PATCH: Forcible delaying of UFS (soft)updates

Marko Zec zec at
Sat Apr 19 14:51:10 PDT 2003

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?


More information about the freebsd-stable mailing list