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 -- 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
