Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Apr 2003 20:37:47 +0200
From:      Marko Zec <zec@tel.fer.hr>
To:        Kirk McKusick <mckusick@beastie.mckusick.com>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: PATCH: Forcible delaying of UFS (soft)updates
Message-ID:  <3E9C517B.6039679A@tel.fer.hr>
References:  <200304130004.h3D04Vb5006635@beastie.mckusick.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E9C517B.6039679A>