[OpenAFS-devel] to fsync() or not to fsync()

[Frank Batschulat (Home)]

On Thu, 14 Sep 2006 19:36:44 +0200, Jeffrey Hutzelman <jhutz@cmu.edu>  
wrote:

> On Thursday, September 14, 2006 01:23:05 PM -0400 Ken Hornstein  
> <kenh@cmf.nrl.navy.mil> wrote:
>
>>> ...which is a "risk" almost any filesystem or application takes into
>>> consideration, and allows the filesystem user to determine when it's
>>> "really necessary" to wait to go forward until data is committed to
>>> firm storage, or not.  Good or bad, the fileserver is assuming that's
>>> what you want to do all of the time in the CopyOnWrite and
>>> StoreData_RXStyle
>>
>> So, when I look at StoreData_RXStyle, I am not able to convince myself
>> that the actual file data is fsync()'d ... unless fsync() is actually
>> called on the client (and from what I see, fsync() IS passed from the
>> client to the server).  I can believe there is some other fsync()s in
>> there, certainly, but I don't think it's doing the bulk data (but hey,
>> I've been wrong before when it comes to AFS program flow).
>
> Huh?  There's no RPC for that.  And no, I don't think file data is  
> synced, but metadata is, which is consistent with the behavior of many  
> other filesystems.

interesting - I'd be curious to know about some examples that only
update meta data on fsync(3C) but not the actual file data.

at least if you have a file system that is required to satisfy POSIX
complience I'd wonder how that would work.

SUS3 (aka IEEE POSIX.1-2001) is very clear about the behavior of fsync(3C)
and the optional SIO Synchronized Input and Output functionality.
(The functionality described is also an extension to the ISO C standard.)

to quote:

<snip>
[SIO]  If _POSIX_SYNCHRONIZED_IO is defined, the fsync() function shall  
force
all currently queued I/O operations associated with the file indicated by
file descriptor fildes to the synchronized I/O completion state.
All I/O operations shall be completed as defined for synchronized I/O file
integrity completion.
<snip end>

The key is "as defined for synchronized I/O file integrity completion"
which reads as:

<snip>
      Synchronized I/O file integrity completion:

        o  Identical to a synchronized I/O data integrity  comple-
           tion  with  the addition that all file attributes rela-
           tive to  the  I/O  operation  (including  access  time,
           modification time, status change time) will be success-
           fully transferred prior to  returning  to  the  calling
           process.
<snip end

which is taking us to "synchronized I/O data integrity" eventually:

<snip>
        o  For writes, the operation has been completed  or  diag-
           nosed  if unsuccessful. The write is complete only when
           the data specified in the write request is successfully
           transferred,  and  all file system information required
           to retrieve the data is successfully transferred.

      File attributes that are not necessary  for  data  retrieval
      (access  time,   modification time, status change time) need
      not be successfully  transferred prior to returning  to  the
      calling process.
<snip end>

I must admit - I'd be rather surprised about an implementation
of fsync(3C) that does only sync meta data but not users file data
as well, even more since calling fsync(3C) would be equivilent to opening
a file with O_SYNC from the standards perspective and it's data integrity
requirements.

Leaving standards aside which is naturally not everyones concern,
I'd still wonder why an application would even bother calling fsync(3C)
when all it can be sure afterwards is that the file's meta data
are synced - but the file's contents may vanish ?

-- 
frankB