[Bugs] [Bug 1181048] lockless lookup cause disk to be kicked out

[bugzilla at redhat.com]

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

Xavier Hernandez <xhernandez at datalab.es> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lidi at perabytes.com
              Flags|                            |needinfo?(lidi at perabytes.co
                   |                            |m)



--- Comment #3 from Xavier Hernandez <xhernandez at datalab.es> ---
In this case the volume has not been degraded at any moment. These warning are
only caused by an initial lookup. This apparent discrepancy triggers a
self-heal. Self-heal has enough information to lock the inode and repeat the
lookup. This lookup succeeds and self-heal finishes without doing anything
else.

Any other operation on the file uses locks, so there shouldn't be any problem.

This is exactly what I've tested:

gluster volume create test server:/bricks/test{1..3} force
gluster volume start test
mount -t glusterfs server:/test /gluster/test
mkdir -p /gluster/test/a/b/c
while true; do dd if=/dev/zero of=/gluster/test/a/b/c/aa bs=1M count=200; done

on another session:

while true; do ls -l /gluster/test/a/b/c/aa; sleep 1; done

After some time running both commands without any error I've stopped them.

getfattr -m. -e hex -d /bricks/test{1..3}/a/b/c/aa
getfattr: Removing leading '/' from absolute path names
# file: bricks/test1/a/b/c/aa
trusted.ec.config=0x0000080301000200
trusted.ec.size=0x0000000000000000
trusted.ec.version=0x0000000000003208
trusted.gfid=0xe662cae312924039918520bf1be8a1ac

# file: bricks/test2/a/b/c/aa
trusted.ec.config=0x0000080301000200
trusted.ec.size=0x0000000000000000
trusted.ec.version=0x0000000000003208
trusted.gfid=0xe662cae312924039918520bf1be8a1ac

# file: bricks/test3/a/b/c/aa
trusted.ec.config=0x0000080301000200
trusted.ec.size=0x0000000000000000
trusted.ec.version=0x0000000000003208
trusted.gfid=0xe662cae312924039918520bf1be8a1ac

As you can see, file on all three bricks is healthy and fully synchronized.

Logs report some warnings, but no real self-heal has been executed.

Are you seeing something different ?

-- 
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=aVIkloz4NX&a=cc_unsubscribe