Re: Very slow filesystem

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

Timofey Titovets posted on Thu, 05 Jun 2014 19:13:08 +0300 as excerpted:

> 2014-06-05 18:52 GMT+03:00 Igor M <igork20@gmail.com>:
>> One more question. Is there any other way to find out file
>> fragmentation ?
>> I just copied 35Gb file on new btrfs filesystem (compressed) and
>> filefrag reports 282275 extents found. This can't be right ?

> hes, because filefrag show compressed block (128kbite) as one extent.

Correct.  Which is why my original answer had this:

>>> While compression changes things up a bit (filefrag doesn't know 
>>> how to deal with it yet and its report isn't reliable),

I skipped over the "why" at the time as it wasn't necessary for the then-
current discussion, but indeed, the reason is because filefrag counts 
each 128 KiB block as a separate fragment because it doesn't understand 
them, and as a result, it's not (currently) usable for btrfs-compressed 
files.

They (the btrfs, filefrag, and kernel folks) are working on teaching 
filefrag about the problem so it can report correct information, but the 
approach being taken is to setup generic kernel functionality to report 
that information to filefrag, such that other filesystems can use the 
same functionality, which makes it a rather more complicated project than 
a simple one-shot fix for btrfs by itself would be.  So while the problem 
is indeed being actively worked on, it could be some time before we 
actually have a filefrag that's accurate in btrfs-compressed-file 
situations, but once we do, we can be confident the solution is a correct 
one that can be used well into the future by btrfs and other filesystems 
as well, not just a brittle hack of a few minutes to a day that can't be 
used for anything else and that could well break again two kernel cycles 
down the road.

Unfortunately, I know of nothing else that can report that information, 
so the only real suggestion I have is to either turn off compression or 
forget about tracking individual file fragmentation for now and go only 
on performance.

But as it happens, the NOCOW file attribute turns off compression (as 
well as checksumming) for that file anyway, because in-place rewrite 
would otherwise trigger complex issues and race conditions that are a 
risk to the data as well as performance, which is why traditional non-COW 
filesystems don't tend to offer these features in the first place.  
Btrfs' normal COW nature makes these features possible, but as this 
thread already explores, unfortunately simply isn't suitable for certain 
access patterns.

So if the file is properly (that is, at creation) set NOCOW, filefrag 
should indeed be accurate, because the file won't be (btrfs-)compressed.

-- 
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