Hacker News Reader

Comment by renewiltord | Hacker News Reader

Hmm, my mistake. I thought Bcachefs had copy-up-on-read. It looks like only catfs and aufs do that.

Of course bcachefs can cache data; that was the main draw of bcache as well.

Quoting an example from https://bcachefs.org/GettingStarted/

    bcachefs format /dev/sd[ab]1 \
        --foreground_target /dev/sda1 \
        --promote_target /dev/sda1 \
        --background_target /dev/sdb1
    mount -t bcachefs /dev/sda1:/dev/sdb1 /mnt

This will configure the filesystem so that writes will be buffered to /dev/sda1 before being written back to /dev/sdb1 in the background, and that hot data will be promoted to /dev/sda1 for faster access.

    bcachefs format --help

    --promote_target=(target)
        Device or label to promote data to on read

That is very cool. I under specified when I last spoke. I was hoping for something that would cache arbitrary files. I have a slow FUSE fs I would like cached.

But perhaps I can use bcache instead of cachefilesd to have some more controllable NFS cache.

Bcache seems to use block devices and I don't think it can stand in front of FUSE.

i used to use [0]s3ql on-top of "slow" fuse storage. it comes with its own caching layer and some strategies around handling larger blobs of data efficiently even at high latency with ease but its a non shared filesystem. you mount/lock it only once at a time. otherwise this was a perfect solution to me at the time.

there is also [1]rclone with its own caching layer and own support for various backends directly. I don't remember anymore why i did prefer s3ql though, but i usually have some reasoning with things like this..

[0]: https://github.com/s3ql/s3ql [1]: https://rclone.org/

Reply on news.ycombinator.com