In message <20040521185830.GO3452@bcd.geek.com.au>, Daniel Carosone writes:
>
>--sBcizk6cgRZY6rnJ
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>On Fri, May 21, 2004 at 02:10:19PM -0400, Steve Bellovin wrote:
>> I did, however, encounter another problem that I worked around but=20
>> haven't fixed; this problem requires more thought, which is why I've=20
>> redirected the thread to tech-kern: on a device like this, on the last=20
>> close(), power is removed from the drive before any final writes can=20
>> finish.  Thus, if I unmounted a file system, the superblock wouldn't be=
>=20
>> marked clean, and fsck would run the next time.
>
>Nasty.
>
>> I finally worked around the problem by running
>>=20
>> 	sleep 99999 </dev/rwd1a
>>=20
>> in the background.
>
>Another workaround, and interesting test, would be to turn off
>write-cache on the drive:
>
>	dkctl wdX setcache r
>
>and then try the unmount.  I'm hoping/assuming this would wait for the
>superblock write to complete.  Could you try this?  If it does, then
>building the moral equivalent of
>
>	dkctl wdX synccache force
>
>into the close is the right way to fix this.  It even seems to me like
>if we don't do this, there might be other similar lossage cases
>lurking than the pcmcia one you found.

Yup -- I worry about USB disks, for example.

I'll try the dkctl stuff tonight.  I thought I'd seen some such option, 
but the command I remembered was atactl, and its man page doesn't have 
a pointer to dkctl, nor does wd(4).  Those latter two point to each 
other, however.
>
>(For removable devices that might get unexpectedly yanked, running
>without write cache, and perhaps mount -o sync, might also be a good
>idea - but that should remain a user preference for appropriate
>circumstances.)
>

Agreed.

		--Steve Bellovin, http://www.research.att.com/~smb