In article <199712050728.XAA24436@lestat.nas.nasa.gov> you write:
> Be warned, this is brainstorm spew...

What, as opposed to my proposal? :-)

> So, from my quick skimming of this, I think I pretty much agree with
> your scheme.  In fact, I've been thinking of things along very similar
> lines.

Great!

> The issue I disagree with is the use of the "unveiled" flag.  I think
> that the process structure needs to stay out of this.  It doesn't really
> have anything to do with the file system.
> 
> What I think would be more plausible is a passthrough vfs layer: hsmfs.

I rejected the idea of a vfs layer because I didn't want to put all the
gunk in the kernel.  It didn't occur to me to make it a think vfs that
uses a userland daemon, though...  even though it's already been done
(portalfs).  Oh well.  Yes, you're right.  That's much better.  Still, I
don't think my proposal was bad for a total of like 30 minutes of
thought :-)

> This would be sort of a nullfs-like thing.  For operations on resident
> files, the ops just pass through to the lower layer.  For non-resident
> files, the appropriate restoration occurs.

One question regarding vfs layers -- can we NFS export them? I've never
tried exporting a unionfs or nullfs. Does it work?

> The key bit, here, is a database, that exists as a regular file on the
> lower layer, that is always resident.  This database contains the additional
> metadata for the files in the file system, indexed by inode number, or
> whatever is appropriate.  (It might make sense to make this a ufs-specific
> thin layer, because of the need to know fiel system specifics.)

This is pretty much what I was thinking, including the index by inode
part (though I didn't elaborate on that part).

> Ok, so this probably sounds kind of scattered, but I hope you get the
> idea... I wish I had a couple of hours, an audience, and a whiteboard
> on which to flesh this out a bit... but alas, I have to get ready for a
> trip.

Actually, other than the vfs vs. veiled process hack, it sounds pretty
much the same.

The hard part is the hsmd. Doing that well, and supporting diverse
storage methods will be very difficult, I think. For example, you want
huge tape libraries... the most I forsee using it for myself would be to
put a cd multichanger online and use hsmfs to provide a sort of cache
and to prevent changer thrashing if multiple users want to access
different CDs.

Next: my 30 minute ACL scheme :-)