LU-5263 llite: update ras stride offset

When a read ahead does not reach the end of the region reserved from
ras, we'd set ras::ras_next_readahead back to where we left off; For
stride read ahead, it needs to make sure that the offset is no less
than ras_stride_offset, so that the stride read ahead can work
correctly.

This patch is back-ported from the following one:
Lustre-commit: 9e280281b8daf8ad69d04a5371121224ace28fbc
Lustre-change: http://review.whamcloud.com/11181

Signed-off-by: Bobi Jam <bobijam.xu@intel.com>
Change-Id: I5d319a94435833153c52da6ccc1b20c4952789e9
Signed-off-by: Jian Yu <jian.yu@intel.com>
Reviewed-on: http://review.whamcloud.com/11455
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-4604 obdclass: handle ldt_device_nr/ldt_linkage properly

It is partly back-ported the patch from master:
"LU-4604 lfsck: LFSCK async updates RPC flow control"
But this only contains the part related with lu_device fixes,
not the lfsck async RPC changes.

There was no protection when inc/dec lu_device_type::ldt_device_nr,
which may caused the ldt_device_nr to be wrong and trigger assert.
This patch redefine lu_device_type::ldt_device_nr as atomic type.

There was no protection when add/del lu_device_type::ldt_linkage
into/from the global lu_device_types list, which may caused bad
address accessing. This patch uses the existing obd_types_lock
to protect related operations.

We do NOT need lu_types_stop() any longer. Such function scans
the global lu_device_types list, and for each type item on it
which has zerod lu_device_type::ldt_device_nr, call its stop()
method. In fact, the lu_device_type::ldt_device_nr only will be
zero when the last lu_device_fini() is called, and at that time,
inside the lu_device_fini(), its stop() method will be called.
So it is unnecessary to call the stop() again via lu_types_stop().

Lustre-commit: caef708d4040fd13499a11a42507ba56f9454298
Lustre-change: http://review.whamcloud.com/8694

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: Ibea9e8f51191de76dbd2e199e01b1d2adff35c75
Reviewed-on: http://review.whamcloud.com/12531
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Mike Pershin <mike.pershin@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>