[Lustre-discuss] what file(s) own multi-claimed blocks

[Dilger, Andreas]

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