Re: [Qemu-devel] [PATCH] ide.c make write cacheing controllable by guest

[Ian Jackson]

Jamie Lokier writes ("Re: [Qemu-devel] [PATCH] ide.c make write cacheing 
controllable by guest"):
> I'm imagining that fdatasync() will flush the necessary metadata,
> including file size, when a file is extended.  As would O_DSYNC.

Do you have a reference to support this supposition ?  SuSv3's
specification for fdatasync is (astonishingly!) even vaguer and less
meaningful than that for fsync.

The closest I've come to finding answers are these:

HP-UX 11i's fdatasync manpage:

      fdatasync() causes all modified data and file attributes of fildes
      required to retrieve the data to be written to disk.

The glibc info manual:

     Sometimes it is not even necessary to write all data associated with
  a file descriptor.  E.g., in database files which do not change in size
  it is enough to write all the file content data to the device.

The Solaris manpage says that fdatasync does the same as O_DSYNC, and
it calls the service "synchronized I/O data integrity completion"
which is defined by the `Programming Interfaces Guide' to include
this:

 * For writes, the operation has been completed, or diagnosed if
   unsuccessful. The write operation succeeds when the data specified
   in the write request is successfully transferred. Furthermore, all
   file system information required to retrieve the data must be
   successfully transferred.

But then the next bullet point is this:

 * File attributes that are not necessary for data retrieval are not
   transferred prior to returning to the calling process.

which says `are not transferred' when it ought to say `are not
necessarily transferred' so it may be unwise to rely on the precise
wording.

I looked at various other manpages but they all say useless things
like `metadata such as modification time' which leaves open the
question of whether the file size is included.

If the size is supposed to be included then the OS is required to keep
a flag to say whether the file has been extended so that it knows that
the next fdatasync ought really to be an fsync and write the inode
too.  (In a traditional filesystem structure.)  Or perhaps fsck needs
to extend the file as necessary to include the data blocks past the
nominal end of file.

This seems like rather a minefield.

Ian.