Re: [linuxdc-dev] VMU filesystem question

[M. R. B. <mr...@0x...>]

* David Willmore <dav...@ia...> on Sun, Dec 08, 2002:

>=20
> 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.
>=20

Ok, first off before *anyone* else responds to this thread, read the pages
at http://mc.pp.se/dc/vms/flashmem.html and
http://mc.pp.se/dc/vms/fileheader.html to gain an understanding of what's
being discussed.

Your above paragraph: think about it.  If I copy a file from VMU, say to
/tmp, and perform an edit or some other operation that changes the size of
the file, what happens to that extra info that was stored elsewhere?

It's invalid and the file (w.r.t to the VMU) is worthless.  The only way
that works is if the editing tool understands the extra little files and
directorires and can update them as soon as the main file is updated.  That
isn't realistic.

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

Heh, have you done Linux kernel development, in particular VFS development?
Do you know the headaches that Adrian has been through getting his driver
to work?  Doing a userspace (cross-platform is an extra bonus)
implementation would simplify things greatly - all data remains intact when
transferring between vmus and the code becomes more than trivial.  Besides,
what do you think the VFS driver is doing with this "hokey little system"?

The only disadvantage is a non-intuitive way to access file data, but at
least it's compatible with every other vmufs implementation (including the
DC browser itself) outside of Linux.

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

See my last couple of paragraphs.

>=20
> 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.
>=20

At my former university, every student had an account and disk space on a
Unix system.  In each lab, the workstations would map this disk space so
that students could save documents, etc. there.  On the Macs, because they
use "extra" info for their filesystems, they tended to create an ".afpvol"
directory that was hidden as long as you accessed that share on a Mac.

I spent a lot of my time under Unix and I typically trimmed my directory
because of the quota imposed.  What do you think I did with the Mac-created
=2Eafpvol?  rm -rf.  Could the Mac HFS do anything with this info any more?
No.  Did it become problematic when accessing that share on the Mac again?
Just a little, since it held type/creator information and other
HFS-specific bits that made the file recognizable under the Finder.

I say all that to hopefully get you to see that vmufs-specific data will
only ever make sense or be usuable by vmufs - other filesystems could care
less about that extra information, _wherever_ it's stored.

> 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...=20
>=20

vmufs is a block-oriented filesystem.  You can't do magic things that are
persistent because in the end, you're writing to a block device: whether
it's the VMU mapped over MTD, a raw 128k dump of the VMU, or something
else.

As soon as you modify the raw block data in a non-consistent manner, you no
longer have vmufs.

You can always present a special interface to the user, but see above as to
why this won't persist across filesystems.

M. R.