[lustre-discuss] recovery MDT ".." directory entries (LU-5626)

[Martin Hecht]

Hi,

comments inline...

On 11/04/2015 01:34 PM, Patrick Farrell wrote:
> Our observation at the time was that lfsck did not add the fid to the .. dentry unless there was already space in the appropriate location.  
Ok, I might have been wrong in this point and some manual mv by the
users was involved.


On 11/04/2015 04:24 PM, Chris Hunter wrote:
> Yes I believe you want to (manually) recover the directories from
> lost+found back to ROOT on the MDT before lfsck/oi_scrub runs. I don't
> think lfsck on the MDT will impact orphan objects on the OSTs.
With lfsck phase 2 introduced in lustre 2.6 the MDT-OST consistency is
checked and repaired. Chris, you wrote that you have upgraded to "lustre
2.x", so I don't know if you have lfsck II already.  And I'm not sure if
MDT entries in lost+found are ignored by lfsck. I just wanted to point
out that you might have to be careful here, but looking at the lustre
manual it turns out that you are right. The consistency checks are run
when lfsck type is set to "layout", which is a different thing than the
"namespace" check used to update the FIDs.


On 11/05/2015 01:29 AM, Dilger, Andreas wrote:
> Note that newer versions of LFSCK namespace checking (2.6 or 2.7, don't
> recall offhand) will be able to return such entries from lost+found back
> into the proper parent directory in the namespace, assuming they were
> created under 2.x.  Lustre stores an extra "link" xattr on each inode with
> the filename and parent directory FID for each link to the file (up to the
> available xattr space for each inode), so in case of directory corruption
> it would be possible to rebuild the directory structure just from the
> "link" xattrs on each file.
that's good to know. However, the files in this case were created with
1.8, so even if the current version after the upgrade has this "link"
xattr, it doesn't help to recover from LU-5626. But your script is
useful (it's pretty much the same as I did back then, but I didn't find
my quick hack it anymore...)
 
> In the meantime, I attached a script to LU-5626 that could be used to
> re-link files from lost+found into the right directory and filename based
> on the output from e2fsck.  It is a bit rough (needs manual editing of
> pathnames), but may be useful if someone has hit this problem.

best regards,
Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2252 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20151105/ff7a6bcb/attachment.bin>