Hi,
I have a 2T file fragmented into 841891 randomly placed extents. It takes
4-6 minutes (depending on what else the filesystem is doing) to delete the
file. This is causing a timeout in the application doing the removal, and
hilarity ensues.
The fragmentation is the result of reflinking bits and bobs from other
files into the subject file, so it's probably unavoidable.
The file is sitting on XFS on LV on a raid6 comprising 6 x 5400 RPM HDD:
# xfs_info /home
meta-data=/dev/mapper/vg00-home isize=512 agcount=32, agsize=244184192 blks
= sectsz=4096 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=1
= reflink=1
data = bsize=4096 blocks=7813893120, imaxpct=5
= sunit=128 swidth=512 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=521728, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
I'm guessing the time taken to remove is not unreasonable given the speed
of the underlying storage and the amount of metadata involved. Does my
guess seem correct?
I'd like to do some experimentation with a facsimile of this file, e.g.
try the remove on different storage subsystems, and/or with a external fast
journal etc., to see how they compare.
What is the easiest way to recreate a similarly (or even better,
identically) fragmented file?
One way would be to use xfs_metadump / xfs_mdrestore to create an entire
copy of the original filesystem, but I'd really prefer not taking the
original fs offline for the time required. I also don't have the space to
restore the whole fs but perhaps using lvmthin can address the restore
issue, at the cost of a slight(?) performance impact due to the extra
layer.
Is it possible to using the output of xfs_bmap on the original file to
drive ...something, maybe xfs_io, to recreate the fragmentation? A naive
test using xfs_io pwrite didn't produce any fragmentation - unsurprisingly,
given the effort XFS puts into reducing fragmentation.
Cheers,
Chris
