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--