LU-3455 mdt: sync when evicting client

If some client is evicted from the MDT, then the underlying OSD
should be synchronized, otherwise the recovery will be failed
for the replay requests were dropped alongside with the client.

in test_20b in replay-single.sh, the occupied disk space will be
released only after DMUs are committed for ZFS, then it should
wait some more time before calling 'df' to get the disk usage info.

Test-Parameters: alwaysuploadlogs \
envdefinitions=SLOW=yes,ENABLE_QUOTA=yes,ONLY=20b \
mdtfilesystemtype=zfs mdsfilesystemtype=zfs ostfilesystemtype=zfs \
clientcount=4 osscount=2 mdscount=2 \
mdssizegb=10 ostsizegb=10 austeroptions=-R failover=true iscsi=1 \
testlist=replay-single,replay-single,replay-single,replay-single,replay-single

Change-Id: Ic126bd3c58a6d2da1c69c7231e88a8977417d37b
Signed-off-by: Hongchao Zhang <hongchao.zhang@intel.com>
Reviewed-on: http://review.whamcloud.com/11767
Tested-by: Jenkins
Reviewed-by: Nathaniel Clark <nathaniel.l.clark@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Jian Yu <jian.yu@intel.com>
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-6033 tests: inject failure before counting the objects

Some test cases need to inject some failure stub on OST that will
be triggered when creating the OST objects. For that, we need to
calculate how many objects to be created to guarantee that all the
pre-created OST-objects on the MDT can be exhausted. Under some
race cases, the MDT may be in pre-creating OST-objects and finished
the pre-creation just after the precreated_ost_obj_count() returning
zero to the caller but before the caller injecting the failure stub
on the OST. Then the subsequent failure injection will be useless.
To resolve such trouble, the caller of precreated_ost_obj_count()
should inject related failure stub before calculating the pre-created
OST-objects count.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: I01c98c0eb67aa0974c3223356557ae76f23ddb77
Reviewed-on: http://review.whamcloud.com/13098
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Bobi Jam <bobijam@hotmail.com>
Reviewed-by: Jian Yu <jian.yu@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-6025 utils: reset optind before calls to getopt_long()

The nodemap commands in lctl were not properly resetting optind
between calls to getopt_long(). This patch sets optind to 0 before
calling any subcommands.

Signed-off-by: Kit Westneat <kit.westneat@gmail.com>
Change-Id: I14a1f34000c678799298dae3c248c839a1f32d52
Reviewed-on: http://review.whamcloud.com/13063
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Tested-by: Jenkins
Reviewed-by: Nathaniel Clark <nathaniel.l.clark@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
LU-5851 build: split lustre-osd RPMs

Since Lustre Server DKMS builds osd Kernel modules and Provides
lustre-osd, we need to find a way to also install the
osd-specific dso that is also shipped as part of lustre-osd RPM.

To fix this, now ship the osd-specific dso as part of its own RPM.
And also create its new lustre-osd-mount dependency to ensure
the lustre-osd -> lustre-osd-mount -> lustre coherency and
ordering for Server installs.

Signed-off-by: Bruno Faccini <bruno.faccini@intel.com>
Change-Id: I25d498590212e696f74018c0af694bfee4d1cc81
Reviewed-on: http://review.whamcloud.com/12589
Tested-by: Jenkins
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Dmitry Eremin <dmitry.eremin@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-6042 osc: osc_object_ast_clear() LBUG

An OSC object could be destroyed with AGL locks waiting for granted,
so we'd get rid of the osc_object_ast_clear() assertion that its
dlm locks all getting granted.

Signed-off-by: Bobi Jam <bobijam.xu@intel.com>
Change-Id: I47f6c9a5f5b57291e8452713af417310f25a5e03
Reviewed-on: http://review.whamcloud.com/13163
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Jinshan Xiong <jinshan.xiong@intel.com>
Reviewed-by: Niu Yawei <yawei.niu@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>