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/
signature.asc
Description: This is a digitally signed message part.
|