MRP-477 resend CANCEL rpc

it is better to deliver CANCEL rpc to server reliably in the following case:
    RPC timeout, re-connect, CANCEL resend
because server may have sent BL AST and is waiting for this CANCEL. this will
avoid possible idle time on server and later client evictions.

CANCEL is always has up-todate lock handle or both enqueue and cancel are not
replayed on recovery, with the exception of the following case:
    BL AST is sent; recovery starts, lock is re-enqueued, BL AST comes to
    client, cancel is created, recovery ends (lock handle has changed), CANCEL
    is sent, its reply gets estale as lock handled is not updated in the RPC.
this case is left unfixed and still may result in lock callback timeout and
client eviction, but this race window is much much shorter than the target
case being fixed by this fix.

Also remove lock cancelling from client_common_put_super() as it is done later
in client_disconnect_export().
MRP-477 disabling ELC through procfs

adding a possibility to disable ELC through procfs, for test purposes only.

Reviewed-by: Andrew Perepechko <Andrew_Perepechko@xyratex.com>
Reviewed-by: Alexander Zarochentsev <Alexander_Zarochentsev@xyratex.com>
Signed-off-by: Vitaly Fertman <vitaly_fertman@xyratex.com>
MRP-477 test for HP re-connect & cancel resend

Reviewed-by: Alexey Lyashkov <alexey_lyashkov@xyratex.com>
LU-1095 debug: CWARN to CDEBUG for mds_notify() event

Both of these warnings represent correct behavior the administrator
does not need to know about, or more importantly do anything about.
As such I am moving both of these warnings to CDEBUG(D_CONFIG).

  Lustre: 8099:0:(mds_lov.c:1167:mds_notify()) MDS lc1-MDT0000:
  add target lc1-OST0023_UUID

  Lustre: lc1-MDT0000: in recovery, not resetting orphans on
  lc1-OST0007_UUID

Signed-off-by: Christopher J. Morrone <morrone2@llnl.gov>
Change-Id: I66a98d87e3d5de7205420c74db4f6d9bcaaf31a7
Reviewed-on: http://review.whamcloud.com/2202
Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>
LU-1095 debug: Standardize, suppress mount/umount messages

Standardize mount/umount console message to include profile name,
and optionally suppress them with the 'quiet' mount option.  We
have been using private namespaces for testing and mounting then
umounting the FS as needed for each job.  In this context these
messages end up causing alot of syslog noise.

Signed-off-by: Christopher J. Morrone <morrone2@llnl.gov>
Change-Id: I7514f6016c337a358e5e31146644810dff292d02
Reviewed-on: http://review.whamcloud.com/2199
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Yu Jian <yujian@whamcloud.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>
LU-1095 debug: Improve messages for fake requests

Update the console filter to correctly handle fake requests and
squelched the lov_update_create_set() message for the
-ETIMEDOUT/-ENOTCONN case.

 LustreError: 7872:0:(lov_request.c:693:lov_update_create_set()) error
 creating fid 0x104c5e0b sub-object on OST idx 53/2: rc = -107

Signed-off-by: Christopher J. Morrone <morrone2@llnl.gov>
Change-Id: I5f37f585566b053d515665fcddbcc8a3e653d89a
Reviewed-on: http://review.whamcloud.com/2203
Tested-by: Hudson
Reviewed-by: Minh Diep <mdiep@whamcloud.com>
Reviewed-by: Jinshan Xiong <jinshan.xiong@whamcloud.com>
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>
LU-1095 debug: Improve recovery console messages

Quiet and/or improve a few recovery messages.

A sysadmin will not understand this:

  2012-03-02 16:27:19 Lustre: 5211:0:(ldlm_lib.c:2072:
  target_queue_recovery_request()) Next recovery transno: 410629539,
  current: 410629539, replaying

Messages like this are too verbose for the console:

  2012-03-02 16:27:59 LustreError: 5286:0:
  (genops.c:1270:class_disconnect_stale_exports())
  lc3-OST0004: disconnect stale client
  47808f4f-9f36-e8eb-f363-14b1abe4ac57@<unknown>

and can be left to this simpler message:

  2012-03-02 16:27:59 Lustre: lc3-OST0005: disconnecting 0 stale
  clients

Signed-off-by: Christopher J. Morrone <morrone2@llnl.gov>
Change-Id: I457602c3440ba10475e4ddca7c4e58ef8669922c
Reviewed-on: http://review.whamcloud.com/2249
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Niu Yawei <niu@whamcloud.com>
Reviewed-by: Liu Xuezhao <xuezhao.liu@emc.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>
LU-1095 debug: Send common recovery messages to D_HA

These messages are always present at recovery time, and are not
understable by a sysadmin.

Signed-off-by: Christopher J. Morrone <morrone2@llnl.gov>
Change-Id: I907b0ac49541b20699914dc4f8c5e0db3fb6bec9
Reviewed-on: http://review.whamcloud.com/2198
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
Reviewed-by: Minh Diep <mdiep@whamcloud.com>
Reviewed-by: wangdi <di.wang@whamcloud.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>
MRP-613 e2fsck on boot finds long symlinks that are 'invalid'

Write zero string terminator for symbolic links
to make fsck happy.

LU-1540 contains patch for fsck to fix old links.

Reviewed-by: Andrew Perepechko <Andrew_Perepechko@xyratex.com>
Reviewed-by: Vitaly Fertman <vitaly_fertman@xyratex.com>
Signed-off-by: Andriy Skulysh <Andriy_Skulysh@xyratex.com>