LU-2368 recovery: fix for obd_stale_clients counter

class_fail_export() occured during recovery process, when
the mds connect to ost from new IP(failover happened), and cause
perpetual recovery.
- in class_fail_export() update obd_stale_clients counter if
  recovery is in progress.

Signed-off-by: Mikhail Pershin <tappro@whamcloud.com>
Signed-off-by: Alexander Boyko <alexander_boyko@xyratex.com>
Xyratex-bug-id: MRP-738
Change-Id: I2b2fe5853a9b0713a0a9357713f612b331505c6f
Reviewed-on: http://review.whamcloud.com/4641
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Mike Pershin <mike.pershin@intel.com>
Reviewed-by: Keith Mannthey <keith.mannthey@intel.com>
Reviewed-by: Keith Mannthey <DELETED>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.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>
Signed-off-by: Bob Glossman <bob.glossman@intel.com>
Change-Id: I6debe07acd015eb990d5b3748e50cc88d61065f8
Reviewed-on: http://review.whamcloud.com/6377
Tested-by: Hudson
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Tested-by: Maloo <whamcloud.maloo@gmail.com>
LU-1468 o2iblnd: Support OFED-3.5 for o2ib

OFED is having new structure based on linux kernel code + backports
and packaging. Here is detailed information.
http://lists.openfabrics.org/pipermail/ewg/2011-December/017156.html

This patches are the lustre build improvements to support OFED 3.5,
3.x whatever future OFED release.

Porting from:  Id4ffc39bc7fc24cc591bf6fb47e9b0e662993bda

Signed-off-by: Minh Diep <minh.diep@intel.com>
Change-Id: Icb64c3ab57be4bcbbdd8120aec6b58d02ff7253f
Reviewed-on: http://review.whamcloud.com/5688
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Brian J. Murrell <brian.murrell@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-2797 osc: GPF in osc_send_oap_rpc

Due to cl_loi_list_lock release in osc_send_oap_rpc(), this
leaves a window where lov_oinfo may be freed/poisoned between both
write/read steps/calls of osc_send_oap_rpc() in osc_check_rpcs(),
thus it needs to be refreshed.

Signed-off-by: Bruno Faccini <bruno.faccini@intel.com>
Change-Id: Id3056c1fca91bade65b6d2b556b6b47a3d3d089e
Reviewed-on: http://review.whamcloud.com/6089
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Jinshan Xiong <jinshan.xiong@intel.com>
Reviewed-by: Johann Lombardi <johann.lombardi@intel.com>
LU-3187 obdecho: always set o_id non-zero

Always initialize the o_id field in obdecho requests so the server
doesn't get confused between o_id == 0 and f_seq == 0.  This isn't
strictly necessary for protocol correctness (the server assigns
the actual OID in the end), but makes life a bit easier for cross
compatibility with FID-on-OST.

Signed-off-by: Andreas Dilger <andreas.dilger@intel.com>
Change-Id: Ifc318333df97326fb33366cd9f06d33e3f5139bb
Reviewed-on: http://review.whamcloud.com/6319
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>