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?<br><br>Avati<br><br><div class="gmail_quote">
On Mon, May 21, 2012 at 9:27 AM, Emmanuel Dreyfus <span dir="ltr"><<a href="mailto:manu@netbsd.org" target="_blank">manu@netbsd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Emmanuel Dreyfus <<a href="mailto:manu@netbsd.org">manu@netbsd.org</a>> wrote:<br>
<br>
> 3548 1 tar CALL rename(0xbb9010e0,0x8071584)<br>
> 3548 1 tar NAMI "usr/src/gnu/CVS/Tag.03548f"<br>
> 3548 1 tar RET rename -1 errno 13 Permission denied<br>
<br>
</div>I tracked this down to FUSE LOOKUP operation that do not set<br>
fuse_entry's attr.uid correctly (it is left set to 0).<br>
<br>
Here is the summary of my findings so far:<br>
- as un unprivilegied user, I create and delete files like crazy<br>
- most of the time everything is fine<br>
- sometime a LOOKUP for a file I created (as an unprivilegied user) will<br>
return a fuse_entry with uid set to 0, which cause the kernel to raise<br>
EACCESS when I try to delete the file.<br>
<br>
Here is an example of a FUSE trace, produced by the test case<br>
while [ 1 ] ; do cp /etc/fstab test/foo1 ; rm test/foo1 ; done<br>
<br>
> unique = 1435, nodeid = <a href="tel:3098542296" value="+13098542296">3098542296</a>, opcode = LOOKUP (1)<br>
< unique = 1435, nodeid = <a href="tel:3098542296" value="+13098542296">3098542296</a>, opcode = LOOKUP (1), error = -2<br>
> unique = 1436, nodeid = <a href="tel:3098542296" value="+13098542296">3098542296</a>, opcode = CREATE (35)<br>
< unique = 1436, nodeid = <a href="tel:3098542296" value="+13098542296">3098542296</a>, opcode = CREATE (35), error = 0<br>
> unique = 1437, nodeid = <a href="tel:3098542396" value="+13098542396">3098542396</a>, opcode = SETATTR (4)<br>
< unique = 1437, nodeid = <a href="tel:3098542396" value="+13098542396">3098542396</a>, opcode = SETATTR (4), error = 0<br>
> unique = 1438, nodeid = <a href="tel:3098542396" value="+13098542396">3098542396</a>, opcode = WRITE (16)<br>
< unique = 1438, nodeid = <a href="tel:3098542396" value="+13098542396">3098542396</a>, opcode = WRITE (16), error = 0<br>
> unique = 1439, nodeid = <a href="tel:3098542396" value="+13098542396">3098542396</a>, opcode = FSYNC (20)<br>
< unique = 1439, nodeid = <a href="tel:3098542396" value="+13098542396">3098542396</a>, opcode = FSYNC (20), error = 0<br>
> unique = 1440, nodeid = <a href="tel:3098542396" value="+13098542396">3098542396</a>, opcode = RELEASE (18)<br>
< unique = 1440, nodeid = <a href="tel:3098542396" value="+13098542396">3098542396</a>, opcode = RELEASE (18), error = 0<br>
> unique = 1441, nodeid = <a href="tel:3098542396" value="+13098542396">3098542396</a>, opcode = GETATTR (3)<br>
< unique = 1441, nodeid = <a href="tel:3098542396" value="+13098542396">3098542396</a>, opcode = GETATTR (3), error = 0<br>
> unique = 1442, nodeid = <a href="tel:3098542296" value="+13098542296">3098542296</a>, opcode = LOOKUP (1)<br>
< unique = 1442, nodeid = <a href="tel:3098542296" value="+13098542296">3098542296</a>, opcode = LOOKUP (1), error = 0<br>
<br>
--> here I sometimes get fuse_entry's attr.uid incorrectly set to 0<br>
--> When this happens, LOOKUP fails and returns EACCESS.<br>
<br>
> unique = 1443, nodeid = <a href="tel:3098542296" value="+13098542296">3098542296</a>, opcode = UNLINK (10)<br>
< unique = 1443, nodeid = <a href="tel:3098542296" value="+13098542296">3098542296</a>, opcode = UNLINK (10), error = 0<br>
> unique = 1444, nodeid = <a href="tel:3098542396" value="+13098542396">3098542396</a>, opcode = FORGET (2)<br>
<br>
<br>
Is it possible that metadata writes are now so asynchronous that a<br>
subsequent lookup cannot retreive the up to date value? If that is the<br>
problem, how can I fix it? There is nothing telling the FUSE<br>
implementation that a CREATE or SETATTR has just partially completed and<br>
has metadata pending.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Emmanuel Dreyfus<br>
<a href="http://hcpnet.free.fr/pubz" target="_blank">http://hcpnet.free.fr/pubz</a><br>
<a href="mailto:manu@netbsd.org">manu@netbsd.org</a><br>
<br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a><br>
<a href="https://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
</div></div></blockquote></div><br>