Re: unclean shutdown and space cache rebuild

[Duncan <1i5t5.duncan@cox.net>]

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