Shridhar Daithankar posted on Mon, 01 Jul 2013 08:20:19 +0530 as excerpted: > On Sunday, June 30, 2013 01:53:48 PM Garry T. Williams wrote: [discussing fragmentation] > >> ~/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend > > damn! > > # filefrag soprano-virtuoso.db soprano-virtuoso.db: 10518 extents found > > # btrfs fi defrag soprano-virtuoso.db > > # filefrag soprano-virtuoso.db soprano-virtuoso.db: 957 extents found While you evidently had quite some fragmentation as the number of extents dropped considerably, if you're running btrfs compression, it's worth noting that (based on earlier posts here) filefrag always counts compressed files as fragmented, even if they're not. So a sufficiently sized file will almost certainly show fragmentation via filefrag if it's compressed, and all you can do is use filefrag as a hint in that case; defrag may well not do anything if it's not actually fragmented. > How much is an extend anyways? is it a page or 256M? I don't know... > But in general, how to find out most fragmented files and folders? > mouting with autodefrag is a serious degradation.. It is? AFAIK, all the autodefrag mount option does is scan files for fragmentation as they are written and queue any fragmentation-detected files for background defrag by the defrag thread. I had expected, particularly on spinning rust, that the benefits of autodefrag to far exceed the costs, so your performance drag claim is interesting to me indeed. If my expectation is wrong, which it could be, I'd love to know why, and see some numbers. -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
