PATCH: Forcible delaying of UFS (soft)updates

Marko Zec zec at tel.fer.hr
Tue Apr 15 11:38:07 PDT 2003


Kirk McKusick wrote:

> I am of the opinion that fsync should work. Applications like
> `vi' use fsync to ensure that the write of the new file is on
> stable store before removing the old copy. If that semantic
> is broken, it would be possible to have neither the old nor
> the new copy of your file after a crash. I do not consider
> that acceptable behavior. Further, the fsync call is used
> to ensure that link/unlink/rename have been completed. So
> more than just fsync is being affected by your change. Lastly,
> I often write out a file when I am about to suspend my laptop
> (for low battery or other reasons) and I really want that file
> on the disk now. I do not want to have to wait for it to decide
> at some future time to spin up the disk.
>
> I suggest that you make the disabling of fsync a separate
> option from the rest of your change so that people can
> decide for themselves whether they want partial savings
> with working semantics, or greater savings with broken
> semantics. I am also intrigued by the changes proposed by
> Ian Dowse that may better accomplish the same goals with
> less breakage.

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.

Marko




More information about the freebsd-stable mailing list