Search year 2000 lkml archives for
"Of removable media" and "Of removable devices" threads.
That should fill up one of your days this weekend.
I recall the results basically the same as Matt and Greg did.
~Randy
___________________________________________________
|Randy Dunlap Intel Corp., DAL Sr. SW Engr.|
|randy.dunlap.at.intel.com 503-696-2055|
|NOTE: Any views presented here are mine alone |
|and may not represent the views of my employer. |
|_________________________________________________|
> -----Original Message-----
> From: Miles Lane [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 07, 2000 12:00 PM
> To: Matthew Dharm
> Cc: Vojtech Pavlik; Alessandro Rubini; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: [linux-usb] USB usage count?
>
>
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
