Re: extremely slow file creation/deletion after xfs ran full

[Dave Chinner <david@fromorbit.com>]

On Mon, Jan 12, 2015 at 06:33:06PM +0100, Carsten Aulbert wrote:
> Hi
> 
> On 01/12/2015 05:37 PM, Brian Foster wrote:
> > No, but it does show that there are a bunch of free inodes scattered
> > throughout the existing records in most of the AGs. The finobt should
> > definitely help avoid the allocation latency when this occurs.
> > 
> 
> That is good to know/hope :)
> 
> > It is interesting that you have so many more free inodes in ag 0 (~53m
> > as opposed to several hundreds/thousands in others). What does 'p count'
> > show for each ag? Was this fs grown to the current size over time?
> > 
> "p count" seems to "thin out" over ag:
> 
> count = 513057792

AG 0 has > 500 allocated million inodes, and > 50 million free
inodes.  Traversal of the inode btree to find free inodes is going
to be costly in both CPU time and memory footprint. The other AGs
have much fewer inodes, so searches are much less costly.

That's why allocation will be sometimes slow and sometimes fast - it
depends on what AG the inode is being allocated from.

> count = 16596224
> count = 15387584
> count = 14958528
> count = 4096960
> count = 4340416
> count = 4987968
> count = 3321792
> count = 5041856
> count = 5485376
> count = 5233088
> count = 5810432
> count = 5271552
> count = 5464000
> count = 365440

This pattern seems to match a filesystem that was running under
inode32 for most of it's life, and is now using inode64 and hence
spreading the subdirectories and hence new inodes over all AGs
instead of just limiting them to AG 0....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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