Subject: Re: as long as we're hitting FFS...
To: Bill Studenmund <firstname.lastname@example.org>
From: Ted Lemon <email@example.com>
Date: 03/23/1999 23:34:33
> 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.
> 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
> 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.
> 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
> 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