Matthew Dharm wrote:
>
> 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.
I think it is time to ask again. I'll see if I can dig up the previous
discussions from the linux-kernel archives. If any of you have a T1-T3
or ADSL connection and care to do this research, I'd appreciate it.
I am struggling along at 56K for another three months! :-)
I think having a good solution for ensuring that all data is written
to removable media is essential for success with this aspect of USB
support. I'd love to know how this is dealt with for ZIP/JAZZ drives.
> > > 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.
It is a soft eject button. Again, I am simply wanting an implementation
(usermode or kernelmode) that enables easily shuttling disks between
machines running different operating systems where:
Pressing the Eject button causes the media to eject
if it is not being accessed.
and
The information that I thought I wrote to the disk is completely
written whenever the media is ejected.
Your implementation for handling the USB cable being unplugged while
the drive is in use is great. Eventually, we should have a usermode
program that pops up a warning that a write is incomplete in this case.
Then the user could plug the drive back in to get the rest of the
file(s).
Miles
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
