On Wed, Feb 14, 2018 at 10:08 AM, Nikolay Borisov <nbori...@suse.com> wrote:

> V1 for large filesystems is jut awful. Facebook have been experiencing
> the pain hence they implemented v2. You can view the spacecache tree as
> the complement version of the extent tree. v1 cache is implemented as a
> hidden inode and even though writes (aka flushing of the freespace
> cache) are metadata they are essentially treated as data. This could
> potentially lead to priority inversions if cgroups io controller is
> involved.
>
> Furthermore, there is at least 1 known deadlock problem in freespace
> cache v1. So yes, if you want to use btrfs ona multi-tb system v2 is
> really the way to go.

I've been using v2 on a couple of systems' rootfs for a couple of
months. I'm not totally certain it's v2, or another enhancement circa
4.14, but system updates (rpm based) are definitely faster. So it may
not only be a Nice To Have with big file systems. I haven't tried it
yet but if the file system face plants on me, I figure I'll use btrfs
check to wipe the free space cache (hopefully that's allowed even if
the file system is hosed) and then try to repair.


-- 
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to