All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jim Crilly <jim@why.dont.jablowme.net>
To: Rob Love <rml@ximian.com>
Cc: Joshua Schmidlkofer <kernel@pacrimopen.com>,
	"David B. Stevens" <dsteven3@maine.rr.com>,
	Helge Hafting <helgehaf@aitel.hist.no>,
	Jos Hulzink <josh@stack.nl>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: 2.7 (future kernel) wish
Date: Sat, 27 Dec 2003 22:19:53 -0500	[thread overview]
Message-ID: <3FEE4BD9.5000000@why.dont.jablowme.net> (raw)
In-Reply-To: <1072581073.4042.10.camel@fur>

Rob Love wrote:
> On Sat, 2003-12-27 at 22:03, Jim Crilly wrote:
> 
> 
>>Generally it just complains that you pulled out the device prematurely, 
>>I've never seen one give a STOP error from that but I guess a bad driver 
>>or USB controller could cause anything.
> 
> 
> It would be pretty easy to screw things up if you pull out a device in
> the middle of use.
> 
> 
>>When you insert a device like a USB stick Windows puts a little icon 
>>next to the clock in the system tray that you're supposed to use to stop 
>>the device before pulling it, effectively it unmounts and stops (or 
>>atleast releases the device from) the driver so the device can be 
>>'safely' removed.
> 
> 
> This is useful, and something I think we need on the Linux desktop (stay
> tuned).
> 

I agree, that's one of the reasons I posted at all. Little things like 
this can make a big difference, even though I've seen a lot of users not 
notice the little icon and have to be told about it.

Maybe when the icon appears have a tool-tip that pops up and says 
something like "your USB device is ready for user at /mnt/usb, click 
here when you're done" or something like that to make it more noticable 
that they shouldn't just yank it.

But I seem to be getting OT for this list...

> 
>>I also believe Windows mounts any removable device 
>>synchronously so that if you do pull it out prematurely the damage done 
>>is limited.
> 
> 
> Eww, I hope not, that would be excruciatingly slow.  It might adjust the
> buffer writeback to be really short (even nearly immediate) but
> synchronous I/O is a different story, and much slower.
> 
> 	Rob Love
> 
> 

Perhaps synchronous was the wrong term =) But it does atleast seem to do 
less buffering for removable devices or I could just be fooled by 
something else slowing it down.

  reply	other threads:[~2003-12-28  3:20 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-23 22:42 2.7 (future kernel) wish Jos Hulzink
2003-12-26 23:38 ` Helge Hafting
2003-12-26 23:57   ` David B. Stevens
2003-12-27  6:51     ` Joshua Schmidlkofer
2003-12-28  3:03       ` Jim Crilly
2003-12-28  3:08         ` Kevin P. Fleming
2003-12-28  3:13           ` Rob Love
2003-12-28 11:17           ` Kevin Krieser
2003-12-28 11:23             ` Gaël Le Mignot
2003-12-28  3:11         ` Rob Love
2003-12-28  3:19           ` Jim Crilly [this message]
2004-01-04 21:05             ` Pat Erley
2003-12-28  3:57         ` Joshua Schmidlkofer
2003-12-28  4:33         ` Elladan
2003-12-30 14:20         ` Helge Hafting
2003-12-31  0:18           ` Jim Crilly
  -- strict thread matches above, loose matches on Subject: below --
2003-12-30 15:41 Pacheco Jason NPRI
2003-12-30 16:18 ` mjt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3FEE4BD9.5000000@why.dont.jablowme.net \
    --to=jim@why.dont.jablowme.net \
    --cc=dsteven3@maine.rr.com \
    --cc=helgehaf@aitel.hist.no \
    --cc=josh@stack.nl \
    --cc=kernel@pacrimopen.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rml@ximian.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.