Last week I discovered that one of our volumes had 87%(!) file
fragmentation. Number of extents per file was in the range of thousands!
Nothing you are used to when it comes to XFS...
The filesystem is 68% full, but was up to 99% full for a short period a
couple of weeks earlier.
The xfs_fsr utility is made for this kind of problem, but after reading
more about xfs_fsr, in particular this:
I was more sceptical.
So I run some tests. And as Chris pointed out, when running xfs_fsr on a
badly fragmented filesystem, it completely destroys the locality of
Then I decided to try to fix this, so I wrote a dirty little proof of
concept hack to xfs_fsr.c (diff against cvs attached) that finds one
name for the inode it defrags, and places the temporary file it's parent
directory. This way, it will restore the broken locality.
This works fine, after running it on the badly fragmented filesystem,
both fragmentation and locality was better than ever!
However, this fix is as I said "dirty". It uses find -inum to find a
filename for an inode. This makes it quite slow. Not much of a problem
for a one-time problem like this, but it's not very nice to put this
into a cron-job. There must be a better way to find the filename. But
I'm not familiar with the internals of XFS, so I thought I ask on this
Does anyone know of a good way to find one filename that points o a
certain inode? I can't use xfs_db ncheck, as the filesystem is mounted.
Or is there a way to tell XFS to place extents in a newly created file
in a certain AG?
Description: Text Data