In <14514.51903.585403.885700@dukat.scot.redhat.com> Stephen C. Tweedie (sct@redhat.com) wrote:
ST> Hi,
ST> On Tue, 22 Feb 2000 02:25:25 +0300 (MSK), Khimenko Victor
ST> <khim@dell.sch57.msk.ru> said:
>>> Why? I see no problem with the semantics, "you remove an active floppy,
>>> all outstanding activity is lost." As long as the kernel doesn't defer
>>> IO unnecessarily, that's just fine.
>> Ok, it's fine for DOS where all activity come from user. It's NOT Ok for
>> multiuser OS with "it's own life" (deamons :-) like Linux.
ST> If you have the O/S playing around in the background on removable media,
ST> then you have other problems.
This is Linux. If removable media is in active use O/S WILL play with it
in the background eventually. If it's not in active use then the whole
problem is moot in first place.
ST> I don't think that's a valid objection --- quite the opposite, in a
ST> multiuser environment you _have_ to avoid prompting the user to recover
ST> from a media-change event.
If system can not ask user then user must ask system :-) I can not believe
that such talks are going on lkml: do you really not know what happens when
some operation is done without acuiring proper lock ???
>>> The old behaviour of some desktop OSes of tracking multiple "mounted"
>>> floppies at once arose in the times when many machines had nothing
>>> _except_ floppy drives, and good management of multiple concurrent
>>> floppies was very important. That no longer applies.
>> You either 1) have no need for "good management of multiple concurrent
>> floppies" and can tolerate complex procedures or 2) you are working
>> constantly with multiple concurrent floppies and thus NEED "good
>> management of multiple concurrent floppies".
ST> Exactly. Nobody has given me a convincing reason why we need seamless
ST> support for multiple concurrently-mounted floppies.
We need it IF we want to avout explicit unmounting.
>> If first case mount/umount should be enough, in second case you need
>> proper solution to problem, not just something that "works
>> sometimes". "Good enough" can be enough for Microsoft but it's NOT
>> enough for Linus. Solution MUST be bullet-proof
ST> This is where you are being completely inconsistent. mount/umount is
ST> not bullet-proof for your first case (one removable media at a time)
ST> either.
Huh ??? How you can corrupt anything with proper umount usage ? unmount is
EXACTLY command to system "stop playing with my floppy, I want to eject it".
ST> So far your argument seems to be that it's OK to lose data as
ST> long as you only lose it on one disk at once.
My argument is that it's NOT ok to lose data when "all is done right".
With manual unmount you CAN NOT lose data when you are doing everything
right (that is: you do not pull floppies without unmounting them first).
With supermount there are NO WAY guaranetee that data will not be corrupt.
ST> mount/umount is _not_ good enough for single floppies. We can make it
ST> good enough without the overkill of something like Sun's vold.
HOW ??? I repeat: if there are exist EVEN smallest chance to get corrupted
data on floppy when everithing is "done right" it's not a solution. It's
kludge at best.
>>> But I don't. A removed floppy is _gone_.
>> So you data on floppy with corruped filesystem is gone as well. If you
>> do not need that data then why was floppy needed in first place ?
ST> Sheesh. If the user wanted the data saved to the disk, then why did
ST> they remove the disk while it was being written?
Since is OS like Linux user is NOT the only source of activity around
filesystem. User saved data to the disk allright. And then some background
daemon spoiled the whole party. With mount/unmount (or rather autofs/umount:
there are no problem with automatic mounting, just with automatic DISmounting)
you can GUARANTEE that data will not be corrupt.
-
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 : Wed Feb 23 2000 - 21:00:31 EST