In message <199903260142.UAA03094@grosse.fugue.com>  Ted Lemon wrote:
> 
> > No, because it would also have to compact space on closure, among other
> > things.
> 
> No, it would not.   You would define the following operations:

Other people call this extended-attributes,  I think it implies more
possible uses.

> 
> typedef struct inode_tag {
>   u_int32_t magic;
>   size_t len;
>   char *data;
> } tag_t;

...

> fcntl (file, F_ADD_TAG, tag_t)
> fcntl (file, F_GET_TAG, tag_t)
> fcntl (file, F_DELETE_TAG, tag_t)

....

Thats ok, but the tag-magic should contain a class and a class-specific code.
eg.,

typedef struct { u_int16_t tag_class,u_int16_t tag_code };

so that generic code inside the kernel can 'map' the provided data
in a 'application' specific way. (esp. if you try to implement stuff
like DMIG you may need to convert some of the values to kernel specific
values as userland can't gurantee atomic translations for some values.

Also using strings instead of constants would be a big win!! This avoids
conflicts later on on some of he more common magic numbers 42, 4711 ...
Translations for strings to classes could be stored permanently in a 
specific place like quotas on a per filesystem basis, so this would
be a userland only convention/library.

> 
> > The reason for keeping the magic number in host order is so that the
> > overlay fs can tell if it needs to byteswap the payload.
> 
> So make the magic number 23 bits, and use one bit to indicate byte
> order.

Make the class tag 15 bits. this only limits the number of extension-classes
on a per filesystem base (Ok I admid 7 bits would do for most systems :-)).

> 
> > No, I disagree. Sticking a database in the inode sounds like a mess to me.
> > And that is what you're proposing.
> 
> Putting in an opaque data field with flag bits sounds like a mess to
> me.   Maybe this isn't a good argument.

Sticking a database in the inode is excatly what we need, as there are
a lot of other applications that can use additional attributes.

> 
> > And just what, exactly, are other people going to want to stick in here?
> 
> Other file attributes?   You're proposing a userland API - I can think
> of things I'd like to stick in there.   Small things, obviously.   GUI
> hints, for example.

GUI hints, tertiary/backup  storage tags, ACL's , conditional symlinks ,
triggers, file versioning, persistant fs-snapshots ,  
encryption/authentication ...

> 
> > I really don't forsee having two overlay fs's running on top of each
> > other at the same time, each needing per-inode storage.
> 

Thats a weak argument (esp. in NetBSD context were 150% correct
   is not enough :-)) ), 
 1) it can be used by applications without an overlay OS
 2) ACL's would be a prime example for something that may be used
    on top of any other usage

> 
> > We can leave hooks in the design so it could be supported, but it
> > really strikes me as rare.
> 
> How about a filesystem with macos-like resource forks, where the
> inode of the resource fork is stored in the opaque data?   How about
> ACLs?   There are tons of possible uses for this.

People like veritas do it approximatly this way (but using ioctl instead
of fcntl) and the attribute pointer points to a normal fs-block
and there is an indicator if it's a simple data-block or an indirect one.
I see no need to restict this to one block or a certain size, 
so the whole resource fork could go in under one tag (even if its
3 MBytes).
The normal fs-code can be used to read/write those tag/attribure-areas.

Stefan

> 
> 			       _MelloN_

--
Stefan Grefen                                Tandem Computers Europe Inc.
grefen@hprc.tandem.com                       High Performance Research Center
 --- Hacking's just another word for nothing left to kludge. ---