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

--
Stefan Grefen                                Tandem Computers Europe Inc.
grefen@hprc.tandem.com                       High Performance Research Center
 --- Hacking's just another word for nothing left to kludge. ---