[Lustre-discuss] e2scan wrong file list mtime/ctime
Andrea Pieretti
a.pieretti at caspur.it
Thu Jan 7 02:43:21 PST 2010
Dear Andreas,
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 ?
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
+-------------------------------------------------------
More information about the lustre-discuss
mailing list