Subject: Re: Detaching live sd devices
To: Hubert Feyrer <hubert@feyrer.de>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 07/25/2005 09:32:14
--G4iJoqBmSsgzjUCe
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 24, 2005 at 10:35:10PM -0500, David Young wrote:
> On Sun, Jul 24, 2005 at 10:34:37PM +0200, Hubert Feyrer wrote:
> > On Fri, 22 Jul 2005, Bill Studenmund wrote:
> > >Thoughts? I have a few, but I'd appreciate input.
> >=20
> > I thought about removing USB sticks andy why one can ~safely pull them=
=20

Interesting. I'm looking at disks that are on a SAN.

> > after writing on Windows the other day, but I don't have the needed=20
> > kernel-know-how to describe an implementation. Anyways: right now it's=
=20
> > only safe to remove media (disk, stick ...) when the filesystem is=20
> > unmounted. On umount(2), all data is synced to disk first. So the "unsa=
fe"=20
> > period is between mount and umount.
> >=20
> > Now my idea is: why not make the "unsafe" period shorter, e.g. between=
=20
> > open and close, or maybe even before&after read/write/etc.?

Because you'll increase wear and tear on the device, and reduce=20
performance. Strictly speaking, we would have to perform an unmount/mount=
=20
pair at the edges of the "safe" period you want. That will mean writing a=
=20
lot of stuff that we wouldn't need to write otherwise (we would end up=20
continually updating the superblocks and we would probably re-write inodes=
=20
more than otherwise).

> > I don't know if that makes sense and there are probably many details I=
=20
> > don't know, but that was the general idea...
>=20
> Hubert,
>=20
> We can also think of this as a type of usability problem: dirty buffers
> are not "visible" to the operator.  One possible remedy is to add a device
> node /dev/dbufs from which daemons can read the number of dirty buffers
> on each removable storage device.  The daemons can render an unobtrusive
> "dirty buffer meter" on the system console or in an X window, or else
> they can light a keyboard LED.  It is "media safety" at a glance. [1]
>=20
> Sometimes the operator is in a race with some process to remove the media
> before more buffers are dirtied.  A useful adjunct to /dev/dbufs is a key
> that you can press and hold to prevent buffer-dirtying on removable media
> (remount read-only?) until you release the key (remount read-write?).

Why not just unmount the stick before disconnecting it?

I think we'll be better served to make it easier for the user to unmount a=
=20
memory stick than to add all of this other complexity.

While dirty buffers are a big part of the issue, they aren't all of it. To=
=20
unhook the stick, you really should have the file system shut itself down.

Take care,

Bill

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

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

iD8DBQFC5RQNWz+3JHUci9cRAs3gAJ4gD1SnoXDQy43kSnZ6A1acSiRd7ACfQZQt
FQlIkR6KGij+JzHIn6KPTd4=
=C/px
-----END PGP SIGNATURE-----

--G4iJoqBmSsgzjUCe--