On Thu, Jul 05, 2012 at 04:39:21PM -0700, Christian Kujau wrote: > On Fri, 6 Jul 2012 at 07:59, Dave Chinner wrote: > > It means that you have enough attributes that they don't fit in the > > inode, so every time they are read or written you have to do an > > extra IO on top of reading/writing the inode. Performance can easily > > drop by an order of magnitude when the attributes are moved out of > > the inode.... > > xfs_info shows isize=256 - but I'm not sure how I would have exceeded that > limit? I'm not using SELinux or anhy other security frameworks on that > machine, only plain unix permissions. Just check again, no ACLs, no EAs, > no file attributes are set on these filesystems. Applications can use attributes without you being aware of them. e.g. Samba, desktop search/indexing, etc might be using attributes even though you aren't explicitly using them.... > The filesystems make heavy use of hardlinks, but files usually have no > more than ~12 hardlinks, so that counter should not exceed the inode > size either. Hardlinks are not attributes, and the counter is in the inode core so this won't have any impact on attributes being places out of line. > > Typically there is 50-70 bytes of attribute space available in 256 > > byte inodes, larger attributes or lots of them will push them out of > > the inode.... > > 50 bytes sounds more than enought for holding only unix permissions. Unix permissions are held in the inode core, not in the attribute space. And i did say "typically". if you have a file that has 6-7 extents, then there won't be any space for attributes and it will put new attributes out of line immediately.... > Does > it matter that the filesystem is somewhat larger? Not too large though, > all xfs filesystems are < 1TB in size. No. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
