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 1066178 - gfs does not update the on-disk mtime in file writes when: an mmap() is used, fdatasync() is called, and fsync() is not called
Summary: gfs does not update the on-disk mtime in file writes when: an mmap() is used,...
Status: CLOSED DUPLICATE of bug 1066181
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gfs-utils
Version: 5.8
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: Robert Peterson
QA Contact: Cluster QE
Depends On:
TreeView+ depends on / blocked
Reported: 2014-02-17 22:55 UTC by Harold Miller
Modified: 2018-12-05 17:19 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
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:13:26 UTC
Target Upstream Version:

Attachments (Terms of Use)
test program used to demonstrate the issue (deleted)
2014-02-17 22:55 UTC, Harold Miller
no flags Details

System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 639903 None None None Never

Description Harold Miller 2014-02-17 22:55:05 UTC
Created attachment 864327 [details]
test program used to demonstrate the issue

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:13:26 UTC

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

Note You need to log in before you can comment on or make changes to this bug.