Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 1066179

Summary: gfs does not update the on-disk mtime in file writes when: an mmap() is used, fdatasync() is called, and fsync() is not called
Product: Red Hat Enterprise Linux 5 Reporter: Harold Miller <hamiller>
Component: gfs-utilsAssignee: Robert Peterson <rpeterso>
Status: CLOSED DUPLICATE QA Contact: Cluster QE <mspqa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.8CC: cluster-maint, sbradley, swhiteho
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Red Hat Enterprise Linux Server release 5.8 Booted kernel: 2.6.18-308.8.2.el5 gfs2-utils-0.1.62-34.el5.x86_64 gfs-utils-0.1.20-13.el5.x86_64
Last Closed: 2014-02-18 15:14:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Harold Miller 2014-02-17 22:55:34 UTC
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

Comment 1 Steve Whitehouse 2014-02-18 15:14:38 UTC

*** This bug has been marked as a duplicate of bug 1066181 ***