LU-1291 mds: kernel crashed while umount mds

The obd_notify needs protect by mds_notify_lock. Else LOV
maybe gone while __mds_lov_synchronize be called.

Signed-off-by: yang sheng <yang.sheng@intel.com>
Change-Id: Ia96e0df2e7c8489741c8cbfe9f4fa35ecdb8f453
Reviewed-on: http://review.whamcloud.com/5789
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Niu Yawei <yawei.niu@intel.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
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: I1b0468fe1d3bed5b3563b17c9722009514bbea2e
Reviewed-on: http://review.whamcloud.com/6176
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Ned Bass <bass6@llnl.gov>
Reviewed-by: Prakash Surya <surya1@llnl.gov>
LU-3218 kernel: Kernel update [RHEL5.9 2.6.18-348.4.1.el5]

Update RHEL5.9 patch to 2.6.18-348.4.1.el5.

Signed-off-by: yang sheng <yang.sheng@intel.com>
Change-Id: Ib9741a9323fff58926a12b8f46ddae43950ea964
Reviewed-on: http://review.whamcloud.com/6279
Tested-by: Hudson
Reviewed-by: Bobi Jam <bobijam@gmail.com>
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-3279 changelog: fix CL_LAYOUT, accept all types

In order to avoid compatibility issues with older ChangeLog consumers,
change the new CL_LAYOUT record to use the value previously assigned
to CL_IOCTL.  The CL_IOCTL type was never used anywhere, and it didn't
really make any sense as a ChangeLog record, since it could really
mean anything at all.

The changelog_show_cb() function is renamed to changelog_kkuc_cb(),
since it is really about consuming the ChangeLog and passing it up to
the kernel-user-coms interface.  At some point we should consider to
implement a DBUS-based ChangeLog interface as well.

The changelog_kkuc_cb() "sanity check" on cr_type was removed, since
there is no reason the client kernel needs to know every record type
that is being passed to userspace.  It is up to the client tool to
determine what records that it can process.

Signed-off-by: Andreas Dilger <andreas.dilger@intel.com>
Change-Id: Id8e6471827a89d8c62808e6b3cfd9693d63ebbe5
Reviewed-on: http://review.whamcloud.com/6335
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: jacques-Charles Lafoucriere <jacques-charles.lafoucriere@cea.fr>
Reviewed-by: Jinshan Xiong <jinshan.xiong@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>