Andrus, Brian Contractor
2013-Apr-03 17:20 UTC
[Lustre-discuss] what file(s) own multi-claimed blocks
All,
I am running e2fsck on one of my OSTs.
I run into:
==================File /O/0/d6/768742 (inode #22479589, mod time Fri Aug 17
11:15:51 2012)
has 1034 multiply-claimed block(s), shared with 4 file(s):
... (inode #25579161, mod time Wed Oct 6 20:47:34 2010)
... (inode #25579148, mod time Wed Oct 6 20:47:28 2010)
... (inode #25579135, mod time Wed Oct 6 20:47:12 2010)
... (inode #25579134, mod time Wed Oct 6 20:47:10 2010)
===================
It seems to imply there are only a few files affected by this issue.
I would like to hunt down the specific file and delete/restore it, but how do I
identify it?
The OST is 16TB and the lustre filesystem itself is about 80TB
I do have the OST offline and unmounted.
Is there a quick/simple way to find the affected file(s)
Brian Andrus
ITACS/Research Computing
Naval Postgraduate School
Monterey, California
voice: 831-656-6238
Dilger, Andreas
2013-Apr-07 00:18 UTC
[Lustre-discuss] what file(s) own multi-claimed blocks
On 2013/03/04 11:20 AM, "Andrus, Brian Contractor" <bdandrus at nps.edu> wrote:>All, > >I am running e2fsck on one of my OSTs. >I run into: >==================>File /O/0/d6/768742 (inode #22479589, mod time Fri Aug 17 11:15:51 2012) > has 1034 multiply-claimed block(s), shared with 4 file(s): > ... (inode #25579161, mod time Wed Oct 6 20:47:34 2010) > ... (inode #25579148, mod time Wed Oct 6 20:47:28 2010) > ... (inode #25579135, mod time Wed Oct 6 20:47:12 2010) > ... (inode #25579134, mod time Wed Oct 6 20:47:10 2010) >===================> >It seems to imply there are only a few files affected by this issue. >I would like to hunt down the specific file and delete/restore it, but >how do I identify it? >The OST is 16TB and the lustre filesystem itself is about 80TB > >I do have the OST offline and unmounted. >Is there a quick/simple way to find the affected file(s)Each OST object has an xattr called "fid" which contains its own object ID, as well as the FID of the parent MDT inode of which it is a part. If you run debugfs on this OST you can print out this information with the "stat" command: debugfs -c /dev/{ost} stat <25579161> stat <25579148> stat <25579135> stat <25579134> Cheers, Andreas -- Andreas Dilger Lustre Software Architect Intel High Performance Data Division
Andrus, Brian Contractor
2013-Apr-09 15:22 UTC
[Lustre-discuss] what file(s) own multi-claimed blocks
Andreas, Thanks for that info, it is a step in the right direction. I found the following on the file: debugfs: stat <25579161> Inode: 25579161 Type: regular Mode: 0666 Flags: 0x80000 Generation: 2046188318 Version: 0x00000000:0030d2d7 User: 30203 Group: 606 Size: 829264 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 1624 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x5037debd:59b44000 -- Fri Aug 24 13:06:21 2012 atime: 0x50119f0b:59b44000 -- Thu Jul 26 12:48:27 2012 mtime: 0x4cad42d6:59b44000 -- Wed Oct 6 20:47:34 2010 crtime: 0x500b314a:a10bb0d4 -- Sat Jul 21 15:46:34 2012 Size of extra inode fields: 28 Extended attributes stored in inode body: fid = "c5 13 00 00 02 00 00 00 e3 ba 00 00 00 00 00 00 0f fb 08 00 00 00 00 00 00 00 00 00 00 00 00 00 " (32) fid: objid=588559 seq=0 parent=[0x2000013c5:0xbae3:0x0] stripe=0 EXTENTS: (0-202):3287229701-3287229903 So I can identify who the file belongs to with the User: info there, but how do I use that fid info to find the specific file? I see objid and the parent info. I imagine I need to use that on the MDT somehow? Brian Andrus ITACS/Research Computing Naval Postgraduate School Monterey, California voice: 831-656-6238> -----Original Message----- > From: Dilger, Andreas [mailto:andreas.dilger at intel.com] > Sent: Saturday, April 06, 2013 5:19 PM > To: Andrus, Brian Contractor; lustre-discuss at lists.lustre.org > Subject: Re: [Lustre-discuss] what file(s) own multi-claimed blocks > > On 2013/03/04 11:20 AM, "Andrus, Brian Contractor" <bdandrus at nps.edu> > wrote: > > >All, > > > >I am running e2fsck on one of my OSTs. > >I run into: > >==================> >File /O/0/d6/768742 (inode #22479589, mod time Fri Aug 17 11:15:51 > >2012) > > has 1034 multiply-claimed block(s), shared with 4 file(s): > > ... (inode #25579161, mod time Wed Oct 6 20:47:34 2010) > > ... (inode #25579148, mod time Wed Oct 6 20:47:28 2010) > > ... (inode #25579135, mod time Wed Oct 6 20:47:12 2010) > > ... (inode #25579134, mod time Wed Oct 6 20:47:10 2010) > >===================> > > >It seems to imply there are only a few files affected by this issue. > >I would like to hunt down the specific file and delete/restore it, but > >how do I identify it? > >The OST is 16TB and the lustre filesystem itself is about 80TB > > > >I do have the OST offline and unmounted. > >Is there a quick/simple way to find the affected file(s) > > Each OST object has an xattr called "fid" which contains its own object ID, as > well as the FID of the parent MDT inode of which it is a part. If you run > debugfs on this OST you can print out this information with the "stat" > command: > > debugfs -c /dev/{ost} > stat <25579161> > stat <25579148> > stat <25579135> > stat <25579134> > > Cheers, Andreas > -- > Andreas Dilger > > Lustre Software Architect > Intel High Performance Data Division >
Dilger, Andreas
2013-Apr-11 12:31 UTC
[Lustre-discuss] what file(s) own multi-claimed blocks
On 2013/09/04 9:22 AM, "Andrus, Brian Contractor" <bdandrus at nps.edu> wrote:>Thanks for that info, it is a step in the right direction. >I found the following on the file: > >debugfs: stat <25579161> >Inode: 25579161 Type: regular Mode: 0666 Flags: 0x80000 >Generation: 2046188318 Version: 0x00000000:0030d2d7 >User: 30203 Group: 606 Size: 829264 >File ACL: 0 Directory ACL: 0 >Links: 1 Blockcount: 1624 >Fragment: Address: 0 Number: 0 Size: 0 > ctime: 0x5037debd:59b44000 -- Fri Aug 24 13:06:21 2012 > atime: 0x50119f0b:59b44000 -- Thu Jul 26 12:48:27 2012 > mtime: 0x4cad42d6:59b44000 -- Wed Oct 6 20:47:34 2010 >crtime: 0x500b314a:a10bb0d4 -- Sat Jul 21 15:46:34 2012 >Size of extra inode fields: 28 >Extended attributes stored in inode body: > fid = "c5 13 00 00 02 00 00 00 e3 ba 00 00 00 00 00 00 0f fb 08 00 00 >00 00 00 00 00 00 00 00 00 00 00 " (32) > fid: objid=588559 seq=0 parent=[0x2000013c5:0xbae3:0x0] stripe=0 >EXTENTS: >(0-202):3287229701-3287229903 > > > >So I can identify who the file belongs to with the User: info there, but >how do I use that fid info to find the specific file? I see objid and the >parent info. I imagine I need to use that on the MDT somehow?You can look up the parent FID using: lfs fid2path /mount/point [0x2000013c5:0xbae3:0x0] on any client. Cheers, Andreas>> -----Original Message----- >> From: Dilger, Andreas [mailto:andreas.dilger at intel.com] >> Sent: Saturday, April 06, 2013 5:19 PM >> To: Andrus, Brian Contractor; lustre-discuss at lists.lustre.org >> Subject: Re: [Lustre-discuss] what file(s) own multi-claimed blocks >> >> On 2013/03/04 11:20 AM, "Andrus, Brian Contractor" <bdandrus at nps.edu> >> wrote: >> >> >All, >> > >> >I am running e2fsck on one of my OSTs. >> >I run into: >> >==================>> >File /O/0/d6/768742 (inode #22479589, mod time Fri Aug 17 11:15:51 >> >2012) >> > has 1034 multiply-claimed block(s), shared with 4 file(s): >> > ... (inode #25579161, mod time Wed Oct 6 20:47:34 2010) >> > ... (inode #25579148, mod time Wed Oct 6 20:47:28 2010) >> > ... (inode #25579135, mod time Wed Oct 6 20:47:12 2010) >> > ... (inode #25579134, mod time Wed Oct 6 20:47:10 2010) >> >===================>> > >> >It seems to imply there are only a few files affected by this issue. >> >I would like to hunt down the specific file and delete/restore it, but >> >how do I identify it? >> >The OST is 16TB and the lustre filesystem itself is about 80TB >> > >> >I do have the OST offline and unmounted. >> >Is there a quick/simple way to find the affected file(s) >> >> Each OST object has an xattr called "fid" which contains its own object >>ID, as >> well as the FID of the parent MDT inode of which it is a part. If you >>run >> debugfs on this OST you can print out this information with the "stat" >> command: >> >> debugfs -c /dev/{ost} >> stat <25579161> >> stat <25579148> >> stat <25579135> >> stat <25579134> >> >> Cheers, Andreas >> -- >> Andreas Dilger >> >> Lustre Software Architect >> Intel High Performance Data Division >> > >Cheers, Andreas -- Andreas Dilger Lustre Software Architect Intel High Performance Data Division