Bug 139884 - Sub-second mtime changes without modifying file
Sub-second mtime changes without modifying file
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Stephen Tweedie
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-18 12:05 EST by Patrick J. LoPresti
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version: kernel-2.6.12-1.1372_FC3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-05 09:21:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Patrick J. LoPresti 2004-11-18 12:05:29 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
The 2.6 kernel's buffer cache has sub-second resolution for file
times.  The ext3 file system does not.  Consequently, the observable
mtime for a file changes unpredictably.

This is causing problems for us while compiling our product, because
"make" relies on file modification times to determine what to compile.
 But the bug is easily observed without running make; see the steps below.


Version-Release number of selected component (if applicable):
kernel-2.6.9-1.678_FC3

How reproducible:
Always

Steps to Reproduce:
1. touch /tmp/foo

2. ls -l --full-time /tmp/foo

3. (reboot system)

4. ls -l --full-time /tmp/foo

    

Actual Results:  The visible file modification time changes (gets
rounded down) as a result of the reboot.  The rounding down happens
whenever the kernel's buffer cache for the file gets flushed, which on
an active system is essentially random.


Expected Results:  The file modification time should not change for a
file which is not modified.


Additional info:

This was discussed on the linux-kernel mailing list back in April, but
as far as I can tell it was never resolved:

  http://www.ussg.iu.edu/hypermail/linux/kernel/0404.0/0193.html

And now it is causing a real problem for us.  This is clearly a kernel
bug; a file's modification time should not change unless the file is
modified.
Comment 2 Stephen Tweedie 2005-01-24 09:12:59 EST
A fix for this was committed upstream on the 4th of January:

ChangeSet@1.1975.1.115, 2005-01-04 21:30:08-08:00, ak@suse.de
  [PATCH] Sync in core time granuality with filesystems
                                                                                
  This patch corrects a problem that was originally added with the nanosecond
  timestamps in stat patch.  The problem is that some file systems don't have
  enough space in their on disk inode to save nanosecond timestamps, so they
  truncate the c/a/mtime to seconds when flushing an dirty node.  In core the
  inode would have full jiffies granuality.
Comment 5 Dave Jones 2005-01-24 18:14:40 EST
fc3 won't get a 2.6.11 kernel until after its released, so a backport is
probably a good idea for the interim.
Comment 7 Dave Jones 2005-07-15 16:46:30 EDT
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.

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