LU-3321 clio: optimize read ahead code

It used to check each page in the readahead window is covered by
a lock underneath, now cpo_page_is_under_lock() provides @max_index
to help decide the maximum ra window. @max_index can be modified by
OSC to extend the maximum lock region, to align stripe boundary at
LOV, and to make sure the readahead region at least covers read
region at LLITE layer.

After this is done, usually readahead code calls
cpo_page_is_under_lock() for each stripe.

Signed-off-by: Jinshan Xiong <jinshan.xiong@intel.com>
Change-Id: Iecce020d01b804b799ad234f623498cc6f2f3fb2
Reviewed-on: http://review.whamcloud.com/8523
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-4540 llite: deadlock for page write

Writing thread already locked page #1, and then wait for the
Writeback bit of page #2;

Ptlrpc thread is composing a write RPC, so it sets Writeback on
page #2 and tries to lock page #1 to make it ready.

Deadlocked.

Signed-off-by: Jinshan Xiong <jinshan.xiong@intel.com>
Change-Id: I2da547b4c93c3464e520a1f593985adae9360bc9
Reviewed-on: http://review.whamcloud.com/9036
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: wangdi <di.wang@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-3950 lfsck: control LFSCK on all devices via single command

Under DNE mode, it is more convenient for the administrator to control
the LFSCK (start/stop) on all the MDT devices via single command. Such
functionality is not only useful for DNE consistency verification, but
also for layout consistency (Phase II). It is also required for orphan
OST-objects scanning.

Test-Parameters: allwaysuploadlogs
Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: Ie0d4611f969e51b80faf27b52dbdaee41caf5187
Reviewed-on: http://review.whamcloud.com/7665
Tested-by: Jenkins
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>