LU-8574 osd-ldiskfs: fix FID-in-dirent properly

LU-8574 osd-ldiskfs: fix FID-in-dirent properly

Sometimes, the directory entry may be corrupted and contains bad
ino# information as to point to the inode that belong to other.
Two cases for that:

1) If such inode is unless, then the up layer namespace LFSCK may
   handle it as dangling name entry (by guess), and as the LFSCK
   progressing, its original inode (orphan) may be found then the
   LFSCK will fix the such bad name entry to reference the orphan.

2) If such inode is used by other, then osd_dirent_check_repair()
   will find that the FID-in-dirent does not match the FID-in-LMA,
   and fix the FID-in-dirent. So the up layer namespace LFSCK will
   get the wrong FID (not the original FID-in-dirent). Under such
   case, the up layer LFSCK will fix it as unmatched pairs, then
   the orphan cannot be recovered.

In fact, when injecting failure stub for LFSCK sanity test, we
hit similar issues as the 2) case. To resolve such trouble, we
can enhance the osd_dirent_check_repair() logic as following:
If the FID-in-dirent does not match the inode's FID-in-LMA, then
check the inode's linkEA, if it recognizes the dirent entry (with
parent dir's FID + child name), then trouble the inode, and fix
the FID-in-dirent with the FID-in-LMA. Otherwise, the dirent may
be corrupted, as the LFSCK processing, the right orphan may be
found, then fix it later. The worst case is that the inconsistence
is detected but kept there, but it will make wrong fixing.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: I3516a6ad9cc1766453612c440df7db02bc2f09a4
Reviewed-on: http://review.whamcloud.com/22310
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>