Re: [gentoo-user] Re: Re: Re: [Gentoo-User] emerge --sync likely to kill SSD?

[Rich Freeman]

On Sun, Jun 22, 2014 at 7:44 AM, Kai Krakow <hurikhan77@×××××.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