LU-3420 scrub: trigger OI scrub properly

LU-3420 scrub: trigger OI scrub properly

In osd_fid_lookup(), if the iget() cannot locate the backend inode
(return -ENOENT or -ESTALE) with the found ino#/gen in the OI file,
there may be three cases:

1) MDT file-level backup/restore caused the OI invalid.
2) Someone unlinked the object but NOT removed the OI mapping, such
   as mount target device as ldiskfs, and modify something directly.
3) Someone just removed the object between the osd_oi_lookup() and
   the iget(). It is normal.

Under such case we can lookup OI again to check whether related OI
mapping is still there or not. If not, it is 3rd case. Otherwise,
it is diffcult to distinguish the 2nd from the 1st case. Relatively
speaking, the 1st case is more common than the 2nd case, so trigger
OI scrub without further distinguish.

To reduce the 2nd case, the initial OI scrub will scan the local
objects set to remove those stale OI mappings, such as the entry
for "CATALOGS" after file-level backup/restore.

Another update is about mapping FID to inode for the object with
remote name entry. For example, dir1's name entry resides on the
MDT0. Its object resides on the MDT1. On the MDT1, do file-level
backup/resotre. And before the OI scrub finishing to rebuilt the
OI files on the MDT1, MDT0 send RPC to MDT1 to access dir1's obj
with dir1's FID. On the MDT1, the OI mapping for FID1 is invalid
yet. Under such case, we have two possible solutions:

a) The MDT1 returns -EINPROGRESS to the MDT0, and the MDT0 retry
   such RPC sometime later.

b) On the MDT1, There is the directory "/REMOTE_PARENT_DIR" hold
   all the objects which have remote name entries on other MDTs.
   The object name under the "/REMOTE_PARENT_DIR" is FID string.
   So when get invalid OI mapping, OSD can localte the inode via
   lookup the "/REMOTE_PARENT_DIR" with the given FID.

Compared the two solutions, a) will cause the MDT0 busy wait until
related OI mapping rebuilt. b) is relative better. And bacause the
MDT file-level backup/restore is rare case, it will not affect the
normal cases for FID to inode mapping.

In fact, from the OSD view, it does not know whether the object for
the given FID is referenced by some remote name entry or not, and
especially for DNE II, a multiple-linked object may have many name
entries reside on many MDTs.

To simplify the operation, OSD will not distinguish more, it just
lookup the "/REMOTE_PARENT_DIR". Usually, it only happened for the
RPC from other MDT during the OI scrub, or for the client side RPC
with FID only, such as FID to path, or from old connected client.

Test-Parameters: testlist=sanity-scrub
Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: I503bd1e2d5d5eb3976a46c385ae041d11d3b9c32
Reviewed-on: http://review.whamcloud.com/6515
Tested-by: Hudson
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Reviewed-by: wangdi <di.wang@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Tested-by: Maloo <whamcloud.maloo@gmail.com>