Bug 1502384 - [CephFS] FUSE mount "stat" command output reports ID: 0
Summary: [CephFS] FUSE mount "stat" command output reports ID: 0
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Ceph Storage
Classification: Red Hat
Component: CephFS
Version: 3.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: 3.1
Assignee: Jeff Layton
QA Contact: ceph-qe-bugs
Bara Ancincova
URL:
Whiteboard:
Depends On:
Blocks: 1494421
TreeView+ depends on / blocked
 
Reported: 2017-10-16 03:04 UTC by Ramakrishnan Periyasamy
Modified: 2018-02-05 23:21 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
.The `stat` command returns `ID: 0` for CephFS FUSE clients When a Ceph File System (CephFS) is mounted as a File System in User Space (FUSE) client, the `stat` command outputs `ID: 0` instead of a proper ID.
Clone Of:
Environment:
Last Closed: 2018-02-05 23:21:48 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Ceph Project Bug Tracker 21884 None None None 2017-10-24 20:20:55 UTC

Description Ramakrishnan Periyasamy 2017-10-16 03:04:46 UTC
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.

Comment 3 John Spray 2017-10-16 09:31:03 UTC
I just ran stat -f on a local sshfs fuse mount, and also saw ID 0.  Do any fuse filesystems populate an ID here?

Comment 7 Jeff Layton 2017-10-23 15:27:11 UTC
(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.

Comment 8 Miklos Szeredi 2017-10-24 07:35:15 UTC
(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.


Note You need to log in before you can comment on or make changes to this bug.