[lustre-discuss] corrupt FID on zfs?

[Stu Midgley]

> 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
sdm900 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20180410/44aff6d9/attachment.html>