[Bugs] [Bug 1424805] New: Gluster returns EINVAL for close() when linux-aio and use-compound-fops are both enabled

bugzilla at redhat.com bugzilla at redhat.com
Sun Feb 19 15:33:10 UTC 2017


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

            Bug ID: 1424805
           Summary: Gluster returns EINVAL for close() when linux-aio and
                    use-compound-fops are both enabled
           Product: GlusterFS
           Version: 3.9
         Component: libgfapi
          Assignee: bugs at gluster.org
          Reporter: nh2-redhatbugzilla at deditus.de
        QA Contact: sdharane at redhat.com
                CC: bugs at gluster.org



Description of problem:

I have a program that does, in this order, `open()`, `sendfile()`, `close()`
syscalls to copy a file.

When I have both `storage.linux-aio on` and `cluster.use-compound-fops on`,
there is a race condition that makes the `close()` return `errno = EINVAL`.

This is especially suspicious because `close()` cannot result in `EINVAL`
according to `man 2 close`.

`EINVAL` is also returned for other operations besides `close()`, e.g. for
`fsync()`.

Turning off either of `storage.linux-aio` or `cluster.use-compound-fops` fixes
the problem, so I assume that the bug only exists if both are enabled.

Version-Release number of selected component (if applicable):

3.9.1

How reproducible:

Always

Steps to Reproduce:
1. Over a list of local files (you need multiple because it's a
nondeterministic race)
2. Copy each file to a gluster volume by using `open + sendfile + close`
(properly checking return code and errno  of close()).

Actual results:

After a few files, close will return -1 and errno will be set to 22 (EINVAL).

Expected results:

All files copy without problem.

Additional info:

I found this commit
https://github.com/gluster/glusterfs/commit/88d772c05c45c467bfccebfc51f6a0e0ea9ca287
which seems to deal with a similar issue; skimming over it, it seems to suggest
that somehow the close is issued before the write operation is done.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.


More information about the Bugs mailing list