Matthew Dharm wrote:
>
> On Thu, 6 Apr 2000, Miles Lane wrote:
>
> > Speaking of USB devices that are not always in use, what are we going
> > to do to make using mountable removable media easy? I am referring to
> > the differences between how Linux treats removable media and how
> > Windoze/Mac does. For example, when you write a file to the Castlewood
> > ORB drive using usb-storage, that file may not have actually been fully
> > written. I have seen a case when I had copied a directory tree to the
> > ORB drive, moved the drive to a Windoze machine and discovered that
> > half of the files where 4KB.
> >
> > I haven't really checked, but are we handling the case where a storage
> > device is disconnected without the usual "sync"/"umount" cycle? Is
> > there a way for us to do this? I notice that folks are working an the
> > automount portion, but I haven't seen discussion of unmounting.
>
> Because of the way linux can cache disk access, you're pretty much screwed
> here. If it's a dos/vfat filesystem, I just use mtools to access it --
> that avoids the problem.
Have you tried bringing this up on the linux-kernel list to see if
anyone
has a good solution? Perhaps some sort of flag can be set to indicate
which drive resources ought to have writes not cached for more than
some reasonable period of time. I would really like to see removable
media drives be robust and reliable data storage options for Linux USB.
> The SCSI layer will keep the module usage count non-zero if it still needs
> the device. That seems to be the best behavior I can find for usb-storage
> -- it acts like any other SCSI driver.
Right.
> Oh, and if you yank a drive while it's in use, the driver will report "not
> ready" in the hopes that you'll reconnect the drive. If you do, it
> _should_ be able to start back up.
This is great. One other missing piece though, is that usb-storage
(or some usermode driver) needs to detect when an eject button has been
pressed on the ORB drive. Then, unless a write or read operation is in
progress, the drive should be unmounted and the media allowed to eject.
At least, I think this is how it should work. I don't know if the drive
sends a signal to the driver that the eject button has been pressed.
It may be that the drive itself checks whether any activity is taking
place and then ejects the media if possible.
Miles
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
