Ceph » CephFS

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[0] = fsid & 0xffffffff;
        buf->f_fsid.val[1] = 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.

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.

Jeff, I liked your suggestion of a vxattr the client can lookup to check if the mount is CephFS.