[Lustre-discuss] e2scan wrong file list mtime/ctime
adilger at sun.com
Wed Dec 16 12:40:03 PST 2009
On 2009-12-16, at 06:28, Miguel Molowny Lopez wrote:
> we are running lustre 22.214.171.124 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
> 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.
This is definitely odd. It is worthwhile to check what the timestamp
is on the MDS, via "debugfs -c -R 'stat foobar.txt'", in addition to
checking via "stat /scratch/foobar.txt" in the filesystem.
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
More information about the lustre-discuss