Open
Description
On July 7, 2014, the nightly builds failed due to a failure in the test/util/opal_path_nfs test. I noticed on the build machine, the following mount was present:
[9:20] jaguar:~/tmp % mount | grep dikim
encfs on /nfs/users/dikim/.passwords type fuse.encfs (rw,nosuid,nodev,default_permissions,user=dikim)
[9:20] jaguar:~/tmp %
It looks like statfs() is lying about the type of filesystem for this mount. Specifically:
[9:20] jaguar:~/tmp % cat foo.c
#include <stdio.h>
#include <sys/vfs.h>
int main()
{
struct statfs buf;
const char *file = "/nfs/users/dikim/.passwords";
int rc = statfs(file, &buf);
printf("ret:%d, f type: 0x%x\n", rc, buf.f_type);
return 0;
}
[9:21] jaguar:~/tmp % gcc foo.c -o foo.x -g && ./foo.x
ret:0, f type: 0x6969
[9:21] jaguar:~/tmp %
According to statfs(2) on RHEL 6.5, 0x6969 is the super magic value for NFS. fuse/encfs is not listed.
I.e., I ''suspect'' that statfs() is confused about the filesystem type of this mount and just gives it an NFS value, especially since there's another mount on this machine:
[9:23] jaguar:~/tmp % mount | grep users
encfs on /nfs/users/dikim/.passwords type fuse.encfs (rw,nosuid,nodev,default_permissions,user=dikim)
deep-thought.osl.iu.edu:/home/users on /nfs/users type nfs (rw,nosuid,nodev,soft,intr,sloppy,addr=10.79.247.75)
[9:23] jaguar:~/tmp %
So I don't know if there's really anything we can do about this -- if statfs() lies to us, I'm not sure what we can do... But I figured I'd file this bug just to record what happened.