All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Kujau <lists@nerdbynature.de>
To: Dave Chinner <david@fromorbit.com>
Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com
Subject: Re: 3.5.0-rc5: inconsistent lock state
Date: Thu, 5 Jul 2012 18:55:39 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.01.1207051824190.5568@trent.utfs.org> (raw)
In-Reply-To: <20120706010126.GT19223@dastard>

On Fri, 6 Jul 2012 at 11:01, Dave Chinner wrote:
> 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....

Hm, it's some kind of server, samba is serving those mounts, but only as 
readonly shares. When running "getfattr -R" or "getfacl -R" on these xfs 
filesystems, only very few (<100) file have attribtues / ACLs set.

> > 50 bytes sounds more than enought for holding only unix permissions.
> Unix permissions are held in the inode core, not in the attribute
> space.

Even better, so I'm really at a loss what could use up this 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....

$ xfs_bmap foo | wc -l
933

And there are lots of files held by lots of extents, so this might be it.

Thanks for this guide through this attribute business. There's currently 
no problem with any of the filesystems but I was tipped off by Christoph's 
remark about "running out of inode attributes" which got me scared a 
little. I understand that it might be a performance issue having to do 
an extra lookup for attributes, but I still fail to see how (and where) 
they sneaked into the fs.

Christian.
-- 
BOFH excuse #284:

Electrons on a bender

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

      reply	other threads:[~2012-07-06  1:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-04 19:13 3.5.0-rc5: inconsistent lock state Christian Kujau
2012-07-04 19:14 ` Christian Kujau
2012-07-05  7:43 ` Christoph Hellwig
2012-07-05 12:44   ` Christian Kujau
2012-07-05 21:59     ` Dave Chinner
2012-07-05 23:39       ` Christian Kujau
2012-07-06  1:01         ` Dave Chinner
2012-07-06  1:55           ` Christian Kujau [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.01.1207051824190.5568@trent.utfs.org \
    --to=lists@nerdbynature.de \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.