Le 06/07/2017 à 13:51, Austin S. Hemmelgarn a écrit : > > Additionally, when you're referring to extent size, I assume you mean > the huge number of 128k extents that the FIEMAP ioctl (and at least > older versions of `filefrag`) shows for compressed files? If that's > the case, then it's important to understand that that's due to an > issue with FIEMAP, it doesn't understand compressed extents in BTRFS > correctly, so it shows one extent per compressed _block_ instead, even > if they are internally an extent in BTRFS. You can verify the actual > number of extents by checking how many runs of continuous 128k > 'extents' there are.
This is in fact the problem : compressed extents are far less likely to be contiguous than uncompressed extents (even compensating for the fiemap limitations). When calling defrag on these files BTRFS is likely to ignore the fragmentation too : when I modeled the cost of reading a file as stored vs the ideal cost if it were in one single block I got this surprise. Uncompressed files can be fully defragmented most of the time, compressed files usually reach a fragmentation cost of approximately 1.5x to 2.5x the ideal case after defragmentation (it seems to depend on how the whole filesystem is used). Lionel -- 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
