Re: 3.5.0-rc5: inconsistent lock state

[Dave Chinner <david@fromorbit.com>]

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@fromorbit.com

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