LU-5519 lfsck: repair bad name hash for striped directory

If the name hash of some name entry under the striped directory
does not match the shard of the striped directory, then the LFSCK
will repair the inconsistency. Ideally, the LFSCK should migrate
the name entry from the current MDT to the right MDT (another one),
but before the async commit finished, the LFSCK will change the
striped directory's hash type as LMV_HASH_TYPE_UNKNOWN and mark
the lmv flags as LMV_HASH_FLAG_BAD_TYPE.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: I665a77473be1fead09c12cb7fb5d0ffa739ffe87
Reviewed-on: http://review.whamcloud.com/11846
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-5519 lfsck: repair master LMV for striped directory

If the master MDT-object of a striped directory lost its LMV EA,
then there may be some users have created some files under the
master MDT-object directly. Under such case, the LFSCK cannot
re-generate LMV EA for the master MDT-object, because we should
keep the existing files to be visible to client. Then the LFSCK
will mark the striped directory as read-only and keep it there
to be handled by administrator manually.

If nobody has created files under the master MDT-object of the
striped directory, then we will set the master LMV EA and
generate a new rescan (the striped directory) request that will
be handled later by the LFSCK instance on the MDT later.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: I4d604cbd346c2cb044503f193ab4745e7fd2c2a2
Reviewed-on: http://review.whamcloud.com/11847
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-3613 llite: Add ioctl to get parent fids from link EA.

Added LL_IOC_GETPARENT to retrieve the <parent_fid>/name(s) of a given
entry, based on its link EA. This saves multiple calls to
path2fid/fid2path.

Added llapi_path2parent() and llapi_fd2parent() wrappers.

Added '--parents' option to lfs path2fid to call this function.

New sanity test 154f to validate the behavior.

Signed-off-by: Thomas Leibovici <thomas.leibovici@cea.fr>
Signed-off-by: Henri Doreau <henri.doreau@cea.fr>
Change-Id: I10f9316da605050be8fc709fe88d87abe86e22a4
Reviewed-on: http://review.whamcloud.com/7069
Tested-by: Jenkins
Reviewed-by: Ned Bass <bass6@llnl.gov>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: frank zago <fzago@cray.com>
Reviewed-by: John L. Hammond <john.hammond@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-5519 lfsck: repair slave LMV for striped directory

Before all shards of the striped directory scanned, the LFSCK
cannot know whether the master LMV EA is valid or not, and also
cannot know how to repair an invalid shard exactly. For example,
the stripe index stored in the shard's name does not match the
stripe index stored in the slave LMV EA, then the LFSCK cannot
know which one is correct. If the LFSCK just assumed one is
correct, and fixed the other, then as the LFSCK processing, it
may find that the former reparation is wrong and have to roll
back. Unfortunately, if some applications saw the changes and
made further modification based on such changes, then the roll
back is almost impossible.

To avoid above trouble, the LFSCK will double scan the master
object of the striped directory, that is NOT the same as normal
two-stages scanning, the double scanning the striped directory
will happen both during the first-stage scanning:

1) When the striped directory is opened for scanning, the LFSCK
   will iterate each shard in turn, and records its slave LMV EA
   in the lfsck_lmv::ll_lslr. In this step, if the 'shard' (may
   be fake shard) name does not match the shard naming rule, for
   example, it does not contain the shard's FID, or not contain
   index, then we can remove the bad name entry directly. But if
   the name is valid, but the shard has no slave LMV EA or the
   slave LMV EA does not match its name, then we just record
   related information in the lfsck_lmv::ll_lslr in RAM.

2) When all the known shards have been scanned, then the engine will
   generate a dummy request (via lfsck_namespace_close_dir) to tell
   the assistant thread that all the known shards have been scanned.
   Since the assistant has got the global knowledge about the index
   conflict, stripe count, hash type, and so on. Then the assistant
   thread will scan the lfsck_lmv::ll_lslr, and for every shard in
   the record, check and repair inconsistency.
2.1) If the shard lost its slave LMV EA, then regenerate the slave
     LMV EA.
2.2) If the index stored in the shard's name entry is wrong, then
     rename the shard.
2.3) If the shard's slave LMV EA contains bad index/stripe_count/
     hash type, then update the slave LMV EA.
2.4) If the shard object is missing, then re-create the lost shard.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: I92c0bd569e5a2711b8c7e93904d050b3fdf35377
Reviewed-on: http://review.whamcloud.com/11848
Tested-by: Jenkins
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-5435 libcfs: copy out ioctl inline buffer

- libcfs_ioctl_popdata should copy out inline buffers.
- code cleanup for libcfs ioctl handler
- error number fix for obd_ioctl_getdata
- add new function libcfs_ioctl_unpack for upcoming patches

Signed-off-by: Liang Zhen <liang.zhen@intel.com>
Change-Id: I3969e4e96b1dc0c2f6c3e86039b97af5482edc74
Reviewed-on: http://review.whamcloud.com/11313
Tested-by: Jenkins
Reviewed-by: Bobi Jam <bobijam@gmail.com>
Reviewed-by: Johann Lombardi <johann.lombardi@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-4198 clio: generalize cl_sync_io

To make cl_sync_io interfaces not just wait for pages, but to be
a generic synchronization mechanism.

Signed-off-by: Jinshan Xiong <jinshan.xiong@intel.com>
Change-Id: Iea43cb56c463efa7a6c6d17d84dacf4bdad8b377
Reviewed-on: http://review.whamcloud.com/8656
Reviewed-by: Bobi Jam <bobijam@gmail.com>
Tested-by: Jenkins
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>