Alessandro Federico
2009-Dec-16 11:37 UTC
[Lustre-discuss] e2scan wrong file list mtime/ctime
Hi to everyone,
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
We are looking for the differences between the first and second list to find
files older than two days and newer than three days (that is: a
list of one day).
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.
For us this e2scan behavior is not trustable and we cannot use its results
either for our bulldozer or for backup purposes.
Can anyone confirm this behaviour or help us to understand it?
Regards,
Ale
--
All work and no play makes Jack a dull boy.
All work and no play makes Jack a dull
boy. All work and no play makes Jack...
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.lustre.org/pipermail/lustre-discuss/attachments/20091216/c8fda960/attachment.html
Miguel Molowny Lopez
2009-Dec-16 13:28 UTC
[Lustre-discuss] e2scan wrong file list mtime/ctime
Hi to everyone,
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
We are looking for the differences between the first and second list to
find files older than two days and newer than three days (that is: a
list of one day).
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.
For us this e2scan behavior is not trustable and we cannot use its
results either for our bulldozer or for backup purposes.
Can anyone confirm this behaviour or help us to understand it?
Regards,
Miguel
--
--------------------------------------------
Miguel Molowny Lopez
CASPUR Inter-Univ. Computing Consortium
Tel: (0039) 06/44486404
E-mail: Miguel.Molowny at caspur.it
--------------------------------------------
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.
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? Thanks Andrea 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 +-------------------------------------------------------
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-discussCheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.
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 +-------------------------------------------------------
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.