PATCH: Forcible delaying of UFS (soft)updates

[Terry Lambert]

Marko Zec wrote:
> Does the laptop owner care if the system freezes for a couple of miliseconds
> more than usual?

I am a laptop owner.  I care.

> If you have tried the patch yourself, you would certainly observe
> that the freeze you are talking about is completely unnoticable.

I run 13 jails for 12 virtual machines on my laptop.  I noticed.


> Therefore the disk head seek latency you mentioned won't be
> noticeable in most cases.

Define "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.

You're wrong.  You have to take into account both the vnodes on
the FS, and the vnodes that the FS is mounted on on devfs.


> > 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.

This is not true.  I've proved it by corrupting an FS by holding
down the power button on my laptop to force an ATX power-off, with
no recourse.  This is the same type of failure that could occur on
a normal laptop when battery output drops the power out from under
you.

The basic problem is that the forces fsync is no longer forced.


> > 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?

I've done it.  I guess you want me to do it again, citing that
absence of evidence is not evidence of absence?

The problem her is well understood.  Rather than arguing further,
I will offer a modification of your patches.

Note that this modification is still unsafe, due to the lack of
a "force" flag for the fsync in the unmount and mount -u cases;
give me a couple of days, since I test patches before I post
them (normally 2 weeks; I'll make an exception in this case).

-- Terry