Is the FUSE SETATTR implementation in NetBSD synchronous? i.e, does the chown() or chmod() syscall issued by the application strictly block till GlusterFS's fuse_setattr_cbk() is called?
Avati On Mon, May 21, 2012 at 9:27 AM, Emmanuel Dreyfus <[email protected]> wrote: > Emmanuel Dreyfus <[email protected]> wrote: > > > 3548 1 tar CALL rename(0xbb9010e0,0x8071584) > > 3548 1 tar NAMI "usr/src/gnu/CVS/Tag.03548f" > > 3548 1 tar RET rename -1 errno 13 Permission denied > > I tracked this down to FUSE LOOKUP operation that do not set > fuse_entry's attr.uid correctly (it is left set to 0). > > Here is the summary of my findings so far: > - as un unprivilegied user, I create and delete files like crazy > - most of the time everything is fine > - sometime a LOOKUP for a file I created (as an unprivilegied user) will > return a fuse_entry with uid set to 0, which cause the kernel to raise > EACCESS when I try to delete the file. > > Here is an example of a FUSE trace, produced by the test case > while [ 1 ] ; do cp /etc/fstab test/foo1 ; rm test/foo1 ; done > > > unique = 1435, nodeid = 3098542296, opcode = LOOKUP (1) > < unique = 1435, nodeid = 3098542296, opcode = LOOKUP (1), error = -2 > > unique = 1436, nodeid = 3098542296, opcode = CREATE (35) > < unique = 1436, nodeid = 3098542296, opcode = CREATE (35), error = 0 > > unique = 1437, nodeid = 3098542396, opcode = SETATTR (4) > < unique = 1437, nodeid = 3098542396, opcode = SETATTR (4), error = 0 > > unique = 1438, nodeid = 3098542396, opcode = WRITE (16) > < unique = 1438, nodeid = 3098542396, opcode = WRITE (16), error = 0 > > unique = 1439, nodeid = 3098542396, opcode = FSYNC (20) > < unique = 1439, nodeid = 3098542396, opcode = FSYNC (20), error = 0 > > unique = 1440, nodeid = 3098542396, opcode = RELEASE (18) > < unique = 1440, nodeid = 3098542396, opcode = RELEASE (18), error = 0 > > unique = 1441, nodeid = 3098542396, opcode = GETATTR (3) > < unique = 1441, nodeid = 3098542396, opcode = GETATTR (3), error = 0 > > unique = 1442, nodeid = 3098542296, opcode = LOOKUP (1) > < unique = 1442, nodeid = 3098542296, opcode = LOOKUP (1), error = 0 > > --> here I sometimes get fuse_entry's attr.uid incorrectly set to 0 > --> When this happens, LOOKUP fails and returns EACCESS. > > > unique = 1443, nodeid = 3098542296, opcode = UNLINK (10) > < unique = 1443, nodeid = 3098542296, opcode = UNLINK (10), error = 0 > > unique = 1444, nodeid = 3098542396, opcode = FORGET (2) > > > Is it possible that metadata writes are now so asynchronous that a > subsequent lookup cannot retreive the up to date value? If that is the > problem, how can I fix it? There is nothing telling the FUSE > implementation that a CREATE or SETATTR has just partially completed and > has metadata pending. > > -- > Emmanuel Dreyfus > http://hcpnet.free.fr/pubz > [email protected] > > _______________________________________________ > Gluster-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/gluster-devel >
_______________________________________________ Gluster-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/gluster-devel
