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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
