Hi,

> Don't forget that there's an asymetry in dump & restore. dump wants access
> to the unmounted device - it reads the raw, on-disk image. restore
> accesses the live filesystem. Since our overlay layer doesn't have a
> filestore, you can't dump it. Without hacking restore, a restore would
> need to take the overlay fs off-line. Not a happy thought. :-)

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

> Also, the dumps of the fs aren't dumps of the file, they are dumps of the
> file plus junk. With the other solutions, you could take the restore to
> another system, restore, and have all the data that was on disk at the
> time of the dump, ready to read. You wouldn't have the ability to read in
> migrated files, but you'd have what was on disk in a readily readable
> format.

See above.

> 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?

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800