Invalidate file in cache (flush file cache) on FreeBSD ?

[iradicator]

I want to invalidate file and remove it from Cache, so that any additional access to that file will go through the lower level storage device.

In linux, it's done using syscall

ioctl(file_desc, BLKFLSBUF)

but what is the equivalent in freeBSD ?

P.S. I related the generate file cache, disregarding specific filesystem.

 

[Bobi B.]

Care to say what are trying to achieve? If it is only to run performance tests, the easiest way would be to unmount and mount the filesystem.

 

[VladiBG]

use sync

 

[SirDice]

I'm not a developer but as far as I understood things sync(2) (or more appropriately fsync(2)) only flushes buffers to disk, it does not change how subsequent access is treated.

 

[VladiBG]

You can use o_direct but it still will use some buffer. Check fcnt(2) for more info.

 

[iradicator]

I seek to invalidate the cache so that read ops will go through the disk.
sync does the opposite (write ops reach the disk by flushing the cache).
any idea how to do that ?

 

[Bobi B.]

And why would you possibly want to do that? It's hard to suggest any pointers with no reasoning.

 

[SirDice]

What are you trying to achieve? There may be other or better ways to do what you want. Lets try to avoid a XY problem.

 

[iradicator]

Basically, I've built a lower level block device in kernel grand access to data to authorized processes.
The problem is that when the read cache is valid, a non authorized process IO doesn't go through my block device.

Therefore, I wish all IOs goe through the block device.

 

[SirDice]

I do believe you shouldn't use block devices due to the caching issues it presents. At least that's the reason why FreeBSD doesn't have them any more.

https://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-block.html

You should probably look into FreeBSD's geom(4) framework if it's supposed to sit somewhere in between the various layers.

 

[Crivens]

Block reading in your device and only allow memory mapping. You should then only allow private mappings and your problem should be solved.

 

[ralphbsz]

You are trying to do access control at the block device level?

That violates the system's design philosophy, which is that block devices are universal, while access control is performed by the file system.

Why don't you trust the file system to perform access control?

 

[Crivens]

Maybe because it is not really a file system? I almost fell into that hole some time ago, when I was doing the driver for a data aquisition system. Having the hardware mimic some FAT32 and change the content of the file behind the back of the system is very tempting, it would make testing so much easier... but I did veto that and we went the mmap way. So maybe iradicator should provide a bit more information and/or revisit the architecture decision.