Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbosgd!gatech!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.bugs.2bsd
Subject: Re: Bug in umount code
Message-ID: <448@umcp-cs.UUCP>
Date: Sun, 23-Mar-86 12:27:03 EST
Article-I.D.: umcp-cs.448
Posted: Sun Mar 23 12:27:03 1986
Date-Received: Tue, 25-Mar-86 04:43:34 EST
References: <1307@mit-eddie.MIT.EDU> <2713@pucc-h>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 27
Keywords: umount block cache slow devices

In article <2713@pucc-h> ach@pucc-h.UUCP (Stephen Uitti) writes:
>[A bug in umount] is not a bug that's limited to 2.9.  It's
>probably found everywhere, and has existed from the dawn of
>time.

It is not present in 4.2 or 4.1, and probably was not in 4.1 (though
I have to admit I never was familiar with the 4.1 code).  The
`proper' way to fix it is clear; indeed, there is a comment in the
4.2 and 4.3 ufs_bio.c that reads as follows:

/*
 * Invalidate in core blocks belonging to closed or umounted filesystem
 *
 * This is not nicely done at all - the buffer ought to be removed from the
 * hash chains & have its dev/blkno fields clobbered, but unfortunately we
 * can't do that here, as it is quite possible that the block is still
 * being used for i/o. Eventually, all disc drivers should be forced to
 * have a close routine, which ought ensure that the queue is empty, then
 * properly flush the queues. Until that happy day, this suffices for
 * correctness.                                         ... kre
 */

`kre', of course, is Robert Elz.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu