[Gluster-devel] DHT NULL pointer usage
Shyam
srangana at redhat.com
Mon Nov 17 14:50:17 UTC 2014
On 11/17/2014 07:20 AM, Emmanuel Dreyfus wrote:
> Hello
>
> I have an almost reliable test that fails on NetBSD:
>
>> ./tests/basic/ec/quota.t (Wstat: 0 Tests: 22 Failed: 3)
>> Failed tests: 19-21
>
> This one is a real bug: glusterfsd crashed because of a NULL pointer. I
> am going to submit a change to avoid touhcing postbuf is op_ret = -1 but
> if someone has a better idea, please let me know.
This should be fine from a DHT perspective. The current tests check if
the file is under migration, using the postbuf attrs sticky and SGID
(for the file). If the FOP errore'd out then the code should look to
check if this is a dht_inode_missing error and then do a phase2 check to
see if the file migrated to a new target (based on a good/bad op_ret).
Looking at the test, it seems that we hit a quota error on the write. In
which case following the file even if it migrated does not make sense.
We should have received an EDQUOT error as the op_errno (if I am not
mistaken) and exited this function at the check below,
dht_writev_cbk:
35: if (op_ret == -1 && !dht_inode_missing(op_errno)) {
36: goto out;
37: }
Are we not sending an EDQUOT upwards in this case?
Validating assumptions:
- As this is an fd based operation, the fd should have been open, and so
why did the writev fail exactly? EDQUOT?
- Was this an NFS based test, which could explain the use of anon-fds
which would return an error if the file is no longer on the backend. Is
this a test run from an NFS mount point?
Shyam
More information about the Gluster-devel
mailing list