Project

General

Profile

Actions

Bug #53045

closed

stat->fsid is not unique among filesystems exported by the ceph server

Added by Jeff Layton over 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Correctness/Safety
Target version:
% Done:

0%

Source:
Tags:
Backport:
pacific,octopus
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
Labels (FS):
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

We are working on a new kubernetes operator to export ceph filesystem using samba. To do this, we mount the filesystem across multiple nodes and use ctdb to allow us to setup an active-active cluster. One of the issues we were investigating was the issue of filehandles(file_id) generated by Samba. It is critical that the filehandle is consistent on all the nodes of the cluster. The file handles are usually generated using the device id and the inode number of the file.

The deviceid is obtained from the stat() call with return value stat->st_dev. On ceph-kmod, this value is eventually obtained from get_anon_bdev() which generates a virtual block device with a generated device id. This can be different on different nodes and will depend on the order in which the filesystems were mounted. We therefore cannot use the device id to generate the filehandle since we cannot guaranty that the device id across the nodes will be the same.

We were therefore investigating the fsid obtained with a statfs() which returns statfs->f_fsid. We can use this with the samba vfs_plugin vfs_fileid to generate consistent filehandles across the cluster. This is set at

static int ceph_statfs(struct dentry *dentry, struct kstatfs *buf)
{
..
        fsid = le64_to_cpu(*(__le64 *)(&monc->monmap->fsid)) ^
               le64_to_cpu(*((__le64 *)&monc->monmap->fsid + 1));
..    
        buf->f_fsid = u64_to_fsid(fsid);
..
}

But since the monc->monmap->fsid is the cluster id, we may need an additional component to differentiate between the multiple file systems exported from the cluster.
Without this change, we may have two different files on two different filesystems exported from the same cluster end up with the same filehandle which could lead to problems on the Samba file server.


Related issues 1 (0 open1 closed)

Copied from Linux kernel client - Bug #52812: stat->fsid is not unique among filesystems exported by the ceph serverResolvedJeff Layton

Actions
Actions #1

Updated by Jeff Layton over 2 years ago

  • Copied from Bug #52812: stat->fsid is not unique among filesystems exported by the ceph server added
Actions #2

Updated by Jeff Layton over 2 years ago

There is a kernel patch for this in flight at the moment, but we need libcephfs to follow suit. See:

https://lore.kernel.org/ceph-devel/20211005153019.79956-1-jlayton@kernel.org/T/#u

Actions #3

Updated by Jeff Layton over 2 years ago

  • Status changed from Fix Under Review to New
  • Assignee deleted (Jeff Layton)
Actions #4

Updated by Jeff Layton over 2 years ago

  • Description updated (diff)
Actions #5

Updated by Venky Shankar over 2 years ago

  • Category set to Correctness/Safety
  • Assignee set to Jeff Layton
  • Target version set to v17.0.0
  • Backport set to pacific,octopus
Actions #6

Updated by Jeff Layton over 2 years ago

I have patches for the userland client that mimic what the kernel does, but building ceph under f35 is currently broken. Once that gets resolved, I'll be able to test this. Note that FUSE always reports the fsid as 0, regardless of what the driver puts in f_fsid, so testing this will require a custom program or maybe cephfs-shell.

Actions #7

Updated by Jeff Layton almost 2 years ago

  • Status changed from New to Resolved
Actions

Also available in: Atom PDF