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.