On Sun, Jun 22, 2014 at 7:44 AM, Kai Krakow <hurikha...@gmail.com> wrote: > 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.
Ah, didn't realize you could attach/remove devices to bcache later. Presumably it handles device failures gracefully, ie exposing them to the underlying filesystem so that it can properly recover? > > 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. The only problem with doing stuff like this at a lower level (both write and read caching) is that it isn't RAID-aware. If you write 10GB of data, you use 20GB of cache to do it if you're mirrored, because the cache doesn't know about mirroring. Offhand I'm not sure if there are any performance penalties as well around the need for barriers/etc with the cache not being able to be relied on to do the right thing in terms of what gets written out - also, the data isn't redundant while it is on the cache, unless you mirror the cache. Granted, if you're using it for write intent logging then there isn't much getting around that. > 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). And this is the main thing keeping me away from it. It is REALLY painful to migrate to/from. Having it integrated into the filesystem delivers all the same benefits of not being able to mount it without the cache present. Now excuse me while I go fix my btrfs (I tried re-enabling snapper and it again got the filesystem into a worked-up state after trying to clean up half a dozen snapshots at the same time - it works fine until you go and try to write a lot of data to it, then it stops syncing though you don't necessarily notice until a few hours later when the write cache exhausts RAM and on reboot your disk reverts back a few hours). I suspect that if I just treat it gently for a few hours btrfs will clean up the mess and it will work normally again, but the damage apparently persists after a reboot if you go heavy in the disk too quickly... Rich
