xfs_fsr, sunit, and swidth

[Dave Hall]

So, assuming entropy has reached critical mass and that there is no easy 
fix for this physical file system, what would happen if I replicated 
this data to a new disk array?  When I say 'replicate', I'm not talking 
about xfs_dump.  I'm talking about running a series of cp -al/rsync 
operations (or maybe rsync with --link-dest) that will precisely 
reproduce the linked data on my current array.  All of the inodes would 
be re-allocated.  There wouldn't be any (or at least not many) deletes.

I am hoping that if I do this the inode fragmentation will be 
significantly reduced on the target as compared to the source.  Of 
course over time it may re-fragment, but with two arrays I can always 
wipe one and reload it.

-Dave

Dave Hall
Binghamton University
kdhall at binghamton.edu
607-760-2328 (Cell)
607-777-4641 (Office)


On 03/30/2013 09:22 PM, Dave Chinner wrote:
> On Fri, Mar 29, 2013 at 03:59:46PM -0400, Dave Hall wrote:
>    
>> Dave, Stan,
>>
>> Here is the link for perf top -U:  http://pastebin.com/JYLXYWki.
>> The ag report is at http://pastebin.com/VzziSa4L.  Interestingly,
>> the backups ran fast a couple times this week.  Once under 9 hours.
>> Today it looks like it's running long again.
>>      
>      12.38%  [xfs]     [k] xfs_btree_get_rec
>      11.65%  [xfs]     [k] _xfs_buf_find
>      11.29%  [xfs]     [k] xfs_btree_increment
>       7.88%  [xfs]     [k] xfs_inobt_get_rec
>       5.40%  [kernel]  [k] intel_idle
>       4.13%  [xfs]     [k] xfs_btree_get_block
>       4.09%  [xfs]     [k] xfs_dialloc
>       3.21%  [xfs]     [k] xfs_btree_readahead
>       2.00%  [xfs]     [k] xfs_btree_rec_offset
>       1.50%  [xfs]     [k] xfs_btree_rec_addr
>
> Inode allocation searches, looking for an inode near to the parent
> directory.
>
> Whatthis indicates is that you have lots of sparsely allocated inode
> chunks on disk. i.e. each 64 indoe chunk has some free inodes in it,
> and some used inodes. This is Likely due to random removal of inodes
> as you delete old backups and link counts drop to zero. Because we
> only index inodes on "allocated chunks", finding a chunk that has a
> free inode can be like finding a needle in a haystack. There are
> heuristics used to stop searches from consuming too much CPU, but it
> still can be quite slow when you repeatedly hit those paths....
>
> I don't have an answer that will magically speed things up for
> you right now...
>
> Cheers,
>
> Dave.
>