On Thu, 6 Apr 2000, Miles Lane wrote:
> 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.
This issue has been brought up on linux-kernel several times. Nobody has
proposed a good solution yet, and it usually come down to a holy war of
some kind.
> > 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.
The SCSI layer sends a ALLOW_MEDIA_REMOVAL command to the drive to attempt
to lock it before accessing it. If the ORB drive has a soft eject button,
then it shouldn't work until the SCSI layer unlocks the drive
electronically.
If it has a hard eject button, then all bets are off.
Matt Dharm
--
Matthew Dharm Home: [EMAIL PROTECTED]
Engineer, Qualcomm, Inc. Work: [EMAIL PROTECTED]
I don't have a left mouse button. I only have one mouse and it's on my right.
-- Customer
User Friendly, 2/13/1999
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
