All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@clusterfs.com>
To: Christoph Hellwig <hch@infradead.org>,
	"Stephen C. Tweedie" <sct@redhat.com>,
	Andreas Gruenbacher <agruen@suse.de>,
	linux-kernel@vger.kernel.org, ext2-devel@lists.sourceforge.net
Subject: Re: [Ext2-devel] [RFC] [PATCH 3/4] Add extended attributes to ext2/3
Date: Tue, 8 Oct 2002 15:19:36 -0600	[thread overview]
Message-ID: <20021008211936.GL3045@clusterfs.com> (raw)
In-Reply-To: <20021008214736.A22169@infradead.org>

On Oct 08, 2002  21:47 +0100, Christoph Hellwig wrote:
> On Tue, Oct 08, 2002 at 09:41:43PM +0100, Stephen C. Tweedie wrote:
> > On Tue, Oct 08, 2002 at 08:20:38PM +0100, Christoph Hellwig wrote:
> > > On Tue, Oct 08, 2002 at 09:14:00PM +0200, Andreas Gruenbacher wrote:
> > > > Users might just fill up all xattr space leaving no space for ACLs (or 
> > > > similar). If user xattrs are disabled this can no longer occur, so some 
> > > > administrators might be happy to have a choice.
> > > 
> > > Umm, that's why we have quota..
> > 
> > It's the per-inode extended attribute space that's at risk here,
> > quotas don't help.
> 
> Well, that's a more important problem.  But I doubt a hack to just turn off
> user xattrs is the right fix then.  A static reservation for ACLs or just
> totally separating them (like in XFS) seems more m?ture.

Yes, we have made proposals in the past to change the way ext2/3 EAs are
stored on disk, but nobody has had time to work on it yet.  The current
limitations of 4kB of EA per inode (user+system) is bad, as is the fact
that you need a full block for each inode if you have any unique
per-inode data (basically anything other than ACLs).

That said, the benefits of the current EA implementation far outweigh the 
limitations, and since this is an internal-to-ext2/3 issue, we can
change it at some later date without affecting the rest of the kernel.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/


  reply	other threads:[~2002-10-08 21:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-08 18:08 [RFC] [PATCH 3/4] Add extended attributes to ext2/3 tytso
2002-10-08 18:53 ` [Ext2-devel] " Christoph Hellwig
2002-10-08 19:14   ` Andreas Gruenbacher
2002-10-08 19:20     ` Christoph Hellwig
2002-10-08 20:41       ` Stephen C. Tweedie
2002-10-08 20:47         ` Christoph Hellwig
2002-10-08 21:19           ` Andreas Dilger [this message]
2002-10-08 22:17         ` Theodore Ts'o
2002-10-09 11:29           ` Andreas Gruenbacher
2002-10-09 15:25             ` Stephen C. Tweedie
2002-10-08 22:21   ` Theodore Ts'o
     [not found]     ` <20021009064242.GW3045@clusterfs.com>
2002-10-09 13:09       ` Christoph Hellwig

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=20021008211936.GL3045@clusterfs.com \
    --to=adilger@clusterfs.com \
    --cc=agruen@suse.de \
    --cc=ext2-devel@lists.sourceforge.net \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sct@redhat.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.