Subject: Re: `Large Inodes'
To: Charles M. Hannum <email@example.com>
From: Stefan Grefen <firstname.lastname@example.org>
Date: 03/30/1999 12:35:14
In message <199903261403.JAA11030@trinity.ihack.net> "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.
> 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.
Quite correct, with one minor flaw. There needs to be some 'help'
form the underlying FS, to keep integrety and make atomic operations
possible without creating a locking nightmare.
Added functions to store/retrieve ,from a FFS (underlying FS) perspective
opauqe attribute data, is all that is needed.
If there is no help form the underlying FS,
even if the data would reside on a different inode on the FS and all the
locking problems were solved, finding the 'inode' again would be a huge
waste of time, and I don't see how to make atomic changes to the inode and
the attribute file without major headaches.
Stefan Grefen Tandem Computers Europe Inc.
email@example.com High Performance Research Center
--- Hacking's just another word for nothing left to kludge. ---