PATCH: Forcible delaying of UFS (soft)updates

[Dave Hart]

Marko Zec said:
> Alfred Perlstein wrote:
> 
> > * Marko Zec <zec at tel.fer.hr> [030411 19:01] wrote:
> > >
> > > When enabled, the extended delaying policy introduces 
> > > some additional changes:
> > >
> > > - fsync() no longer flushes the buffers to disk, but 
> > > returns immediately instead;
[...]
> > Making fsync() not work is a good way to make any sort
> > of userland based transactional system break badly.
[...]
> If the disk would start spinning every now and than,
> the whole patch would than become pointless...

As I feared.

> [...] the fact that the modified fsync() just returns 
> without doing anything useful doesn't mean the data will be
> lost - it will  simply be delayed until the next coalesced
> updating occurs.

Unless, of course, your system or power happens to fail.
Imagine you have a database program keeping track of banking
transactions.  This program uses fsync() to ensure its
transaction logs are committed to reliable storage before
indicating the transaction is completed.  Suppose the moment
after I withdraw $500 from an ATM, the operating system or
hardware fails at the bank.

With your change to fsync() to not commit to stable storage,
I may have just won $500 courtesy of you.  That is, the
database software did all it could to ensure the $500
transaction was actually written to disk before authorizing
the ATM to dispense cash, yet fsync() has decided it's not
that important to do right away, so the transaction might
well have not hit the disk before the catastrophe.

For a perspective from the Windows world on the same sort
of capability, check out the Win32 FlushFileBuffers spec:

http://makeashorterlink.com/?E26B12F24

which is an alias for:

http://msdn.microsoft.com/library/default.asp?url=/library/
en-us/fileio/base/flushfilebuffers.asp

>From that page:  "The FlushFileBuffers function writes all 
of the buffered information for the specified file to disk."

Such is the world of writing OS code -- optimizing for one
situation may well break other important uses of the same
code.

Regards,
Dave Hart
davehart at davehart.com
(who spent more time formatting text than writing, sigh)