Lionel Bouton posted on Mon, 28 Sep 2015 11:55:15 +0200 as excerpted: > From what I understood, filefrag doesn't known the length of each extent > on disk but should have its position. This is enough to have a rough > estimation of how badly fragmented the file is : it doesn't change the > result much when computing what a rotating disk must do (especially how > many head movements) to access the whole file.
AFAIK, it's the number of extents reported that's the problem with filefrag and btrfs compression. Multiple 128 KiB compression blocks can be right next to each other, forming one longer extent on-device, but due to the compression, filefrag sees and reports them as one extent per compression block, making the file look like it has perhaps thousands or tens of thousands of extents when in actuality it's only a handful, single or double digits. In that regard, length or position neither one matter, filefrag will simply report a number of extents orders of magnitude higher than what's actually there, on-device. But I'm not a coder so could be entirely wrong; that's simply how I understand it based on what I've seen on-list from the devs themselves. > In the case of Ceph OSD, this isn't what causes the performance problem: > the journal is on the main subvolume and snapshots are done on another > subvolume. Understood... now. I was actually composing a reply saying I didn't get it, when suddenly I did. The snapshots were being taken of different subvolumes entirely, thus excluding the files here in question. Thanks. =:^) >>> This is on a 3.8.19 kernel [...] >> [Btrfs was still experimental] until 3.12 [so] 3.8 >> is very much still in btrfs-experimental land! [...] > > Oops, that was a typo : I meant 3.18.9, sorry :-( That makes a /world/ of difference! LOL! I'm very much relieved! =:^) -- 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
