On Fri, 26 Mar 1999, Wolfgang Solfrank wrote:

> Wouldn't your size-doubled inodes require modifications to both of
> dump/restore anyway?

Yes, and already implimented. The reason we didn't talk about this much
months ago was that we were getting all of the userland pieces in place.
As mentioned in the original post, we have fixed fsck, dump, restore,
fsirand, quota*, and newfs to all work with the larger nodes.

> 
> > Bill Sommerfield suggested this. And it's very intersting. My one concern
> > is that we'd have to hack restore, which possily isn't a big deal. Because
> > a restore to a live overlay system would need to stick this metadata in
> > the new files, not the old ones.
> 
> See above.  Your scheme requires modifications to restore, too, to extract
> the additional data and call vnextops (or whatever it is called) to supply
> that to the inode.  Or am I missing something here?

Right. But all it needed to know about was that there WAS opaque data, in
the os-standard format. Since the design had only one opaque data blob in
a file at a time, if there was opaque data (irregardles of whose opaque
data it was), then restore just drops it in place.

Take care,

Bill