LU-797 tests: fix ost-pools test timeout issues on b1_8

The test time of the ost-pools subtests is unreasonably long.

test_14 fills an OST to 90% full, regardless of the OST size.
Skip the test if the amount of data to be written is too large
to run in a practical time.

test_18 creates 3x3x30000 files to compare performance with/without
pools enabled.  Instead of creating a fixed number of files, use
createmany to run for a specific (short) time to measure
performance.

test_23 tried to fill all OSTs 100% full.  Split this test into two:
- test_23a to test quota with a file in a pool
- test_23b to test OOS with a file striped over pool

The following patches are merged into this one:
- LU-797 tests: speed up ost-pools tests
(master patch eea698c944283b755882d8f504d2fcc8ea371bd8)
- LU-797 tests: skip ost-pools.sh 23b when SLOW=no
(master patch f7b4054cfc1d30fbbfd56acfe4b5a7a334de8212)
- LU-797 tests: process lfs df output properly
(master patch b1a1ec6300a5ec3925b725d5d2b783314dff3f8)
- LU-797 tests: improve test_23b of ost-pools.sh
(master patch 6dd41a43e3cdff1b2e0713cfc163734889d8650a)

Test-Parameters: envdefinitions=SLOW=yes testlist=ost-pools

Signed-off-by: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: Niu Yawei <niu@whamcloud.com>
Signed-off-by: Liu Ying <emoly.liu@intel.com>
Change-Id: I391e641664890e7172d2ed1da815894e656826ce
Reviewed-on: http://review.whamcloud.com/4898
Tested-by: Hudson
Reviewed-by: Niu Yawei <yawei.niu@intel.com>
Reviewed-by: Jian Yu <jian.yu@intel.com>
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Johann Lombardi <johann.lombardi@intel.com>
LU-1129 obdfilter: handle race condition of recreating objects

During OST recovery, a race can happen while handling replayed
OST_WRITE request during the MDS->OST orphan recovery period to
recreate missing objects, which can trigger ASSERTION(diff >= 0)
failure.

This patch handles the above issue by adding obd->obd_recovering
into the assertion to check whether the OST is in recovery or not.
If it's in recovery and diff < 0, then no assertion failure occurs,
the object has been recreated. If the OST is not in recovery and
diff < 0, then the assertion failure occurs.

Test-Parameters: envdefinitions=SLOW=yes,ENABLE_QUOTA=yes testlist=sanity-quota
Signed-off-by: Jian Yu <jian.yu@intel.com>
Change-Id: I346875378802385a95b0832b76d19f9957910cdf
Reviewed-on: http://review.whamcloud.com/5013
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Jinshan Xiong <jinshan.xiong@intel.com>
Reviewed-by: Fan Yong <fan.yong@intel.com>
Reviewed-by: Johann Lombardi <johann.lombardi@intel.com>