[Lustre-discuss] e2scan wrong file list mtime/ctime

Alessandro Federico afederic at gmail.com
Wed Dec 16 03:37:08 PST 2009

Hi to everyone,
we are running lustre on our storage cluster based on IB.

We are building a "bulldozer" for a scratch area and we have found an odd
behaviour in the e2scan utility (maybe a bug or a ... "defined behaviour" we
don't know about).

We have reproduced this behavior several time and we are having these
- we run e2scan on the MDT to have the files newer than 3 days ago:
  command line used was like:
    * e2scan -l -N '2009-12-13' /dev/mapper/mdt
    * e2scan -l -n /tmp/file.timestamp /dev/mapper/mdt
      where file.timestamp has been created with the date of
      3 days ago using touch
  The result is sorted and saved in a file called: 3daysago.list
- we then run another e2scan looking for files newer than 2 days ago
  using the same command line and the result is sorted and saved in
  a file called: 2daysago.list

We are looking for the differences between the first and second list to find
files older than two days and newer than three days (that is: a
list of one day).

The problem is that there are files whose last modification time is before
the date at which we run the two e2scan commands (they were not modified
during the run of e2scan) _BUT_ they appear only in the list 3daysago.list.
Here is an example:

- first run of e2scan at: Dec 15 16:20 (produce list 3daysago.list)
- second run of e2scan at: Dec 15: 16:50 (produce list 2daysago.list)
- file: /scratch/foobar.txt has mtime=ctime = Dec 14 03:19
  This file is still on filesystem after the run of the two e2scan cmd
well, this file appears only in the 3daysago.list. And this happen for
a _LONG_ list of files.

For us this e2scan behavior is not trustable and we cannot use its results
either for our bulldozer or for backup purposes.

Can anyone confirm this behaviour or help us to understand it?


All work and no play makes Jack a dull boy.
   All work and no play makes Jack a dull
 boy. All work and no play makes Jack...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20091216/c8fda960/attachment.htm>

More information about the lustre-discuss mailing list