Gluster users - May 2012 - fchown() and write() returning ENOENT error

Hi,

SQLite is an embedded database system that uses posix APIs
to access a database stored in a single file on disk:

   http://www.sqlite.org

We have a user who is seeing unusual IO errors when attempting
to use an SQLite database stored on GlusterFS from multiple
clients simultaneously. The [strace] logs show this:

   205 open("test.sqlite3-journal", O_RDWR|O_CREAT|O_CLOEXEC, 0644) =
4
   207 fchown(4, 0, 0)      = -1 ENOENT
   212 write(4, "...", 512) = -1 ENOENT

Does anybody know why this might happen with GlusterFS? If the
client opens the file handle successfully as shown, then a second
client deletes the underlying file before the fchown() call is made,
might the first client get the ENOENT errors that can be seen above?
Are there any other possible causes?

Thanks,
Dan Kennedy.

Is the access via FUSE or NFS?

Avati

On Thu, May 24, 2012 at 12:34 AM, Dan Kennedy <danielk1977 at gmail.com>
wrote:
>
> Hi,
>
> SQLite is an embedded database system that uses posix APIs
> to access a database stored in a single file on disk:
>
>  http://www.sqlite.org
>
> We have a user who is seeing unusual IO errors when attempting
> to use an SQLite database stored on GlusterFS from multiple
> clients simultaneously. The [strace] logs show this:
>
>  205 open("test.sqlite3-journal", O_RDWR|O_CREAT|O_CLOEXEC, 0644)
= 4
>  207 fchown(4, 0, 0)      = -1 ENOENT
>  212 write(4, "...", 512) = -1 ENOENT
>
> Does anybody know why this might happen with GlusterFS? If the
> client opens the file handle successfully as shown, then a second
> client deletes the underlying file before the fchown() call is made,
> might the first client get the ENOENT errors that can be seen above?
> Are there any other possible causes?
>
> Thanks,
> Dan Kennedy.
>
>
>
> ______________________________**_________________
> Gluster-users mailing list
> Gluster-users at gluster.org
>
http://gluster.org/cgi-bin/**mailman/listinfo/gluster-users<http://gluster.org/cgi-bin/mailman/listinfo/gluster-users>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20120524/fd392956/attachment.html>

I am the affected user of this thread:

http://gluster.org/pipermail/gluster-users/2012-May/010384.html

I am using the file system using FUSE. Tested with gluster 3.2 and
3.3, the behavior is same. I have test with quick-read = ON and also
using quick-read = OFF. Still that SQLite problematic behavior is
happening in all those cases. It happens only if we are accessing a
single SQLite file from two different gluster clients.

WIth quick-read=ON I had this in the gluster client log. Did not get
any log after turning quick-read = OFF.

--
Sabya