Bug 762204 (GLUSTER-472)

A user on IRC reported that he'd get a bus fault when trying to run OpenOffice when $HOME was on a GlusterFS filesystem.  I was able to reproduce this behavior on my own setup, and observed that it had to do with the following sequence of operations on a temp file: open(O_TRUNC), unlink, ftruncate (to 4K), mmap (read+write), mmap (read+exec).  It turns out that the ftruncate was failing with ENOENT, so the file was never actually extended and thus the expected page was never valid.

The reason that the ftruncate failed was that fuse_setattr saw a failure from fuse_loc_fill, which did fill in loc->inode but subsequently failed to fill in loc->path for the by-now-unlinked file.  My understanding of the code is that one or the other should be sufficient, with the inode preferred, so this should not cause an error.  I was able to verify that fixing fuse_setattr to work around this condition allowed OpenOffice to work, and didn't see any obvious problems in other quick testing, so I sent the user a patch to see if this improved his situation.

I haven't heard back yet, but I think this is a more fundamental problem with how fuse_loc_fill reports status and it affects many calls in fuse-bridge.c besides fuse_setattr.  I've generated a more comprehensive patch in which fuse_loc_fill reports success if it's able to fill in either the inode or the path, even if the other fails, and testing so far has revealed no new problems.  Is there any reason people know of why we couldn't adopt this approach generally?

Apologies if the component/priority/etc. aren't set correctly.  I'm not quite up on the local definitions or policies for such things.