On Tue, 23 Mar 1999, Ted Lemon wrote:

> 
> > Our thought about this was that these extra uses could come along later.
> > The extra space has a flags field. We didn't expect 32 extra things to
> > come along - if we're trying to cram that much into an inode, we have bad
> > feature creap.
> 
> Oh no, this is exactly the opposite of what I meant.   You've already
> said that you're going to leave the first 128 bytes of the i-node
> alone.   I don't think we all agree that's the right thing to do.
> You say:
> 
> > These flag bits would indicate what extra goddies are there, like
> > Y2038-safe dates
> 
> This doesn't belong in the opaque data field - that would simply be a
> duplication, and wouldn't work if you needed the opaque data for
> anything else, thus rendering the opaque data useless.   Fixing the
> times on the inode pretty much requires a change in the existing inode
> structure.

I AGREE! :-)

These flags aren't in the opaque data. :-) They are, though, in the large
inode.

Here's the defenition of the on-disk large inode:

/*
 * Large dinode.  Requires alternate superblock magic.
 */
struct dinode_large {
        struct dinode   dil_dinode;     /*   0: standard dinode */
#define DINODE_LARGE_APPSPEC_SIZE       96
                                        /* 128: opaque app. specific data */
        u_int8_t        dil_appspec[DINODE_LARGE_APPSPEC_SIZE];
        u_int32_t       dil_flags;      /* 224: flags */
                                        /* 228: reserved for future use */
        u_int8_t        dil_reserved[28];
};

All these flags live in dil_flags.

> > support for more than 32-bits worth of blocks (I think that was one
> > of the things Perry mentioned, but I'm not sure if our indirect
> > block system would support that?)
> 
> This is another thing that doesn't belong in the opaque data.

I agree.

> > support for acl's, etc. As features arrive, dump, restore, ffs, &
> > friends get taught about them.
> 
> That's great, but the opaque data isn't a place where any of these
> features can go - you already have a use for the opaque data.  Any one
> of these uses would prevent the other uses.  This simply doesn't make
> sense.

Right.

> > That way we don't have to decide now what we want to do, we leave space
> > for future growth. Also, we don't have to wait for these features to be
> > defined to move forward. :-)
> 
> Unfortunately, I think we do have to wait.   Please don't take this
> the wrong way.   I think you're on the right track here.   I just
> think it's premature to cast what you have in concrete right now.
> The pressure of having to decide on this prior to 1.4 is just not
> reasonable.

Well, the only thing we'd be casting in stone is: the existance of opaque
data, and that it's 96 bytes. :-)

It might make sense to move dil_flags to one of the "spare" fields in the
struct dinode.

Take care,

Bill