[Gluster-devel] DHT NULL pointer usage

[Xavier Hernandez]

What seems to be happening:

The interesting part of quota.t contains:

16: TEST ! dd if=/dev/urandom of=$M0/test/file1.txt bs=1024k count=12
17: TEST rm $M0/test/file1.txt
18: EXPECT_WITHIN $MARKER_UPDATE_TIMEOUT "0Bytes" usage "/test"
19: TEST dd if=/dev/urandom of=$M0/test/file2.txt bs=1024k count=8

at this point, the volume is configured with a quota of 10MB, so the 
test 16 should fail.

ec xlator receives the create and many write fops. At some point, fops 
start returning EDQUOT, but many other write requests are still being 
processed. Somehow seems that the control returns to the user before all 
write request complete (there seems to be an FSYNC request, but it never 
reaches ec). The user deletes the file on the next test (17). This 
causes that some of the pending writes return ENOENT (not sure why 
because the inode should not have been deleted).

The ENOENT error causes a segmentation fault on DHT. This segmentation 
fault is asynchronous and coincides with the test 19, but it's not the 
responsible of the failure.

A message appears on the console (probably when dd finishes and closes 
the file):

perfused: perfuse_node_inactive: perfuse_node_fsync failed error = 69: 
Resource temporarily unavailable

Note that errno 69 is EDQUOT on NetBSD. Not sure what does mean or if 
it's important.

I'm not sure what is happening here, and why some write requests keep 
floating after the command that launched them has finished (dd). 
Probably it's an ec bug, but I don't see where.

If anyone has any clue, it will be appreciated. Otherwise I'll look 
deeper into it tomorrow.

Xavi

On 11/17/2014 05:18 PM, Emmanuel Dreyfus wrote:
> On Mon, Nov 17, 2014 at 05:08:18PM +0100, Xavier Hernandez wrote:
>> Ok. Let me know login credentials and I'll try to see what's happening.
>
> ssh jenkins at nbslave70.cloud.gluster.org with usual password
> then become root using su and:
> cd /autobuild/glusterfs && ./run-tests.sh -f ./tests/basic/ec/quota.t
>
> While there you can also give a try to ./tests/basic/ec/self-heal.t
> which also has a failure.
>