In <14516.26473.352094.331866@dukat.scot.redhat.com> Stephen C. Tweedie (sct@redhat.com) wrote:
ST> Hi,
ST> On Tue, 22 Feb 2000 21:54:30 +0300 (MSK), "Khimenko Victor"
ST> <khim@sch57.msk.ru> said:
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> Sure, but a background search job like slocate should be perfectly happy
ST> if it simply starts getting IO errors while scanning recursively down a
ST> suddenly-removed media. That's the clean behaviour --- the media was
ST> removed, and any further access to the removed filesystem results in a
ST> clean EIO return to the application.
What if said daemon keep results on floppy (findfast again) ? Not all
filesystems can safely tolerate removal of floppy with files opened for
writing...
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 :-)
ST> No. In a multi-user O/S, such media/drive failures have to be handled
ST> automatically. There really isn't scope for much in the way of user
ST> interaction for two reasons. First, if you just buffer dirty data until
ST> the user happens to restore the disk, then you are wide open to
ST> denial-of-service attack as the user has effectively pinned a large
ST> amount of dirty data in memory.
1. Not so large. 2. You can limit this amount (of course slocate should be
suspended till floppy is inserted back).
ST> Secondly, the user may accidentally remove a disk early (while data is
ST> still being written) and just walk away. The O/S has to recover -- that
ST> user may not be back for a week.
Thus window should have not only "Ok" button but also "Cancel" button.
Or daemon can be tuned to not even ask user. If the ONLY possible user's
action is to remove floppy and go away, then yes, there are no point in
asking user. Unfortunatelly this is NOT the only case. Not for destop
system, not for server system. It's typical situation only for cybercafe
or services like cybercafe IMHO.
>> 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 ???
ST> What has locking to do with it? We are specifically talking about
ST> drives which cannot do proper door locking.
Exactly. We have two concurrent operations: write to floppy and floppy
removal. If we need reliable work we need spinlock (sort of). Since there are
no way to do "spinlock" in hardware we need "spinlock" in software. umount
is way to accuire "spinlock" for removal. Since this operation (removal) can be
reverced if done in wrong time we can do "speculative removal" without
accuiring "spinlock" but then we need to perform reverse operation with help of
daemon if in fact spinlock was held by other operation. That's how it looks
from system viewpoint. This is "spinlock" I talked about above, not drive
lock :-) If you have drive locking you can implement "spinlock" in hardware,
of course.
ST> (Supermount already deals cleanly with drives whose door locking is
ST> reliable.)
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> Because the floppy can be ejected before the user does a umount.
If floppy was ejected without umount then user violated instruction and no
blames can go on Linux. User can blame ITSELF for forgetfullness but not Linux.
ST> Just prompting for it to be reinserted is inadequate, for the reasons above.
Arrrgggh. Lets see:
1. RedHat 10.0 includes supermount and it's on by default.
2. User ejected floppy with corrupted document.
3. He sues RedHat for 10'000'000$ and claims (rightfully) that there are
NO violated points in instruction.
Is it Ok for you ? Not for me. At least with umount accurate user can guarantee
that data will not be corrupt. With pop-up windows such gurantee is also exist.
With supermount there are NO such guarantee.
-
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 : Tue Feb 29 2000 - 21:00:09 EST