swhiteho at redhat.com
Thu Jun 2 11:03:39 UTC 2011
On Thu, 2011-06-02 at 11:47 +0100, Alan Brown wrote:
> Steven Whitehouse wrote:
> > The thing to check is what size the extents are...
> filefrag doesn't show this.
Yes it does. You need the -v flag
> > the on-disk layout is
> > designed so that you should have a metadata block separating each data
> > extent at exactly the place where we would need to read a new metadata
> > block in order to continue reading the file in a streaming fashion.
> > That means on a 4k block size filesystem, the data extents are usually
> > around 509 blocks in length, and if you see a number of these with
> > (mostly) a single metadata block between them (sometimes more if the
> > height of the metadata tree grows) then that is the expected layout.
> 4k*509 = 2024k - most of these files are 800-1010k (there isn't a file
> on this FS larger than 2Mb)
> I've just taken one directory (225 entries, all 880-900k), copied each
> file and moved the copy back to the original spot.
> Filefrag says they're now 1-3 extents (50% 1 extent, 30% 2 extents)
That doesn't sound too unreasonable to me. Usually the best way to
defrag is simply to copy the file elsewhere and copy it back as you've
done. That is why there is no specific tool to do this.
> This filesystem is 700G and was originally populated in a single rsync pass.
> Filesystem Size Used Avail Use% Mounted on
> 700G 660G 41G 95% /stage/sarch01
> Filesystem Inodes IUsed IFree IUse% Mounted on
> 13072686 2542375 10530311 20% /stage/sarch01
> I'd understand if the last files written were like this, but it's right
> across the entire FS.
If rsync is writing only a single file at a time, it should be pretty
good wrt to fragmentation. If it is trying to write multiple files at
the same time, bit by bit, then that is the kind of thing which might
increase fragmentation a bit depending on the exact pattern in this
More information about the Linux-cluster