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

Andreas Dilger adilger at sun.com
Thu Jan 7 14:59:06 PST 2010


On 2010-01-07, at 03:43, Andrea Pieretti wrote:
> sorry for answering you so late  (Christmas holidays ;),
> it seems that the information reported by the two commands you  
> indicated, is different regarding the Access time of the file.
>
> Is this a normal behaviour ?

The atime is only updated lazily on the MDS.  What is important for  
the e2scan problem you reported is the mtime and ctime, which are  
identical in this case.

Can you please reproduce with the original test case, and then report  
the timestamps of a file that does not show up in your e2scan list  
correctly.

> It seems that the MDS does not update the access time  (we opened  
> the file on the client to view it's content)
>
>
> ---> Issued on a lustre client # stat /scratch/pieretti/new.out
> File: `/scratch/pieretti/new.out'
> Size: 25959         Blocks: 56         IO Block: 2097152 regular file
> Device: a2f3dcdch/2733890780d    Inode: 64740446    Links: 1
> Access: (0644/-rw-r--r--)  Uid: (  244/pieretti)   Gid: (20053/       
> bb)
> Access: 2010-01-07 11:28:56.000000000 +0100
> Modify: 2009-04-04 23:44:36.000000000 +0200
> Change: 2009-06-19 00:35:21.000000000 +0200
>
> ---> Issued on the mds # debugfs -c -R 'stat <64740446>' /dev/mapper/ 
> scratch_mdt
> debugfs 1.41.6.sun1 (30-May-2009)
> /dev/mapper/scratch_mdt: catastrophic mode - not reading inode or  
> group bitmaps
> Inode: 64740446   Type: regular    Mode:  0644   Flags: 0x0
> Generation: 1095573155    Version: 0x00000000:00000000
> User:   244   Group: 20053   Size: 0
> File ACL: 0    Directory ACL: 0
> Links: 1   Blockcount: 0
> Fragment:  Address: 0    Number: 0    Size: 0
> ctime: 0x4a3ac129:c210ae38 -- Fri Jun 19 00:35:21 2009
> atime: 0x4a3ac129:00000000 -- Fri Jun 19 00:35:21 2009
> mtime: 0x49d7d4c4:00000000 -- Sat Apr  4 23:44:36 2009
> crtime: 0x4a3ac129:c1969bb4 -- Fri Jun 19 00:35:21 2009
> Size of extra inode fields: 28
> Extended attributes stored in inode body:
> lov = "d0 0b d1 0b 01 00 00 00 5e dc db 03 00 00 00 00 00 00 00 00  
> 00 00 00 00 00 00 10 00 08 00
> 00 00 f5 cd 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05  
> 00 00 00 f5 cd 0c 00 00 00 0
> 0 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 f5 cd 0c 00 00  
> 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 07 00 00 00 f5 cd 0c 00 00 00 00 00 00 00 00 00 00 00  
> 00 00 00 00 00 00 06 00 00 00
> f5 cd 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00  
> 00 f5 cd 0c 00 00 00 00 00 0
> 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f5 cd 0c 00 00 00 00  
> 00 00 00 00 00 00 00 00 00 00
> 00 00 00 03 00 00 00 f5 cd 0c 00 00 00 00 00 00 00 00 00 00 00 00 00  
> 00 00 00 00 02 00 00 00 " (22
> 4)
> BLOCKS:
>
>
> Thanks for your kindness
>
> Andrea
>
>
>
> Andreas Dilger wrote:
>> On 2009-12-23, at 04:11, Andrea Pieretti wrote:
>>> Dear Andreas, sorry for the delay,
>>> I work with Miguel, so i'll write for him.
>>>
>>> We have one question,
>>> is it possible (safe) to use debugfs on a mounted Lustre filesystem?
>>
>> Yes, this is safe unless you open the filesystem with "-w" (write  
>> mode).
>> Without that you shouldn't be able to modify the filesystem, and it  
>> is
>> safe.
>>
>>> Andreas Dilger wrote:
>>>> 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
>>>> Lustre-discuss at lists.lustre.org
>>>> http://lists.lustre.org/mailman/listinfo/lustre-discuss
>>>>
>>>
>>> -- 
>>> +-------------------------------------------------------
>>> +  Andrea Pieretti
>>> +  C.A.S.P.U.R.,
>>> +  Via dei Tizii, 6b
>>> +  00185 Roma ITALY
>>> +  tel: +39-06-44486712
>>> +  mob: +39-328-4280841
>>> +  fax: +39-06-4957083
>>> +  e-mail: a.pieretti at caspur.it
>>> +  http://www.caspur.it
>>> +-------------------------------------------------------
>>> +
>>> +          "Nitwit! Blubber! Oddment! Tweak!"
>>> +
>>> +             Albus Percival Wulfric Brian Dumbledore
>>> +-------------------------------------------------------
>>>
>>> _______________________________________________
>>> Lustre-discuss mailing list
>>> Lustre-discuss at lists.lustre.org
>>> http://lists.lustre.org/mailman/listinfo/lustre-discuss
>>
>>
>> Cheers, Andreas
>> -- 
>> Andreas Dilger
>> Sr. Staff Engineer, Lustre Group
>> Sun Microsystems of Canada, Inc.
>>
>
> -- 
> +-------------------------------------------------------
> +  Andrea Pieretti
> +  C.A.S.P.U.R.,
> +  Via dei Tizii, 6b
> +  00185 Roma ITALY
> +  tel: +39-06-44486712
> +  mob: +39-328-4280841
> +  fax: +39-06-4957083
> +  e-mail: a.pieretti at caspur.it
> +  http://www.caspur.it
> +-------------------------------------------------------
> +
> +          "Nitwit! Blubber! Oddment! Tweak!"
> +
> +             Albus Percival Wulfric Brian Dumbledore
> +-------------------------------------------------------


Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.




More information about the lustre-discuss mailing list