From: Andreas Gruenbacher <agruen@suse.de>
To: Andrew Morton <akpm@digeo.com>, tytso@mit.edu
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] Add extended attributes to ext2/3
Date: Wed, 16 Oct 2002 02:11:39 +0200 [thread overview]
Message-ID: <200210160211.39284.agruen@suse.de> (raw)
In-Reply-To: <3DACAC0C.D4C497C1@digeo.com>
On Wednesday 16 October 2002 02:00, Andrew Morton wrote:
> tytso@mit.edu wrote:
> > This is an updated submission of the extended attribute patches for
> > ext2/3 (versus bk-current). Many thanks to Cristoph, Andrea, and Andrew
> > for their suggestions and cleanups.
> >
> > This patch creates a meta block cache which is utilized by the ext3 and
> > ext2 extended attribute patches (patches 2 and 3, respectively). This
> > cache allows directory blocks to be indexed by multiple keys. In the
> > case of the extended attribute patches, it is used to look up blocks by
> > both the block number and by the hash of the extended attributes. This
> > is extremely important to allow the sharing of acl's when stored as
> > extended attributes. Otherwise every single file would require its own,
> > separate, one block overhead to store then ACL, even though there might
> > be a large number of files that have the same ACL.
>
> The key thing here appears to be the cache entry:
>
> +struct mb_cache_entry {
> + struct list_head e_lru_list;
> + struct mb_cache *e_cache;
> + atomic_t e_used;
> + dev_t e_dev;
> + unsigned long e_block;
> + struct list_head e_block_list;
> + struct mb_cache_entry_index e_indexes[0];
> +};
>
> This should be converted to use sector_t for >2TB support, and tested
> with CONFIG_LBD=y and n.
e_block is the block number; the e_indexes are hash values. Ext[23] only has
32bit block numbers. Am I getting you wrong?
> The use of a dev_t search key is a bit old-fashioned. Maybe
> use the address of inode->i_sb->s_bdev?
That would do as well.
A related issue:
Would switching to a more decent hash algorithm in fs/ext?/xattr.c make sense?
I think there are better ones in 2.5. This would only degrade sharing on
"legacy" systems for a while, but the slow down would vanish over time.
--Andreas.
next prev parent reply other threads:[~2002-10-16 0:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-15 22:20 [PATCH 1/3] Add extended attributes to ext2/3 tytso
2002-10-16 0:00 ` Andrew Morton
2002-10-16 0:11 ` Andreas Gruenbacher [this message]
2002-10-16 0:52 ` Andrew Morton
2002-10-16 1:20 ` Andi Kleen
2002-10-16 1:43 ` David S. Miller
2002-10-16 16:04 ` Theodore Ts'o
[not found] <698528293@toto.iv>
[not found] ` <15788.54887.251518.350350@wombat.chubb.wattle.id.au>
2002-10-16 14:01 ` Andi Kleen
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=200210160211.39284.agruen@suse.de \
--to=agruen@suse.de \
--cc=akpm@digeo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/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.