Bug 1502384
Summary: | [CephFS] FUSE mount "stat" command output reports ID: 0 | ||
---|---|---|---|
Product: | [Red Hat Storage] Red Hat Ceph Storage | Reporter: | Ramakrishnan Periyasamy <rperiyas> |
Component: | CephFS | Assignee: | Jeff Layton <jlayton> |
Status: | CLOSED CANTFIX | QA Contact: | ceph-qe-bugs <ceph-qe-bugs> |
Severity: | medium | Docs Contact: | Bara Ancincova <bancinco> |
Priority: | unspecified | ||
Version: | 3.0 | CC: | ceph-eng-bugs, hnallurv, jlayton, john.spray, mszeredi, pdonnell |
Target Milestone: | rc | ||
Target Release: | 3.1 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
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.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2018-02-05 23:21:48 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1494421 |
Description
Ramakrishnan Periyasamy
2017-10-16 03:04:46 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? (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. |