On Fri, 26 Mar 1999, Charles M. Hannum wrote:

> The problem I have with the proposal is not quite what other people
> have indicated -- that they want to change the time stamp format, or
> add ACLs, or whatever.
> 
> The problem I have with it is that it's a `Berkeley abstraction'.  You
> obviously have a specific problem that you want to solve, and rather
> than stating that problem, you've attempted to come up with some
> `general' abstraction to encompass it -- one which, in all likelihood,
> isn't anywhere near general enough to handle the next task.

Quite possibly true. :-)

> Furthermore, if I understand the problem you're actually trying to
> solve, I think the `large inode' solution is an exceptionally poor way
> to solve it.  If you're stacking something on top of FFS, there's no
> reason the stacked layer can't keep its data elsewhere.  This is,
> actually, the whole *point* of stacked VFS layers.  This data simply
> doesn't belong in FFS at all.

And where else are we supposed to store this info?

I only see 4 answers to "where do we put overlay inode info." They are:

1) In reserved space in the inode - that's what we're proposing.

2) In a seperate stream off of the file, a la MacOS resource forks or
NTFS's ability to store restoures forks. My concern with our application
using this is the cleanest way I've thought of to impliment it in ufs is
to make one file's inode refer to another inode, which would hold that
fork's data. On the current systems we have, we already have to crank up
the number of inodes in the fs just to hold what we have. We have fs's
with about 10 million inodes on them. If we have to have two inodes per
file, it's even worse.

(we chould build the other fork reading into ffs, but then I don't think
it'd still be ffs :-)

3) In the front of the file, say as a 256 byte header. This solution has
two problems. First, for the migration problem, we want to totally zap
files off of disk. If we store our header in the file, we'll have to keep
at least one frag around. That seems wasteful. Second, we have to keep
accesses from reading/writing that area (not hard, but an extra step).
Third, restoring would be tricky. dump reads the disk info, so would see
our data. But restore writes, so it couldn't store it.

4) In another file system. This idea, while possibly quite sensable for
other forms of overlay VFS, gives me great pause here. First off, it is
even more overhead space, and also it means TWO things have to bet backed
up at once. That's an added hassle for the machine room, and strikes me as
an added point of failure.


Can you think of anywhere else we can store the data?

Take care,

Bill