kernel-packages team mailing list archive

["Christopher M. Penalver" <christopher.m.penalver@xxxxxxxxx>]

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 ?

** Tags added: needs-bisect regression-release

** Changed in: linux (Ubuntu)
       Status: Confirmed => Incomplete

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1185730

Title:
  Very low granularity of file modification timestamps

Status in “linux” package in Ubuntu:
  Incomplete

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1185730/+subscriptions