On Wed, Feb 14, 2018 at 10:08 AM, Nikolay Borisov <nborisov@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
