On 08/31/2017 06:18 PM, Duncan wrote: [...] > Michał Sokołowski posted on Thu, 31 Aug 2017 16:38:14 +0200 as excerpted: >> Is there another tool to verify fragments number of given file when >> using compression? > AFAIK there isn't an official one, tho someone posted a script (python, > IIRC) at one point and may repost it here. > > You can actually get the information needed from filefrag -v (and the > script does), but it takes a bit more effort than usual, scripted or > brain-power, to convert the results into real fragmentation numbers. > > The problem is that btrfs compression works in 128 KiB blocks, and > filefrag sees each of those as a fragment. The extra effort involves > checking the addresses of the reported 128 KiB blocks to see if they are > actually contiguous, that is, one starts just after the previous one > ends. If so it's actually not fragmented at that point. But if the > addresses aren't contiguous, there's fragmentation at that point. > > I don't personally worry too much about it here, for two reasons. First, > I /always/ run with the autodefrag mount option, which keeps > fragmentation manageable in any case[1], and second, I'm on ssd, where > the effects of fragmentation aren't as pronounced. (On spinning rust > it's generally the seek times that dominate. On ssds that's 0, but > there's still an IOPS cost.) > > So while I've run filefrag -v and looked at the results a few times out > of curiousity, and indeed could see the reported fragmentation that was > actually contiguous, it was simply a curiosity to me, thus my not > grabbing that script and putting it to immediate use. > > --- > [1] AFAIK autodefrag checks fragmentation on writes, and rewrites 16 MiB > blocks if necessary. If like me you always run it from the moment you > start putting data on the filesystem, that should work pretty well. If > however you haven't been running it or doing manual defrag, because > defrag only works on writes and the free space may be fragmented enough > there's not 16 MiB blocks to write into, it may take awhile to "catch > up", and of course won't defrag anything that's never written to again, > but is often reread, making its existing fragmentation an issue.
Very comprehensive, thank you. I was asking because I'd like to learn how really random writes by VM affects BTRFS (vs XFS,Ext4) performance and try to develop some workaround to reduce/prevent it while having csums, cow (snapshots) and compression. -- 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
