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