[OpenAFS-devel] The ihandle sync thing

[Russ Allbery]

chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil> writes:
> Chaskiel Grundman <cg2v@andrew.cmu.edu> wrote:

>> Just because ext3 (in ordered mode) does something doesn't mean it's
>> correct or something you should count on. If you don't fsync/fdatasync,
>> there is no guarantee your data is on the media or ever will be on the
>> media.

> Even that is not a guarantee that your data is going to be on the media.
> The device may have your data in its write cache.

At least on Linux, fsync tries to flush all the way to media with the
assistance of the kernel, even to devices with write caches.

    fsync() transfers ("flushes") all modified in-core data of (i.e.,
    modified buffer cache pages for) the file referred to by the file
    descriptor fd to the disk device (or other permanent storage device)
    so that all changed information can be retrieved even after the system
    crashed or was rebooted.  This includes writing through or flushing a
    disk cache if present.

This may or may not be possible depending on how much control the kernel
has over the write buffering of the underlying device (SAN storage, for
example, probably can't be told to really write to disk), but it does try.

See also NOTES:

    The fsync() implementations in older kernels and lesser used
    filesystems does not know how to flush disk caches.  In these cases
    disk caches need to be disabled using hdparm(8) or sdparm(8) to
    guarantee safe operation.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>