Add extended attributes to ext2/3

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.

- Ted

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
#

# fs/Config.in            |    9 
# fs/Makefile             |    4 
# fs/mbcache.c            |  694 ++++++++++++++++++++++++++++++++++++++++++++++++
# include/linux/mbcache.h |   69 ++++

# 4 files changed, 775 insertions(+), 1 deletion(-)
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/10/15 [email protected] 1.851
# Port of the 0.8.50 xattr-mbcache patch to 2.5. (Shrinker API, hch 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.
# --------------------------------------------
#
diff -Nru a/fs/Config.in b/fs/Config.in
--- a/fs/Config.in	Tue Oct 15 16:58:05 2002
+++ b/fs/Config.in	Tue Oct 15 16:58:05 2002
@@ -171,6 +171,15 @@
    define_tristate CONFIG_ZISOFS_FS n
 fi

+# Meta block cache for Extended Attributes (ext2/ext3)
+if [ "$CONFIG_EXT2_FS_XATTR" = "y" -o "$CONFIG_EXT3_FS_XATTR" = "y" ]; then
+ if [ "$CONFIG_EXT2_FS" = "y" -o "$CONFIG_EXT3_FS" = "y" ]; then
+ define_tristate CONFIG_FS_MBCACHE y
+ elif [ "$CONFIG_EXT2_FS" = "m" -o "$CONFIG_EXT3_FS" = "m" ]; then
+ define_tristate CONFIG_FS_MBCACHE m
+ fi
+fi
+
mainmenu_option next_comment
comment 'Partition Types'
source fs/partitions/Config.in

diff -Nru a/fs/Makefile b/fs/Makefile
@@ -6,7 +6,7 @@
 # 
 
 export-objs :=	open.o dcache.o buffer.o bio.o inode.o dquot.o mpage.o aio.o \
-                fcntl.o read_write.o
+                fcntl.o read_write.o mbcache.o
 
 obj-y :=	open.o read_write.o devices.o file_table.o buffer.o \
 		bio.o super.o block_dev.o char_dev.o stat.o exec.o pipe.o \

@@ -29,6 +29,8 @@
 obj-y				+= binfmt_script.o
 
 obj-$(CONFIG_BINFMT_ELF)	+= binfmt_elf.o
+
+obj-$(CONFIG_FS_MBCACHE)	+= mbcache.o
 
 obj-$(CONFIG_QUOTA)		+= dquot.o
 obj-$(CONFIG_QFMT_V1)		+= quota_v1.o

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.

The use of a dev_t search key is a bit old-fashioned. Maybe use the address of inode->i_sb->s_bdev?

e_block is the block number; the e_indexes are hash values. Ext[23] only has 32bit block numbers. Am I getting you wrong?

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.

Well it depends how generic the mbcache code is supposed to be.

The kernel has just gained supoprt for 64-bit sectors on ia32 and PPC32 but the new mbcache code will not support that.

I guess if there are no current 64-bit users of mbcache then it can be deferred until there is a need.

Might do. There's hash_long() in <linux/hash.h>

<nitpick> ... and x86-64 (CONFIG_X86 includes X86-64)

But I wonder why this weird ifdef. Is there any reason why the other architectures are not supported ?

-Andi

From: Andi Kleen <[email protected]>
Date: 16 Oct 2002 03:20:08 +0200

But I wonder why this weird ifdef. Is there any reason why the other architectures are not supported ?

Especially weird considering the fact that ppc32's do_div() doesn't even operate on 64-bit values :-)

It's only used to store an ext2/3 block number (not a 512 byte sector number, but a 1k, 2k, or 4k fs block number).

Changing it to be sector_t wouldn't hurt, but it would be less efficient if CONFIG_LBD were turned on, since ext2/3 would only store 32 bit values into it. If someone needed it for the future, the change could take place then. It's a simple change: change the type of e_block, in mbcache.h, and the type of "block" in the function parameters of mb_cache_entry_insert and mb_cache_entry_get, and you're done. No change would be needed in the ext3 code.

Sure, that would be easy enough to do. In the next patch....

- Ted