On 02/14/2018 12:08 PM, Nikolay Borisov 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.
Fantastic. Thanks for the backstory. That is what I will plan to use
then. I've been operating with whatever the default is (I presume v1
based on the man page), but haven't yet populated any of our machines
sufficiently enough to notice performance degradation due to space cache
problems.
No, the long mount times seems to be due to the fact that in order for a
btrfs filesystem to mount it needs to enumerate its block_groups items
and those are stored in the extent tree, which also holds all of the
information pertaining to allocated extents. So mixing those
data structures in the same tree and the fact that blockgroups are
iterated linearly during mount (check btrfs_read_block_groups) means on
spinning rust with shitty seek times this can take a while.
However, this will really depend on the amount of extents you have and
having taken a look at the thread you referred to it seems there is not
clear-cut reason why mounting is taking so long on that particular
occasion.
Ok; thanks. To phrase it somewhat more simply, should I expect for
"normal" datasets (think home directory) that happen to be part of a
very large BTRFS filesystem (tens of TBs) to take more than 60s to
mount? Let's presume there isn't extreme fragmentation or any media
errors to keep things simple.
Best,
ellis
--
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
