LU-3029 osd-ldiskfs: clear old FMODE_32BITHASH for readdir

On MDS, the RPC service thread's "osd_thread_info" will be reused
without completely reset when switches from one RPC processing to
another RPC processing.

Some old client may not claim "OBD_CONNECT_64BITHASH" when connect
to the MDS, then it will be regarded as 32-bit client. For readdir
RPC from such old client, the MDS will use 32-bit dirhash, the RPC
service thread's "osd_thread_info::oti_it_ea::oie_file::f_mode" is
set as "FMODE_32BITHASH", which will not be dropped until restart.

If some RPC service threads (for readdir) are "FMODE_32BITHASH",
but some NOT, then for new client, which support 64-bit dirhash,
it may get trouble when traverses large directroy as following:

1) The first readdir RPC is served by the RPC service thread1,
   which is marked as "FMODE_32BITHASH" because it ever served
   readdir RPC from old client. So the thread1 still generates
   32-bit dirhash (major hash only) for the new client readdir.

2) The new client triggers another readdir RPC for the same dir
   with the 32-bit dirhash as cookie, which was returned by the
   thread1.

3) This time, the readdir RPC is served by another RPC service
   thread2, which is NOT marked as "FMODE_32BITHASH". Then the
   thread2 explains the readdir cookie as 64-bit dirhash, It's
   wrong. So the thread2 can NOT locate the position correctly.

So we need to clear some fields in "osd_thread_info" to avoid
to be reused when switch from one RPC processing to another.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: I3b9aaede0bccab900f1d198c7093b98f0fc48945
Reviewed-on: http://review.whamcloud.com/6138
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Tested-by: Hudson
Reviewed-by: Ned Bass <bass6@llnl.gov>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: Prakash Surya <surya1@llnl.gov>
Tested-by: Maloo <whamcloud.maloo@gmail.com>
LU-3202 osd: no inode::i_mutex inside osd_object_destroy

Originally, to control the race between the OI scrub inserting
OI mapping and the osd_object_destroy() removing OI mapping on
the same target, the inode::i_mutex was used.

But the unlink thread which called osd_object_destroy() already
started transaction handle. Such order is different from others
as to may cause some deadlock between transaction start and the
obtain inode::i_mutex.

So now, the osd_object_destroy() will not obtain inode::i_mutex,
instead, the OI scrub will check whether someone unlinked the
inode or not during the OI scrub rebuilding the OI mapping, and
remove the new-inserted OI mapping if the race happened.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: Ic5c2e2b1d967e52a2b980d4f6bcaed4bdcf8368b
Reviewed-on: http://review.whamcloud.com/6124
Tested-by: Hudson
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Tested-by: Cliff White <cliff.white@intel.com>
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-992 build: remove obsolete rhel5 server configurations

For 2.4 RHEL5 server side support has been removed but
some technical debt remained before. This patch removes
the no longer needed rhel5 kernel configurations and
the CONFIG_LDISKFSDEV_* options that were left over
from the rhel5 ext3 days.

Signed-off-by: James Simmons <uja.ornl@gmail.com>
Change-Id: I345b1b5d182602b82be018b1e18a7bdbe939f578
Reviewed-on: http://review.whamcloud.com/5930
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
LU-1189 tests: run save_lustre_params() on facets

This patch fixes save_lustre_params() and restore_lustre_params()
to get and set Lustre parameters through do_facet() instead of
do_node(). This will fix the issue that restore_lustre_params() still
tries to restore the saved params on the original node which will
likely become inactive under failover test environment.

Test-Parameters: envdefinitions=SLOW=yes,ENABLE_QUOTA=yes \
clientcount=4 osscount=2 mdscount=2 austeroptions=-R \
failover=true useiscsi=true \
testlist=replay-vbr,replay-dual

Signed-off-by: Jian Yu <jian.yu@intel.com>
Change-Id: I5bfc4797727aaaa15fac1e34b6a7182ae8f26da8
Reviewed-on: http://review.whamcloud.com/5628
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Li Wei <wei.g.li@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Wei Liu <wei3.liu@intel.com>
LU-3142 mdt: update mdt_max_mdsize in mdt_lvbo_size

during calling mdt_lvbo_size to get the size of lsm, mdt_max_mdsize
could be less than the lsm size of this object in failover mode.
then it is needed to check and update this value.

Test-Parameters: envdefinitions=RECOVERY_MDS_SCALE_EXCEPT=failover_ost \
clientdistro=el6 serverdistro=el6 clientarch=x86_64 serverarch=x86_64 \
clientcount=4 osscount=2 mdscount=2 austeroptions=-R failover=true \
useiscsi=true testlist=recovery-mds-scale

Change-Id: Id490c346ca9f34edcc963334e396678f1b41562c
Signed-off-by: Hongchao Zhang <hongchao.zhang@intel.com>
Signed-off-by: Jian Yu <jian.yu@intel.com>
Reviewed-on: http://review.whamcloud.com/6102
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Mike Pershin <mike.pershin@intel.com>
Reviewed-by: Fan Yong <fan.yong@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>