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
|