[Bugs] [Bug 1300875] Client self-heals block the FOP that triggered the heals

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1300875

nchilaka <nchilaka at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ON_QA                       |VERIFIED



--- Comment #13 from nchilaka <nchilaka at redhat.com> ---
QATP and Results:(all cases are working as expected) hence moving to verified
test version:3.7.9-6  (tested on fuse mount)
================
    QATP:

    TC#1:   steps reported in bug  ==>PASS

    1.Create a 1x2 replica, fuse mount and create a file.

    2.Disable self-heal daemon

    2.Kill a brick, `dd` a few gigs into the file.

    3.Bring the brick back up, do a hexdump of file from the mount.

    4.Hexdump will stall spewing out data until the data heal completes (as
seen from the mount log)

 Comment by Ravi " Correction here: File reads (i.e. hexdump of       file)
should spew out data immediately, without waiting for the       heal to happen.
(This wasn't the case prior to the fix)."

    TC#2:   scenario#2 ==>PASS

    1.Create a 1x2 replica, fuse mount and create a file.

    2.Disable self-heal daemon

    3.Kill a brick,copy  some 10 music files

    4.Bring the brick back up, and now play the music files

    5.the music files must be playing without any interruption and heal must
take place in the background




    Expected result: only 10 must be getting healed, however all the files must
be accessible and no IO must hang


    TC#3:  testing the functionality of background-self-heal-count=2,
heal-wait-queue-leng=3   =>PASS

    1.Create a 1x2 replica, fuse mount and create a file.

    2.Disable self-heal daemon

    3. set  background-self-heal-count=2 proceed with below tests

    4. Now create some 10 dummy files

    5. Now bring down one brick and create atleast 200 5GB files

    6. Now bring back the brick online

    7. Now open all  files from same mount point (different terminals) and keep
accessing them (how do i do that) => Comment by Ravi "You could try  `hexdump
file&` "

    8. Now check the backend bricks

    Expected result: only 2 file must be getting healed at a time  however all
the files must be accessible and no IO must hang

 Comment by Ravi " The  files queued in the wait queue will be       again
picked up for  background heal when currently undergoing       heals complete ,
so all  files may eventually be healed if they       were accessed."
Comment by Ravi "I think a simpler way would be to set the       limits to a
smaller value and verify. For example, bg selfheal       count=2,
wait-queue-length=1. Then try with 5 big files that need       healing. Only 3
should be healed."

Comment by Ravi " It would also be good to add a negative test       case where
setting the bg selfheal count and waitqueue length to       zero does not
trigger data self-heals when files are accessed."

    TC#4: back-ground self heal-count is per client and not per volume =>pass

    1.Create a 1x2 replica, fuse mount and create a file.

    2.Disable self-heal daemon

    3. set  background-self-heal-count=2 proceed with below tests

    4. Now create some 10 dummy files

    5. Now bring down one brick and create atleast 10 10GB files say f{1..10}

    6. Now bring back the brick online

    7. Now have atleast 5 different clients and from each client open a
different file using hexdump or octal dump(od)

    8. Now check the backend bricks

    Expected result: all the 5 files must be getting healed with no hangs in
the octal dump as the background-self-heal-count is per client and not per
volume however all the files must be accessible and no IO must hang

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=p3XdJSxRii&a=cc_unsubscribe