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>
LU-3934 scrub: detect upgraded from 1.8 correctly

The OI scrub should has the capability to detect the case of the MDT
device upgraded from lustre-1.8 and trigger full OI scrub to process
IGIF mapping into OI files.

Originally, we detect that by checking /ROOT/.lustre via initial OI
scrub, but if the MDT is upgraded to lustre-2.1 firstly, and then
continue to lustre-2.4, the such detect mechanism will be failed.
Because lustre-2.1 does not support OI scrub, but will create the
/ROOT/.lustre.

The new detect mechanism will combine the checking OI file name and OI
scrub successfully scan count: if there is old OI file "oi.16" and OI
scrub has never successfully run on the device, then it is regarded as
upgrading case.

Test-Parameters: testlist=sanity-scrub
Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: I5e57aae972e4fe93d3cb9e7cc7ca2e5b95dce4b2
LU-3892 ofd: setattr doesn't need to return attributes

the root cause of the problem is that getattr finds the
object being already destroyed, so we have transno from
preceeding setattr and -ENOENT from getattr and this
confuses OSP.

there is actually no need in attributes in the reply.

Signed-off-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Change-Id: Ib059a443af164d0def58fdfbf41ab545c057cd10
Reviewed-on: http://review.whamcloud.com/7672
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Mike Pershin <mike.pershin@intel.com>
Reviewed-by: Johann Lombardi <johann.lombardi@intel.com>
Reviewed-by: Niu Yawei <yawei.niu@intel.com>
Revert "LU-3161 lod: Added proper error handling instead of LASSERT"

This reverts commit a5753062bbf8291dfba5d27da5e3d521f7869eb0.
LU-3161 lod: Added proper error handling instead of LASSERT

LASSERT are replaced with proper error handling in
lod_initialize_objects.

Signed-off-by: Gaurav Mahajan <gmahajan@ddn.com>
Change-Id: Ia8fbbb4956765835bf46b46b3a7addc99cb191fa
Patch-Set: 7