PATCH: Forcible delaying of UFS (soft)updates

[Ian Dowse]

In message <3E9C517B.6039679A at tel.fer.hr>, Marko Zec writes:
>Tempted by a lot of opposition to the concept of (optionally) ignoring
>fsync() calls when running on battery power, I wonder what effect the
>concept of unconditional delaying of _all_ disk updates by ATA-disk
>firmware will make on FS consistency in case of system crash or power
>failure? I do not want to imply such a concept is a priori bad, however
>I fail to realize its advantages over OS-controlled delaying of disk
>synching.

Note that the ATA "delayed write" mechanism only delays writes while
the disk is spun down; at other times there is no change in behaviour.
Since the disk only spins down after it has been idle for a time,
it is very unlikely that the disk is left in an inconsistent state
while it is stopped.

Just after the disk spins up there is a small window where the
cached writes get written out in a burst. Due to the amount of
cached data and the probable re-ordering of writes, the disk is
quite likely to be in an inconsistent state during this flurry of
writes, but the window is short so it is probably not a big issue
in practice.

The main advantage of using the ATA delayed write mechanism is that
the disk itself can take advantage of knowing whether or not it is
spinning, whereas the OS does not have that information. The downside
is that it is not guaranteed that fsync'd data gets written to disk
immediately, though in practice the disk tends to be spinning when
the fsync is performed due to the previous accesses. I've been using
ATA delayed writes on a few laptops for over a year and it has never
caused me any problems - it generally works just right in the sense
that the disk remains spun down when the machine is mostly idle,
and spins up when you save files from an editor etc.

Doing the write delaying in the OS is always going to be a tradeoff
between excessively delaying writes when the machine is busy and
maximising the time between spin-ups when idle, though obviously
there is more control possible over which writes get delayed and
which don't.

Ian