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

[Andreas Dilger]

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.