Date: Sat, 19 Apr 2003 23:50:48 +0200 From: Marko Zec <zec@tel.fer.hr> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-stable@FreeBSD.org Subject: Re: PATCH: Forcible delaying of UFS (soft)updates Message-ID: <200304192350.48576.zec@tel.fer.hr> In-Reply-To: <3EA1B72D.B8B96268@mindspring.com> References: <3E976EBD.C3E66EF8@tel.fer.hr> <200304192134.51484.zec@tel.fer.hr> <3EA1B72D.B8B96268@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 19 April 2003 22:53, Terry Lambert wrote:
> You are still missing the point.
>
> If I have 30 entries each on 2 queues, the rest of the system
> gets an opportunity to run once between what might be significant
> bouts of I/O, which is the slowest thing you can do.
>
> If I have 2 entries each on 30 queue, the rest of the system
> gets an opportunity to run 29 times between much less significant
> bouts of I/O (1/15th of the latency).
>
> So the difference is between the disk spinning up and the system
> freezing for the duration, or the disk spinning up and the
> system freezing unnoticbly to the user for 1/10th of a second
> per worklist for a larger number of worklists.
>
> Add to this that the batches of I/O are unlikely to be on the
> same track, and therefore there's seek latency as well, and you
> have a significant freeze that's going to appear like the machine
> is locked up.
Does the laptop owner care if the system freezes for a couple of miliseconds
more than usual? If you have tried the patch yourself, you would certainly
observe that the freeze you are talking about is completely unnoticable. Even
under the highest loads, my system can accumulate at most around 300 dirty
buffers before starting to sync for one reason or another. Modern ATA disks
posess a significant amount of RAM available for write caching, which will
compensate even for such write bursts. Therefore the disk head seek latency
you mentioned won't be noticeable in most cases.
> Your changes makes it so the insertion *does not* put it in a
> different slot (because the fsync is most likely delayed).
^^^^^
> Therefore we are *not* safe.
Again, in my understanding the (modified) fsync() handler is completely
unrelated to the (unmodified) sync_fsync() function.
> The other FS corruption occurs because you don't specifically
> disable the delaying code before a shutdown or umount or mount
> -u -o ro, etc..
Such a problem simply does not exist. Please try out the patch, enable the
delaying, fill in as much dirty buffers as possible, and unmount the FS. You
will notice that a) all the dirty buffers will be automatically written to
the disk; b) the unmount operation will succeed; c) the system will not crash
and d) the FS will be perfectly consistent at the next mount.
> My analysis (and several other people's) differs from yours.
>
> > and from my experience with a production system
> > running all the time on a patched kernel.
>
> This is totally irrelevent; it's anecdotal, and therefore has
> nothing whatsoever to do with provable correctness.
No offence please, but your argumentation would look much more convincing if
you could provoke a system crash with the patch enabled, and then provide a
backtrace. If the patch is as bad as you are suggesting, that shouldn't be
that hard to do, should it?
Marko
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200304192350.48576.zec>