Date: Mon, 20 Sep 1999 11:19:19 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Justin T. Gibbs" <gibbs@caspian.plutotech.com> Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern vfs_bio.c Message-ID: <199909201819.LAA83048@apollo.backplane.com> References: <199909201734.LAA00382@caspian.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> If both B_INVAL and B_ERROR are set the buffer is typically out of the
:> underlying device's block range and must be destroyed. If only B_ERROR
:> is set (for a write), a write error occured and operation remains as it
:> was before: the buffer must be redirtied to avoid corrupting the
:> filesystem state.
:
:If a device "goes away", how should any pending buffers be marked? Does a
:umount -f cause pending buffers to be B_INVAl'ed? I'm pretty sure that
:we still can't rid the system of the knowledge of a mounted fs for a device
:that has disappeared, but I haven't checked recently.
:
:--
:Justin
At the moment vinvalbuf will write out any dirty buffers, so this is
unrelated to the B_INVAL bit, which isn't set yet at this point. The
unmount code still calls vinvalbuf with V_SAVE, which is correct,
so a forced unmount should not make things work any differently.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909201819.LAA83048>