Date: Mon, 18 Jul 2005 17:14:11 +0200 From: Matthias Buelow <mkb@incubus.de> To: Paul Mather <paul@gromit.dlib.vt.edu> Cc: freebsd-stable@freebsd.org, Matthias Buelow <mkb@incubus.de> Subject: Re: dangerous situation with shutdown process Message-ID: <200507181514.j6IFEBoR001237@drjekyll.mkbuelow.net> In-Reply-To: Message from Paul Mather <paul@gromit.dlib.vt.edu> of "Mon, 18 Jul 2005 10:59:39 EDT." <1121698779.51580.15.camel@zappa.Chelsea-Ct.Org>
next in thread | previous in thread | raw e-mail | index | archive | help
Paul Mather <paul@gromit.dlib.vt.edu> writes: >Why would that necessarily be more successful? If the outstanding >buffers count is not reducing between time intervals, it is most likely >because there is some underlying hardware problem (e.g., a bad block). >If the count still persists in staying put, it likely means whatever the >hardware is doing to try and fix things (e.g., write reallocation) isn't >working, and so the kernel may as well give up. So the kernel is relying on guesswork whether the buffers are flushed or not... >You can enumerate the buffers and *try* to write them, but that doesn't >guarantee they will be written successfully any more than observing the >relative number left outstanding. That's rather nonsensical. If I write each buffer synchronously (and wait for the disk's response) this is for sure a lot more reliable than observing changes in the number of remaining buffers. I mean, where's the sense in the latter? It would be analogous to, in userspace, having to monitor write(2) continuously over a given time interval and check whether the number it returns eventually reaches zero. That's complete madness, imho. mkb.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200507181514.j6IFEBoR001237>