xfs_fsr question for improvement

[Michael Monnerie <michael.monnerie@is.it-management.at>]

[-- Attachment #1.1: Type: text/plain, Size: 2816 bytes --]

From the man page I read that a file is defragmented by copying it to a 
free space big enough to place it in one extent.

Now I have a 4TB filesystem, where all files written are at least 1GB, 
average 5GB, up to 30GB each. I just xfs_growfs'd that filesystem to 
6TB, as it was 97% full (150GB free). Every night a xfs_fsr runs and 
finished to defragment everything, except during the last days where it 
didn't find enough free space in a row to defragment.

Could it be that the defragmentation did it's job but in the end the 
file layout was like this:
file 1GB
freespace 900M
file 1GB
freespace 900M
file 1GB
freespace 900M
That, while being an "almost worst case" scenario, would mean that once 
the filesystem is about 50% full, new 1GB files will be fragmented all 
the time.
To prevent this, xfs_fsr should do a "compress" phase after 
defragmentation finished, in order to move all the files behind each 
other:
file 1GB
file 1GB
file 1GB
file 1GB
freespace 3600M
That would also help fill the filesystem from front to end, reducing 
disk head moves.


Another thing, but related to xfs_fsr, is that I did an xfs_repair on 
that filesystem once, and I could see there were a lot of small I/Os 
done, with almost no throughput. The disks are 7.200rpm 2TB disks, so 
random disk access is horribly slow, and it looked like the disks were 
doing nothing else but seeking.
Would it be possible xfs_fsr defrags the meta data in a way that they 
are all together so seeks are faster?
Currently, when I do "find /this_big_fs -inum 1234", it takes *ages* for 
a run, while there are not so many files on it:
# iostat -kx 5 555
Device:         r/s     rkB/s    avgrq-sz avgqu-sz   await  svctm  %util
xvdb              23,20    92,80     8,00     0,42   15,28  18,17  42,16
xvdc              20,20    84,00     8,32     0,57   28,40  28,36  57,28
(I edited the output to remove "writes" columns, as they are 0)
This is a RAID-5 over 7 disks, and 2 TB volumes are used with LVM 
concatenated. As I only added the 3rd 2TB volume today, no seeks on that 
new place.
So I get 43 reads/second at 100% utilization. Well I can see up to 
150r/s, but still that's no "wow". A single run to find an inode takes a 
very long time.
# df -i
Filesystem            Inodes         IUsed          IFree      IUse%
mybigstore            1258291200  765684 1257525516    1%

So only 765.684 files, and it takes about 8 minutes for a "find" pass.
Maybe an xfs_fsr over metadata could help here?


-- 
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc

it-management Internet Services
http://proteger.at [gesprochen: Prot-e-schee]
Tel: 0660 / 415 65 31

// Wir haben im Moment zwei Häuser zu verkaufen:
// http://zmi.at/langegg/
// http://zmi.at/haus2009/

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs