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

[Kai Krakow]

Rich Freeman <rich0@g.o> schrieb:

> On Sat, Jun 21, 2014 at 3:24 PM, Kai Krakow <hurikhan77@×××××.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.