On Fri, 26 Mar 1999, Bill Studenmund wrote:
> 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?

[First off, I'm catching up on 1000+ emails WRT NetBSD, so please forgive
me if this issue has already been beaten to death.]

Creating an entire file system is probably not necessary, especially to
implement heirarchical storage via stacked filesystems.  What about placing
a portal-like file system on top on any other file system such that
extra meta data is pushed into a database or another filesystem as needed.
For example, when it's determined that a file needs to be pushed out to
tape, the portal-like filesystem daemon could schedule a backup and when
the file is on tape, it would store the file's information and location
on tape into a database and finally unlink the under-lying file.

That way, the underlying filesystem doesn't need to be changed at all and
we still get to store possibly arbitrary amounts of data or metadata.  Also,
possibly arbitrary things can be done to files (encryption, migration to
secondary storage based on usage, ACLs, etc).

Yes, it's not as fast as storing metadata in the inode, but it's certainly generic,
fits into the existing structure of things and gives us user-land file systems
to boot.

Just thinking out loud,

Paul
--
Paul Dokas                                            dokas@cs.umn.edu
======================================================================
Don Juan Matus:  "an enigma wrapped in mystery wrapped in a tortilla."