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@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
