Re: mount btrfs takes 30 minutes, btrfs check runs out of memory

[Duncan <1i5t5.duncan@cox.net>]

Qu Wenruo posted on Mon, 18 Jul 2016 17:07:47 +0800 as excerpted:

>>     Since I'm really surprised on the mount time reduce, especially
>>     considering the fact that for compression case, max extent size is
>>     limited to 128K, IMHO defrag won't help much.
>>
>> Is the 128K limit for the whole FS or only for files that btrfs deemed
>> worth to compress? If it's the latter, that could explain why defrag
>> helped.
> 
> The latter. But the 128K is not for compressed size, but raw size.
> 
> So no matter the compressed size, any extent whose uncompressed size is
> larger than 128K will be split.
> 
> The main reason I'm surprised about the mount time reduce, is that
> considering the sectorsize (4K for x86_64 and x86), the fragments won't
> increase too much.
> The smallest extent size is determined by sectorsize(4K for most arch).
> Compressed extent up limit is 128K,  4K -> 128K is only 32 times. While
> for non-compress case, its extent size up limit is 128M.
> 32K times larger than sector size, or 1024 times larger than compressed
> extent size.
> 
> So I'm quite surprised that defrag helps so much.

[I'm only seeing your posts here, not his (yet?), so I'm only seeing what 
you quote from his posts and may be missing part of the story.  Never-the-
less...]

I think what he's referring to is that he's only running compress, not 
compress-force, and presumably not autodefrag.  So there's probably a lot 
of uncompressed files that were heavily fragmented and thus in many 
extents, that a defrag run helped consolidate, thus reducing mount time 
substantially.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman