Red Hat Bugzilla – Bug 1502384
[CephFS] FUSE mount "stat" command output reports ID: 0
Last modified: 2018-02-05 18:21:48 EST
Description of problem: FUSE mount "stat" command output reports "ID: 0" value where in kernel mount has ID value. ==================In Kernel Mount================ [ubuntu@host006 ~]$ sudo stat -f /mnt/cephfs/ File: "/mnt/cephfs/" ID: deb736e6918fe9e3 Namelen: 255 Type: ceph Block size: 4194304 Fundamental block size: 4194304 Blocks: Total: 2133642 Free: 1277776 Available: 1277776 Inodes: Total: 6231765 Free: -1 ==================In Fuse Mount================== [ubuntu@host070 ~]$ sudo stat -f /mnt/cephfs/ File: "/mnt/cephfs/" ID: 0 Namelen: 255 Type: fuseblk Block size: 4194304 Fundamental block size: 4194304 Blocks: Total: 2133642 Free: 1277774 Available: 1277774 Inodes: Total: 6231765 Free: -1 Version-Release number of selected component (if applicable): ceph version 12.2.1-10.el7cp (5ba1c3fa606d7bf16f72756b0026f04a40297673) luminous (stable) How reproducible: Every time Steps to Reproduce: 1. Configure CephFS FUSE and Kernel client 2. run "stat -f <mount-point>" on client where FS mounted. Actual results: Fuse ID value is 0 Expected results: NA Additional info: Above output captured for same FS but with FUSE and Kernel mount.
I just ran stat -f on a local sshfs fuse mount, and also saw ID 0. Do any fuse filesystems populate an ID here?
(In reply to John Spray from comment #3) > I just ran stat -f on a local sshfs fuse mount, and also saw ID 0. Do any > fuse filesystems populate an ID here? Well spotted. FUSE apparently intentionally sets the FSID to 0, regardless of what the lower fs returns. static void convert_fuse_statfs(struct kstatfs *stbuf, struct fuse_kstatfs *attr) { stbuf->f_type = FUSE_SUPER_MAGIC; stbuf->f_bsize = attr->bsize; stbuf->f_frsize = attr->frsize; stbuf->f_blocks = attr->blocks; stbuf->f_bfree = attr->bfree; stbuf->f_bavail = attr->bavail; stbuf->f_files = attr->files; stbuf->f_ffree = attr->ffree; stbuf->f_namelen = attr->namelen; /* fsid is left zero */ } FUSE has been that way since its inception, so we'd need to change that if you really want something non-zero in there. Adding Miklos to ask: Is there a particular reason to leave that zeroed out? I know that the fsid is pretty poorly-defined in general, but it seems like we should allow filesystems to present it if they choose.
(In reply to Jeff Layton from comment #7) > Is there a particular reason to leave that zeroed out? I don't remember, TBH. > I know that the fsid > is pretty poorly-defined in general, but it seems like we should allow > filesystems to present it if they choose. I guess so, except for unprivileged mounts. We definitely don't want unprivileged userspace to present an arbitrary fsid for whatever malicious intent. Should not be difficult to add to protocol and libfuse API. It should be optional (i.e. controlled by a FUSE_CAP_* flag) otherwise we will break backward compatibility.