LU-2919 hsm: Implementation of exclusive open

In this patch, a framework of lease is implemented. However,
only exclusive lease is supported right now.

To apply a lease, MDS_OPEN_LEASE must be set to open the file, EX
mode open lock is returned to the client side to hold a lease. From
that time on, if this file is opened again by other processes, the
open lock will be revoked so the client who holds the lease will
know the lease is already broken by checking that open lock.

To release a lease, normal close is used. The client will revoke the
open lock before sending CLOSE request.

Lease can be applied in two ways. ll_lease_open()/close() can be
called directly if the lease holder is in kernel space; or if the
lease holder lives in user space, it has to open the file first and
then use ioctl() with command LL_IOC_SET_LEASE to apply a lease. The
lease holder has to poll the lease status itself.

Signed-off-by: Jinshan Xiong <jinshan.xiong@intel.com>
Signed-off-by: John L. Hammond <john.hammond@intel.com>
Change-Id: I181edbb0b31fcf60858656170528d2ffda9c9bb6
Reviewed-on: http://review.whamcloud.com/6730
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-3093 lnet: Fix assert on empty group in selftest module

The core of the issue is that the selftest module doesn't sanitize its
own API, but it depends on lst utility to do such checks.  As a result
this issue manifests itself in this particular LU through an assert
on an empty group.  If the NID is misspelled then an empty group is
added.  An error output is provided, but if that's never checked in a
batch script, as is the case with this issue, then the script will try
to add an empty group to a test to run in a batch, and that will cause
an assert

The fix is two fold.  Ensure that lst utility checks that a group is
added with at least one node.  If not the group is subsequently
deleted.  And the add_test command would fail, since the group no
longer exists.

The second fix is to ensure that the kernel module itself sanitizes
its own API in this particular case, so that if a different utility is
used other than lst to communicate with the selftest kernel module
then this error would be caught.  This fix looks up the batch and the
groups, src and dst, in the ioctl handle and sanitizes that input at
this point.  If the group looked up either doesn't exist or doesn't
have at least one ACTIVE node, then the command fails.

NOTE:there are many other cases in the code where the selftest kernel
module doesn't check for sanity of the input, but depends totally on
the lst module to do such checks.  Particularly around length of
strings passed in.  Thus it is possible to crash the selftest module
if someone tries to create another userspace app to communicate with
the selftest kernel module without ensuring sanity of the params sent
to the kernel module.  In effect, it's always assumed that lst is the
front end for selftest and no other front end is to be used.

Signed-off-by: Amir Shehata <amir.shehata@intel.com>
Change-Id: If2e59c1fadf8bd6cac759ea8fa761be386e71bd3
Reviewed-on: http://review.whamcloud.com/6092
Tested-by: Hudson
Reviewed-by: Isaac Huang <he.huang@intel.com>
Reviewed-by: Liang Zhen <liang.zhen@intel.com>
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-2901 ldlm: fix resource/fid check, use DLDLMRES

In ll_md_blocking_ast() the FID/resource comparison is incorrectly
checking for fid_ver() stored in res_id.name[2] instead of name[1]
changed since http://review.whamcloud.com/2271 (commit 4f91d5161d00)
landed.  This does not impact current clients, since name[2] and
fid_ver() are always zero, but it could cause problems in the future.

In ldlm_cli_enqueue_fini() use ldlm_res_eq() instead of comparing
each of the resource fields separately.

Use DLDLMRES/PLDLMRES when printing resource names everywhere.

Signed-off-by: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: Lai Siyao <lai.siyao@intel.com>
Change-Id: I7b45d382d2ee87c1df813ebdd9c7f21029500c1e
Reviewed-on: http://review.whamcloud.com/6592
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Johann Lombardi <johann.lombardi@intel.com>
LU-3264 tests: support failover testing with ZFS

This patch improves test-framework.sh to support failover testing with
ZFS under shared storage configuration.

After formatting a ZFS target, "cachefile=none" property will be set
on the ZFS storage pool so that the pool is not automatically imported
on system startup. And then the pool will be exported so as to leave
the import and export operations handled by mount_facet() and stop().

For SOFT failure mode (unmount and mount), "zpool export …" will be
run on the active server node to export the ZFS storage pool, and
"zpool import -f …" will be run on the failover partner node to import
the pool.

For HARD failure mode (power off and on), since the "cachefile=none"
property has been set on the ZFS storage pool on the active server
node, after the node is power-cycled, the pool will not be imported.
Then on the failover partner node, "zpool import -f …" can be run to
import the pool.

This is a reworked patch with fixes merged in.

Formerly Change-Id: I6b9646cb36f7fa4924af03a055ccb137187843a5
Formerly Reviewed-on: http://review.whamcloud.com/6258
Formerly Change-Id: I63ac141fdefcace99a1cf7c366e15f0067fa2a56
Formerly Reviewed-on: http://review.whamcloud.com/6358
Formerly Change-Id: I83678fd8b67de87f5174017634f108e6ae5b30e0
Formerly Reviewed-on: http://review.whamcloud.com/6408

Test-Parameters: envdefinitions=PTLDEBUG=-1,DEBUG_SIZE=128 mdtfilesystemtype=zfs mdsfilesystemtype=zfs ostfilesystemtype=zfs clientdistro=el6 serverdistro=el6 clientarch=x86_64 serverarch=x86_64 clientcount=4 osscount=2 mdscount=2 austeroptions=-R failover=true useiscsi=true testlist=recovery-double-scale
Signed-off-by: Jian Yu <jian.yu@intel.com>
Signed-off-by: Nathaniel Clark <nathaniel.l.clark@intel.com>
Change-Id: I6d2fffede5de7a7d4a6bde3d62dd7c6cb60f63fa
Reviewed-on: http://review.whamcloud.com/6429
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>