Re: [linuxdc-dev] VMU filesystem question

[David W. <dav...@ia...>]

> * David Willmore <dav...@ia...> on Sun, Dec 08, 2002:
> 
> >=20
> > You Linux VFS sees the files, but the filesystem driver makes them up fro=
> m the=20
> > info in the directories (the hidden pointers and such).  I'll write a bet=
> ter=20
> > description when I get a moment--have to go finish makeing dinner. :)
> >=20
> 
> How does this help you when transferring files to/from a filesystem that
> doesn't understand this information, like NFS?  Or when transferring saves
> around across the network?

That's the advantage of these.  Normal tools will copy the 'special' files
as well.  Tar up the whole thing and you will save the special info with
the normal info.

> The solution would be a user space tool that understood and could transfer
> files between full VMU images (whether dumped or mapped via MTD).  This is =
> the
> only way you can persist the nonstandard info and be flexible enough to
> allow other uses of the VMU save data.  MTOOLS (the MSDOS userspace
> filesystem utilities?) comes to mind.

This requires a whole suite of cross-platform tools that understand how
one hokey little system mangles its data., ick.

> Such tools would be a hell of a lot easier to implement than a full-blown
> (and unfortunately incompatible) VFS driver.

There is nothing incompatable about it--as far as being a VFS driver goes.

Okay, how does this sound.  Make the first block of the file be the special
data for that file?  When the first block is read/written, the fs knows to 
generate that info/save that info in the 'special' area.  All other blocks
work normally.

For inspiration on how I see this working, look at the AppleShare system.
How do unix systems serve files to Macs which expect a file to have a 
code and a resource fork?  They do it by having this split and mirrored
directory structure.

rootoffilesystem/code/pathtostuff/myfile is the code 'fork' of the file
rootoffilesystem/res/pathtostuff/myfile is the resource 'fork' of the file.

If the filesystem is HFS (say a disk from a Mac that's been stuck into
a linux box) then on disk the data is in one big 'file' chunk that one has
to understand how to split into code and resource 'forks'.  The VFS makes it
look like seperate files.  If the Linux box serves it out to an AppleShare
client, it makes it look like one file again.

The VFS just wants to say 'here is a path, open this file and give me
blocks of it'.  The filesystem driver has complete control over what
goes to and comes from the backing store--disk, flash, tape, etc.  Some
filesytems are completely 'made up'--proc, devfs... 

I must be describing this poorly and for that I'm sorry.  It's really
a clever way of making the two systems see the same thing differently/
different things the same.

Cheers,
David