https://tracker.ceph.com/https://tracker.ceph.com/favicon.ico2017-10-23T10:43:36ZCeph CephFS - Bug #21884: client: populate f_fsid in statfs outputhttps://tracker.ceph.com/issues/21884?journal_id=1012252017-10-23T10:43:36ZJeff Laytonjlayton@redhat.com
<ul></ul><p>Here's how the kernel client fills this field out:</p>
<pre>
/* 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;
</pre>
<p>We could simply do the same thing in the userland client, but I think this is actually wrong.</p>
<p>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).</p>
<p>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.</p> CephFS - Bug #21884: client: populate f_fsid in statfs outputhttps://tracker.ceph.com/issues/21884?journal_id=1012492017-10-23T17:46:43ZPatrick Donnellypdonnell@redhat.com
<ul><li><strong>Subject</strong> changed from <i>client: populate fs id in statfs output</i> to <i>client: populate f_fsid/f_type in statfs output</i></li><li><strong>Description</strong> updated (<a title="View differences" href="/journals/101249/diff?detail_id=98201">diff</a>)</li></ul> CephFS - Bug #21884: client: populate f_fsid in statfs outputhttps://tracker.ceph.com/issues/21884?journal_id=1012532017-10-23T19:51:19ZJeff Laytonjlayton@redhat.com
<ul></ul><p>I'm not sure we want to change f_type. It <em>is</em> still FUSE, regardless of what userland daemon it's talking to.</p>
<p>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.</p>
<p>FUSE doesn't present anything from userland in this field, so we'd need to plumb that support in.</p>
<p>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.</p>
<p>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.</p> CephFS - Bug #21884: client: populate f_fsid in statfs outputhttps://tracker.ceph.com/issues/21884?journal_id=1012792017-10-24T20:23:23ZPatrick Donnellypdonnell@redhat.com
<ul></ul><p>Jeff, I liked your suggestion of a vxattr the client can lookup to check if the mount is CephFS.</p> CephFS - Bug #21884: client: populate f_fsid in statfs outputhttps://tracker.ceph.com/issues/21884?journal_id=1015952017-10-30T13:45:50ZPatrick Donnellypdonnell@redhat.com
<ul><li><strong>Priority</strong> changed from <i>High</i> to <i>Low</i></li></ul><p>Waiting for FUSE support on this.</p> CephFS - Bug #21884: client: populate f_fsid in statfs outputhttps://tracker.ceph.com/issues/21884?journal_id=1306032019-03-04T18:07:43ZJeff Laytonjlayton@redhat.com
<ul><li><strong>Subject</strong> changed from <i>client: populate f_fsid/f_type in statfs output</i> to <i>client: populate f_fsid in statfs output</i></li></ul> CephFS - Bug #21884: client: populate f_fsid in statfs outputhttps://tracker.ceph.com/issues/21884?journal_id=1306042019-03-04T18:17:26ZJeff Laytonjlayton@redhat.com
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Resolved</i></li></ul><p>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.</p>
<p>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.</p>