--xgyAXRrhYN0wYx8y
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 26, 2005 at 12:18:42AM -0500, David Young wrote:
> On Mon, Jul 25, 2005 at 12:24:57PM -0700, Bill Studenmund wrote:
> > On Mon, Jul 25, 2005 at 01:26:24PM -0400, Steven M. Bellovin wrote:
> > > Of course, DOS/Windows has gone the other way -- you never needed to=
=20
> > > tell the OS anything when you removed a floppy drive, but you do need=
=20
> > > to "stop" a USB disk or PCMCIA device before removal.  I believe the=
=20
> > > same is true on MacOS.
> > >=20
> > > In other words, maybe people shouldn't have to do it, but on most=20
> > > modern systems they do; it's not a new concept except, perhaps, for t=
he=20
> > > word "unmount".
> >=20
> > I agree. While I think the user should have to go through a manual step=
, I=20
> > think that we can make it easy for them. The "eject" command will do an=
=20
> > unmount if you pass it the -f option. So it shouldn't be hard to create=
 a=20
> > tool that can help users eject media. :-)
>=20
> Bill,
>=20
> Why do you think the user should go through a manual step before they
> remove media or unplug a device, if we can conceive of a system where
> we save the user both the time and the effort?  I would say that there

Because to do this means we either have to continually mount and unmount=20
the volume or we risk having to deal with dirty file systems. Yes, fsck=20
probably won't take long, but there's not really a way to get around it.=20
Hmmm... Actually, as CFs are getting big, you could end up with a=20
noticable fsck delay. Not bad, but multiple minutes.

Also, it will always be a race. Just because a CF or whatever is clean
when I look at a prety display doesn't mean it will be clean when I pull
it out.

I guess I'm also very familiar with unmounting devices under MacOS. It's=20
really rather trivial.

> is pretty good evidence (both concepts and prior art) in the discussion
> that we can save the time and effort:
>=20
>         (1) improve visibility: indicate whether the media is in a "safe"
>             condition or not, by displaying a "dirty buffers meter" or a
>             "do not remove media" indicator

But the file system is still dirty. And you'll always run a race.

Also, if you have gone to the effort to make an application that can tell
if a device has dirty buffers, why not just add an eject button? It's
simpler and easier to tell a device is removable and support the "eject" =
=20
command than to add all the complexity (kernel and userland) to tell if it=
=20
has dirty buffers.

>         (2) anticipate hasty ejection: flush s/w buffers, h/w caches
>             to the media after 1-2s

If your media has a limited life (say CF) you will most likely end up=20
writing data multiple times and increasing wear on the device.

>         (3) recover gracefully: if the user removes the media (or unplugs
>             the device) prematurely, tell them so; hold the unwritten
>             buffers; detect when the media/device is replaced using a
>             unique media/device ID; flush the buffers

While I like this idea, it is a very difficult thing to do for us. We=20
would have to migrate to locators that are tied to a specific device, not=
=20
its location or probe order. Otherwise we don't know if/when the device=20
comes back. Devices have the identifiers needed to handle this, we just=20
don't use them.

I think step 3 would be good, it just isn't easy.

Take care,

Bill

--xgyAXRrhYN0wYx8y
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFC57yJWz+3JHUci9cRAmmFAJ9EqRlsdJGBc067MwvREVQbE1sPGwCcCvMj
mxO8MpE6O8/8N63nmyEM3V0=
=lOAk
-----END PGP SIGNATURE-----

--xgyAXRrhYN0wYx8y--