On Thu, 16 Dec 2004, J Chapman Flack wrote:
> Bill Studenmund writes:
> > After discussing this with some developers, the best solution seems
> > to be to add a flag to fsync_range() to force this behavior. Then
> > pass a flag
>
> What would be the performance hit in making this the /default/
> behavior of fsync and fsync_range?

I always thought that fsync() and friends were guaranteed to commit the
data to stable storage.  The fsync(2) man page sometimes says "written
to permanent storage" and sometimes says "moved to a permanent storage
device".

The volatile write-back cache of a disk does not count as stable storage
in my book, so I would expect that fsync() and friends were guaranteed
to somehow get the data through the disk's cache to the platters.  I
think it's a bug if that guarantee is not being met.  I suppose I
can see a way of legalisticly twisting the words in the man page to
mean "moving the data to a /permanent storage device/ is good enough,
regardless of whether or not the device has really written the data
to /permanent storage/, and a disk with a write-cache is a permanent
storage device, regardless of whether or not the data has been written
to the platters", but I think that that violates the POLA.

It would be fine to have a set of flags telling fsync() things like
"just get the data to the disk controller, don't worry about getting
it to the disk", or "get the data from the controller to the disk,
but don't worry about getting it through any on-disk cache to stable
storage", or "make sure that the data gets to stable storage, but an
NVRAM or battery backed RAM cache is good enough", or "not even NVRAM
is good enough, make sure that the data really gets to it's ultimate
destination".  But I'd like the default behaviour to match what I have
always believed that fsync was guaranteed to do: get the data to stable
storage (NVRAM or battery-backed RAM is good enough).

--apb (Alan Barrett)