Very low granularity of file modification timestamps

[Doping]

The lastest Lucid Lynx kernels generate file modification timestamps with a precision of merely 0.5 seconds on filesystems which support a much higher timestamp resolution, e.g. ext4 or tmpfs. In other words, the test command

{ while true; do echo >t; ls --full-time t; rm t; done; } | uniq

prints exactly two lines per second.

It seems that this bug has been introduced with kernel 2.6.32-45.

I'm able to reproduce it on three platforms:
- a HP desktop PC with Ubuntu Lucid Lynx x86_64 Desktop Edition
- a VirtualBox VM on OS X with Ubuntu Lucid Lynx x86_64 Desktop Edition
- a VirtualBox VM on OS X with Ubuntu Lucid Lynx x86_64 Server Edition

The affected kernels include the latest Lucid Lynx kernels:
2.6.32-45-generic, 2.6.32-46-generic, 2.6.32-47-generic, and 2.6.32-47-server are affected.
2.6.32-45-server and 2.6.32-46-server most likely as well.

The kernels 2.6.32-44-generic and 2.6.32-38-server are fine, 2.6.32-44-server most likely as well. (Fine is this context meaning that the provided test command prints exactly 100 unique timestamps per second when run on these kernel versions.)

I discovered this bug while giving Subversion 1.8 RC2 a try. One test case kept failing due to Subversion's unfortunate assumption that sleeping for one millisecond would be enough to get different timestamps afterwards, combined with the low 0.5 seconds granularity of modification filestamps described in this report. (Please see thread http://mail-archives.apache.org/mod_mbox/subversion-users/201305.mbox/%3C519DDBE3.5040909%40web.de%3E if you're interested in details.)

IMHO this bug has a good chance of affecting other version control systems as well, because many rely on changed timestamps to recognize modified files.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1185730

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Doping (doping)]

This bug is reproducible on two wildly different platforms, a piece of HP metal as well as a VirtualBox VM on a MacBook. If a non-automated human requires more informations on one of these platforms, I'll gladly provide them.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.10 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-rc3-saucy/

[Doping (doping)]

I've tested three mainline kernels in a VirtualBox VM:
- The latest mainline kernel v3.10-rc3 works fine.
- Mainline kernel 2.6.32.59+drm33.24 works fine, just like its Ubuntu counterpart 2.6.32-44.
- Mainline kernel 2.6.32.60+drm33.26 contains the bug, just like its Ubuntu counterpart 2.6.32-45.

So this bug was obviously introduced in the mainline kernel somewhere between 2.6.32.59+drm33.24 and 2.6.32.60+drm33.26.

[penalvch (penalvch)]

Doping, the next step is to fully commit bisect from 2.6.32-44-generic to 2.6.32-45-generic in order to identify the offending commit. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection ?

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]