Extreme fragmentation ho!

[Chris Dunlop <chris@onthe.net.au>]

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