Bug 1066179

Testing with meta.c (attached)

Test program created numerous files using various file open() flags and truncated each to 10 MiB.  The test then wrote a 512-byte block beginning at offset 0 to each file.  After a 10-second delay, the next 512-byte block was written, and so forth.

During the testing, both regular file write() and memcpy() to an mmapped file were tested, as well as combinations of fsync(), fdatasync(), and no file sync.

While the test program was running (after 10+ hours), customer initiated their snapshot + backup process.  The metadata of the various files (in particular, the 'mtime') was then compared.

The result of the testing indicated that the file open() flags had no bearing on whether mtime was updated.  Both fsync() and fdatasync() were confirmed to behave as expected (fsync forced both data write-out and 'mtime' update, while fdatasync() only caused write-out of the data).

When the file was written to through an mmap, fdatasync() was called, and fsync() was not called, the file's 'mtime' was never updated.  In these cases, the mtime remained unchanged since the file creation time.  File contents appeared to be correct in all cases.

In comparison, when the test program ran on a local ext4 filesystem (with the default data=ordered), the combination of mmap and not calling either fsync() or fdatasync() resulted in files where the 'mtime' would periodically lag behind the write time (and the mtime of the other files), but never by more than 20 seconds.  (Note: after running 'sync', all metadata was written to disk, and the maximum mtime difference was less than 10 milliseconds).


It appears that gfs does not update the on-disk mtime in file writes when: an mmap() is used, fdatasync() is called, and fsync() is not called