🚀 go-pugleaf

In article <1307@mit-eddie.MIT.EDU> jfw@mit-eddie.MIT.EDU (John Woods) writes:
>There appears to be a bug in umount on slow devices (and in principle on
>faster ones).  umount invalidates the entries in the buffer cache by setting
>their b_dev field to -1.  However, slow devices like RK05s and RX02s, when
>they finally get around to looking at these entries some time later, find
>that they point to non-existant devices (like minor device 7 in the case of
>the RK05).  Is there a standard fix for this problem?
>-- 
>John Woods, Charles River Data Systems
>decvax!frog!john, mit-eddie!jfw, JFW%mit-ccc@MIT-XX

	Yes.  This is not a bug that's limited to 2.9.  It's
probably found everywhere, and has existed from the dawn of
time.
	I remember reading a note from someone at Digital
Equipement Corp, saying he'd fixed the bug.  He said something
like, "it was a pain to fix, and required several tries to get
it right", but gave no real hints on how to fix it, other than
he said that "sumount" should wait until all the blocks are
written out (after the call to "update" (internal name for
sync) (which schedules the writes but returns immediately))
before the file systems are actually unmounted.
	Actually, maybe the solution is to have "update" wait
for the I/O to finish, so a command line "sync" really does
what you want it to do.
	I haven't looked at the problem other than to verify
that it exists.  I have been bitten by the bug with rk07's.  I
ran "umount", then physically unmounted the pack, then mounted
a new pack, at which point, the kernel finished it's writes.
The new pack's file systems were completely screwed up.
	Stephen Uitti, Purdue University Computing Center.
	ach@pucc-j.