Date: Mon, 18 Jul 2005 12:18:52 -0400 From: Paul Mather <paul@gromit.dlib.vt.edu> To: Matthias Buelow <mkb@incubus.de> Cc: freebsd-stable@freebsd.org Subject: Re: dangerous situation with shutdown process Message-ID: <1121703532.51580.35.camel@zappa.Chelsea-Ct.Org> In-Reply-To: <200507181514.j6IFEBoR001237@drjekyll.mkbuelow.net> References: <200507181514.j6IFEBoR001237@drjekyll.mkbuelow.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2005-07-18 at 17:14 +0200, Matthias Buelow wrote:
> 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...
I don't know if you are just deliberately trying to be contentious, but
that is a serious misrepresentation of what is happening. Quite
obviously the kernel knows whether a buffer has successfully been
flushed, otherwise a count of outstanding buffers would be meaningless.
(Surely you're not saying the kernel simply guesses if a buffer has been
flushed in maintaining its count of outstanding buffers? What would be
the point of that?)
If you calm down and think about it for a little, you'll realise what
you suggest to do and what is actually done amount to the same thing in
practical terms.
It's all very easy to say to "write each buffer synchronously (and wait
for the disk's response)," but what do you do when the buffer *does* get
stuck and won't complete (e.g., because someone removed the floppy or
USB disk, or your remote ggate server disappeared, or your hard disk is
going bad, etc.)? Do you just bail immediately at that point? Or do
you keep retrying in the hope it will complete? In the end, it comes
down to waiting a certain amount of time for drivers to do their best
and then giving up. The only real question is how long you wait, and
maybe whether syncer is not waiting long enough (and hence how to extend
the amount of time it is willing to wait until it gives up on buffers
being unflushable). I'm not sure why that is fundamentally "madness."
Cheers,
Paul.
--
e-mail: paul@gromit.dlib.vt.edu
"Without music to decorate it, time is just a bunch of boring production
deadlines or dates by which bills must be paid."
--- Frank Vincent Zappa
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1121703532.51580.35.camel>