ORNL-28: Set recovery timeout correctly

make sure recovery window uses timeout value from lustre config;
in current implementation this piece of code is totally wrong since
it just disregards timeout configuration.

Change-Id: I0cb0d777569cccd96f30da11834c6e333a673816
Signed-off-by: Jinshan Xiong <jay@whamcloud.com>
Reviewed-on: http://review.whamcloud.com/1292
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>
ORNL-28 recovery: rework extend_recovery_timer()

extend_recovery_timer() is used to adjust timeout value of a recovering
target. In the original implementation, there was a problem it stopped
the target from firing a timer again for version recovery case.

Change-Id: I815a15fb5d3104e52a189eed1529c58d7a8d03b9
Signed-off-by: Jinshan Xiong <jay@whamcloud.com>
Reviewed-on: http://review.whamcloud.com/1620
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Mikhail Pershin <tappro@whamcloud.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>
MRP-967 recovery: port ORNL-28 to neo 1.2

Change-Id: I069797650843505dfa4b24e787489c5399e1d56a
Reviewed-by: Alexey Lyashkov <alexey_lyashkov@xyratex.com>
LU-3219 ost: Ensure dirty flushed on fiemap ioctl

Data corruption is possible if cp(coreutils) uses FIEMAP to obtain
data holes in shared file, since there could be dirty cache on
other clients which hasn't been flushed back.

To ensure all the dirty on remote clients being flushed back on
fiemap ioctl, we'd acquire ldlm lock on server side for fiemap,
unless the local client (which invoke fiemap) has cached lock.

Xyratex-bug-id: MRP-1001
Signed-off-by: Artem Blagodarenko <artem_blagodarenko@xyratex.com>
Signed-off-by: Niu Yawei <yawei.niu@intel.com>
Change-Id: I67fe05bac1ce75f98c3d3806a4d08f6cb02048e6
Reviewed-on: http://review.whamcloud.com/6127
Tested-by: Hudson
Reviewed-by: Nathaniel Clark <nathaniel.l.clark@intel.com>
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Jinshan Xiong <jinshan.xiong@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>