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



## iradicator (May 30, 2018)

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. (May 30, 2018)

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 (May 30, 2018)

use sync


----------



## SirDice (May 30, 2018)

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 (May 30, 2018)

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


----------



## iradicator (May 30, 2018)

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. (May 30, 2018)

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


----------



## SirDice (May 30, 2018)

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 (May 30, 2018)

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 (May 30, 2018)

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 (May 30, 2018)

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


----------



## ralphbsz (May 31, 2018)

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 (May 31, 2018)

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.


----------

