<div dir="ltr">> Try it with the last field as 0x0, like "[0x200000a48:0x1e86e:0x0]".<br>> On the OST, we use the last field to store the stripe index for the file,<br>> so that LFSCK can reconstruct the file layout even if the MDT inode is<br>> corrupted.<br><br><br>OK, thanks.  Setting it to 0x0 worked and returned <br><br>    No such file or directory<br><br>as expected.<br><br><br>> That is not unusual, since the parent (MDT inode) FID is only stored into the<br>> object if it is modified by a client, or if an LFSCK layout check is run.<br><br><br>Interesting.  So these files can only be created files without any content.  I can safely ignore those :)<br><br><br>> It would be great if you could submit this as a patch to Gerrit.<br><br><br>Will do.  This tool is good and can be extended to handle many cases.  <br><br> * unmounted (existing)<br> * mounted (my version)<br> * mounted RO snapshot (my version)<br> * version that uses getfattr which is WAY faster than calling zdb<br><br>My workflow was<br><br>    ssh to OSS<br>    snapshot OST<br>    mount RO snapshot<br>    find O/ -type f<br>    pass file names to zfsobj2fid<br>    ssh to lustre client<br>    sudo<br>    pass FID's to lfs fid2path<br><br>the zfsobj2fid step was very slow for a large number of files, so I also have a getfattr version that is much faster.<br><br>I'll see what I can put together.<br><br>As a side note, it would make things a LOT easier if lfs fid2path worked with the value stored in trusted.fid extended attribute without modification<br><br>eg.<br><br>    trusted.fid=0xcc0e000002000000a02a00000000000000001000010000000000000000000000000000000000000000000000<br>    FID=[0x200000ecc:0x2aa0:0x0]<br><br><br><br><br>--<br>Dr Stuart Midgley<br><a href="mailto:sdm900@gmail.com">sdm900@gmail.com</a></div>