On Tue, 24 Oct 2000, Ragnar Kj�rstad wrote:
> On Sun, Oct 22, 2000 at 04:23:53PM +0200, Andreas Gruenbacher wrote:
> > Hello,
> >
> > This is a proposal to add extended attributes to the Linux kernel.
> > Extended attributes are name/value pairs associated with inodes.
> >
> > A patch implementing extended attribute system calls, the VFS interface,
> > and code for the ext2 filesystem is available. All material is GPL and/or
> > LGPL licensed. The core implementation is pretty stable since months.
>
> Did you read the thread on l-k regarding a common interface for
> accessing extended attributes (much like NTFS streams)?
I am aware of a recent thread about streams akin to a flamewar. If I
recall correctly there were not many arguments applicable to extended
attributes.
I hope I made clear that streams and extended attributes are separate
things. Streams are accessed using regular file semantics. Extended
attributes are accessed atomically using stateless operations (no
open--close).
> > New to the code base is a mechanism for sharing extended attribute blocks
> > among inodes on the ext2 filesystem. This is a significant optimization.
> > The block sharing code might still contain bugs. It can be deactivated at
> > kernel compile time.
>
> This is just an optimization within the filesystem transparent to VFS
> and userspace, right?
Yes. The block sharing code is at the filesystem layer, completely
transparent to the VFS.
> So each filesystem can choose if to do this optimization, and how - for
> example, for many filesystems it would make sence to make this a more
> general optimization; compressing any common "objects" using the same
> algorithm.
> What about inheritence for extended attributes? With this code, there
> are two options:
> * Just setting the attribute for the directory and all subdirectories
> (It get's compressed anyway...)
> (not really inheritence though)
> * Implement inheritence in the layers using the attributes, e.g. ACL
>
> I don't know how much need there is for inheritence here, but if a lot
> of attributes will need it I think it should be supported in the
> interface instead. (though hardlinks really make this hard)
In UNIX like filesystems, permissions are associated with inodes.
Inheritance based schemes tend to associate permissions with directory
entries. There's an inherent conflict between the two. (Personally I
prefer the inode based scheme.)
For Posix like Access Control Lists at least I don't see how inheritance
could possibly work out. All ideas I have seen so far seem to collapse at
some point.
I have discussed that with Vyacheslav Zavadsky (the "Linux Trustees guy")
a long time ago without consensus. My conclusion was back then was
Trustees don't scale up very well.
Thanks,
Andreas
------------------------------------------------------------------------
Andreas Gruenbacher, [EMAIL PROTECTED]
Contact information: http://www.bestbits.at/~ag/
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
