From b41b7d7ddf6d3fba23ac7978c8b272f2ff84265d Mon Sep 17 00:00:00 2001

From: "Richard W.M. Jones" <rjones@redhat.com>

Date: Thu, 21 Apr 2022 16:14:46 +0100

Subject: [PATCH] readahead: Fix test

The previous test turned out to be pretty bad at testing the new

filter.  A specific problem is that the filter starts a background

thread which issues .cache requests, while on the main connection

.pread requests are being passed through.  The test used

--filter=readahead --filter=cache with the cache filter only caching

on .cache requests (since cache-on-read defaults to false), so only

caching requests made by the background thread.

                       main thread

  client ---- .pread ----- delay-filter -------> plugin

             \

              \     background thread

               .cache --- cache-filter

Under very high load, the background thread could be starved.  This

means no requests were being cached at all, and all requests were

passing through the delay filter.  It would appear that readahead was

failing (which it was, in a way).

It's not very easy to fix this since readahead is best-effort, but we

can go back to using a simpler plugin that logs reads and caches and

check that they look valid.

Update: commit 2ff548d66ad3eae87868402ec5b3319edd12090f

(cherry picked from commit db1e3311727c6ecab3264a1811d33db1aa45a4d0)

---

 tests/test-readahead.sh | 61 +++++++++++++++++++++++------------------

 1 file changed, 35 insertions(+), 26 deletions(-)

diff --git a/tests/test-readahead.sh b/tests/test-readahead.sh

index 17126e5a..37f4a06f 100755

--- a/tests/test-readahead.sh

+++ b/tests/test-readahead.sh

@@ -30,43 +30,52 @@

 # OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF

 # SUCH DAMAGE.

-# Is the readahead filter faster?  Copy a blank disk with a custom

-# plugin that sleeps on every request.  Because the readahead filter

-# should result in fewer requests it should run faster.

-

 source ./functions.sh

 set -e

 set -x

-requires_filter delay

+requires_plugin sh

 requires nbdsh --version

 requires dd iflag=count_bytes 

-files="readahead.img"

+files="readahead.out"

 rm -f $files

 cleanup_fn rm -f $files

-test ()

-{

-    start_t=$SECONDS

-    nbdkit -fv -U - "$@" null size=1M --filter=delay rdelay=5 \

-           --run 'nbdsh --uri "$uri" -c "

+nbdkit -fv -U - "$@" sh - \

+       --filter=readahead \

+       --run 'nbdsh --uri "$uri" -c "

 for i in range(0, 512*10, 512):

     h.pread(512, i)

-"'

+"' <<'EOF'

+case "$1" in

+     thread_model)

+         echo parallel

+         ;;

+     can_cache)

+         echo native

+         ;;

+     get_size)

+         echo 1M

+         ;;

+     cache)

+         echo "$@" >> readahead.out

+         ;;

+     pread)

+         echo "$@" >> readahead.out

+         dd if=/dev/zero count=$3 iflag=count_bytes

+         ;;

+     *)

+         exit 2

+         ;;

+esac

+EOF

-    end_t=$SECONDS

-    echo $((end_t - start_t))

-}

+cat readahead.out

-t1=$(test --filter=readahead --filter=cache)

-t2=$(test)

-

-# In the t1 case we should make only 1 request into the plugin,

-# resulting in around 1 sleep period (5 seconds).  In the t2 case we

-# make 10 requests so sleep for around 50 seconds.  t1 should be < t2

-# is every reasonable scenario.

-if [ $t1 -ge $t2 ]; then

-    echo "$0: readahead filter took longer, should be shorter"

-    exit 1

-fi

+# We should see the pread requests, and additional cache requests for

+# the 32K region following each pread request.

+for i in `seq 0 512 $((512*10 - 512))` ; do

+    grep "pread  512 $i" readahead.out

+    grep "cache  32768 $((i+512))" readahead.out

+done

-- 

2.31.1