Manfred Spraul wrote:
> What do you mean with "everything is written"?
> The problem is not the filesystem metadata. We could use O_SYNC or
> O_SYNC_METADATA. The problem is user space: what if the user forgot to
> write a file? Revoke the file handles from the editor and tell the user
> "please type the text again!"?
The editor will write to /floppy/my_file. And /floppy is always a
symbolic link to the currently inserted floppy-volume, right?
If I write a file, save it, remove and insert a different floppy, and
save the file again, I want the second save to write to the new floppy.
Usually I *don't* want the system to insist that I insert the old floppy.
If there is no floppy in the drive, I would expect the editor to point
out the failure to save. I can insert a floppy and try again.
As it happens, even with your multi-volume scheme I will get that
behaviour because the editor always writes to /floppy anyway.
> What if a database with a complex file structure is stored on the disk?
If it's a database it can keep open a directory handle on that disk.
When the disk is removed, the handle is revoke()d as are any open files,
and further operations by the database program fail. (It's possible to
hook these failures in user space if you want to implement a volume
daemon).
In generally I expect users would do "cp file /floppy" and "cp
/floppy/file ." or equivalent, as well as "ls /floppy" and "cd /floppy"
etc.
In your multi-volume scheme, "cd /floppy; do_stuff" would keep operating
on the same physical disk. Whereas "cp file /floppy" and "cp
/floppy/file ." would always operate on the currently inserted disk,
rather like mtools.
I think the latter commands are quite common. So in many common cases,
the multi-volume feature is defeated anyway.
It's unclear whether GUIs would see the multiple volumes or not. It
depends on the file manager implementation. File managers that cd into
the /floppy directory would track the volume they display, but file
managers that simply use path names without expanding links would not.
I guess most file managers are of the latter kind -- i.e. would not see
multiple volumes.
So again multi-volume is defeated -- GUIs don't see it and many command
line operations don't see it.
For GUIs, that means multi-volume has to be supported explicitly. If
it's going to be explicit, you can already do this (have the file
manager verify the disk before every operation on it). We could
make it easier for userspace to call "verify disk" perhaps.
But if you really still want multi-volumes, a "revoked handle accessed"
hook in the kernel would be enough to write a complete volume daemon on
top of what I have proposed for changeable media handling.
have a nice day :-)
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:24 EST