client: populate f_fsid in statfs output
We should just reuse the kclient
f_id f_type as, in principle, the application should only need to know that the file system is CephFS and not what kind of client agent is being used.
Edit: I was originally thinking of f_type in the description of the bug. We want to fix both f_fsid and f_type.
#1 Updated by Jeff Layton over 5 years ago
Here's how the kernel client fills this field out:
/* leave fsid little-endian, regardless of host endianness */ fsid = *(u64 *)(&monmap->fsid) ^ *((u64 *)&monmap->fsid + 1); buf->f_fsid.val = fsid & 0xffffffff; buf->f_fsid.val = fsid >> 32;
We could simply do the same thing in the userland client, but I think this is actually wrong.
It's taking the fsid as an opaque value, which means that it will appear to be different on big and little endian machines. I think we want that to look consistent no matter the machine endianness. That allows a big endian machine to communicate the fsid to a little-endian machine without them worrying about endianness (in principle).
This code goes way back to the initial 2009 code drop into the kernel. I think we ought to fix the kernel client to present this consistently no matter the endianness, and then fix up the fuse client to do the same thing.
#2 Updated by Patrick Donnelly over 5 years ago
- Subject changed from client: populate fs id in statfs output to client: populate f_fsid/f_type in statfs output
- Description updated (diff)
#3 Updated by Jeff Layton over 5 years ago
I'm not sure we want to change f_type. It is still FUSE, regardless of what userland daemon it's talking to.
If we did want to do this, I think we'd want some way to distinguish between the f_type that the kernel client uses and the f_type that the FUSE client uses. Even if they are equivalent, they are different implementations.
FUSE doesn't present anything from userland in this field, so we'd need to plumb that support in.
Finally, the "registry" of f_types (such as it is) is in the kernel headers. If FUSE did this, we'd need some way to ensure that there aren't collisions.
What might work better there is leave f_type alone, and present a fuse-daemon specific value via some other mechanism, if there truly is a need for it.
#4 Updated by Patrick Donnelly over 5 years ago
Jeff, I liked your suggestion of a vxattr the client can lookup to check if the mount is CephFS.
#5 Updated by Patrick Donnelly over 5 years ago
- Priority changed from High to Low
Waiting for FUSE support on this.
#6 Updated by Jeff Layton about 4 years ago
- Subject changed from client: populate f_fsid/f_type in statfs output to client: populate f_fsid in statfs output
#7 Updated by Jeff Layton about 4 years ago
- Status changed from New to Resolved
The kernel FUSE fs hasn't gained the capability to present a f_fsid and adding it would open a big can of worms (since we'd to mitigate skulduggery by unprivileged mounts). We could add the ability to present this via libcephfs, but ganesha already uses the stx_dev for the fsid, so I don't think it'd gain us much there.
I'm going to go ahead and close this bug as RESOLVED since the original problem was with the kernel and that has long since been fixed.