Rich Freeman <ri...@gentoo.org> schrieb: > On Sat, Jun 21, 2014 at 3:24 PM, Kai Krakow <hurikha...@gmail.com> wrote: >> And while we are at it, I'd also like to mention bcache. Tho, conversion >> is not straight forward. However, I'm going to try that soon for my >> spinning rust btrfs. > > I contemplated that, but I'd really like to see btrfs support > something more native. Bcache is way too low-level for me and strikes > me as inefficient as a result. Plus, since it sits UNDER btrfs you'd > probably lose all the fancy volume management features.
I don't see where you could lose the volume management features. You just add device on top of the bcache device after you initialized the raw device with a bcache superblock and attached it. The rest works the same, just that you use bcacheX instead of sdX devices. Bcache is a general approach and it seems to work very well for that already. There are hot data tracking patches and proposals to support adding a cache device to the btrfs pool and let btrfs migrate data back and forth between each. That would be native. But it still would lack the advanced features ZFS implements to make use of such caching devices, implementing even different strategies for ZIL, ARC, and L2ARC. That's the gap bcache tries to jump. > ZFS has ssd caching as part of the actual filesystem, and that seems > MUCH cleaner. Yes, it is much more mature in that regard. Comparing with ZFS, bcache is a lot like ZIL, while hot data relocation in btrfs would be a lot like L2ARC. ARC is a special purpose RAM cache separate from the VFS caches which has special knowledge about ZFS structures to keep performance high. Some filesystems implement something similar by keeping tree structures completely in RAM. I think, both bcache and hot data tracking take parts of the work that ARC does for ZFS - note that "hot data tracking" is a generic VFS interface, while "hot data relocation" is something from btrfs. Both work together but it is not there yet. >From that point of view, I don't think something like ZIL should be implemented in btrfs itself but as a generic approach like bcache so every component in Linux can make use of it. Hot data relocation OTOH is interesting from another point of view and may become part of future btrfs as it benefits from knowledge about the filesystem itself, using a generic interface like "hot data tracking" in VFS - so other components can make use of that, too. A ZIL-like cache and hot data relocation could probably solve a lot of fragmentation issues (especially a ZIL-like cache), so I hope work for that will get pushed a little more soon. Having to prepare devices for bcache is kind of a show-stopper because it is no drop-in component that way. But OTOH I like that approach better than dm- cache because it protects from using the backing device without going through the caching layer which could otherwise severely damage your data, and you get along with fewer devices and don't need to size a meta device (which probably needs to grow later if you add devices, I don't know). -- Replies to list only preferred.
