On 2009-12-16, at 06:28, Miguel Molowny Lopez wrote: > we are running lustre 1.8.1.1 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 > results: > - 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 > or: > * 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. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. _______________________________________________ Lustre-discuss mailing list [email protected] http://lists.lustre.org/mailman/listinfo/lustre-discuss
