Hi,

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

What he said!

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

In what sense it that worse than having to double the space per inode?
I don't get it.

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

No, last I looked, ffs didn't have forks :-).

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

Depends on whether you backup/restore the underlying ffs using dump/restore
(in which case you would of course get the header on tape and be able to
restore it to disk) or using dump/restore on your overlay filesystem
(using unmodified dump/restore of one filesystem to backup another
filesystem seems quite silly to me).

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

Why would this be "more overhead space"?  For starters, you can put a file
on the same disk just 96 bytes or whatever space you need (I didn't follow
the discussion too closely, so I'm not sure whether you are using the 96
byte part, or the 32 byte part of the 128 extra bytes per inode) times the
number of inodes on the disk, and index with the inode number into that
file to get at the relevant information. Would probably use less space
than doubling the inode size, and solve the backup problem, too (assuming
you backup the underlying ffs filesystem), and has the added advantage
that it could possibly be used on some other filesystems than ffs, too
(depending however on the way they compute their inode number equivalent).

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800