On Thu, 25 Mar 1999, 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:
> 
> typedef struct inode_tag {
>   u_int32_t magic;
>   size_t len;
>   char *data;
> } tag_t;
> 
> fcntl (file, F_ADD_TAG, tag_t)
>       returns 0 for success, -1 for failure
>       possible ERRNO values:
> 	       ENOSPC - no space to store this tag.
> 
> fcntl (file, F_GET_TAG, tag_t)
>       looks up field with magic number from tag_t.
>       on success:
>       - returns 0
>       - stores up to tag_t.len bytes through tag_t.data pointer
>         sets tag_t.len to total bytes for tag, which may be greater than
> 	incoming tag_t.len.
>       on failure:
>       - returns -1
>       - errno = ENOENT
>       - tag_t unmodified
> 
> fcntl (file, F_DELETE_TAG, tag_t)
>       on success:
>       - returns 0
>       - specified tag has been deleted.
>       on failure:
>       - returns -1
>       - errno = ENOENT
> 
> Compression of the buffer happens in the delete call, not on file
> closure.  It's no pro-o-blem!

Right. And I mentioned that in another message, and you posted a delete
compactor in that message.

> > 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.

Ok.

> > 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.

Wait. The flag bits never were in the opaque data. They, and 28 unused
bytes, were outside the opaque data.

> > 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.

Since we have only 128 bytes, starting down the road of storing GUI stuff
here makes me nervous...

> > 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.
> 
> If it's something that more than one filesystem can use, and somebody
> implements a filesystem other than yours that uses it, then at some
> point the two will be stacked, and it won't work.   If somebody finds
> a non-filesystem use for it, that won't work with your filesystem.
> 
> > 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.

ACL's were never intended to be stored in the opaque data. I'm sorry that
some folks gathered that impression.

The opaque data was just one use of the extra 128 bytes. A fat one, but
just one.

ACL's and a resource fork (an alternate data stream tied to the inode)
would need to be stored outside the opaque data. The opaque data is opaque
to ufs. :-) Plus, I want ACL's enforced by FFS/LFS, not an overlay fs
(thus they are outside the opaque data) :-) .

And the resource fork reference really needs to be a pointer to an other
inode which holds the resource fork. That way fsck could easily find it,
and since it's a file, we don't have to add any new mechanisms to read or
store the info.

Take care,

Bill