On Wed, Mar 31, 2010 at 06:28:14AM +0800, AndCycle wrote:
> my xfs_fsr version is xfsdump_2.2.48-1,
> there is a description in xfs_fsr man said
> When invoked with no arguments xfs_fsr reorganizes all regular files
> in all mounted filesystems.
> Each pass goes through and selects files that have the largest
> number of extents. It attempts to defragment the top 10% of these
> files on each pass.
> but xfs_fsr -d telling me it defrags in inode ascending order,
Look a little closer:
ino=603561 extents=1815 can_save=1814 tmp=/.fsr/ag2/tmp14298
ino=12652801 extents=208 can_save=207 tmp=/.fsr/ag2/tmp14298
ino=12652802 extents=164 can_save=163 tmp=/.fsr/ag3/tmp14298
ino=13245759 extents=2 can_save=1 tmp=/.fsr/ag0/tmp14298
ino=77725409 extents=11 can_save=10 tmp=/.fsr/ag3/tmp14298
ino=78685589 extents=2 can_save=1 tmp=/.fsr/ag0/tmp14298
ino=538183901 extents=2 can_save=1 tmp=/.fsr/ag3/tmp14298
ino=543424932 extents=2 can_save=1 tmp=/.fsr/ag0/tmp14298
Apart from ino=77725409, they are in order of most extents to least
extents. Maybe the qsort() library function that is used is not
sorting everything correctly, but overall it looks like it is doing
pretty much what the man page says. The ascending order of the inode
numbers is really just a co-incidence.