Ceph » CephFS

Serious question: does anyone actually use the SyntheticClient? It's only linked into the ceph-syn binary, and I don't see anything that calls that in our QA suite, at a quick glance.

Answering my own question: generate_ceph_corpus.sh uses it and it was added fairly recently. Still, I'm not sure that's worth the maintenance burden. We could replace that with a python script or something.

Jeff Layton wrote:

Serious question: does anyone actually use the SyntheticClient? It's only linked into the ceph-syn binary, and I don't see anything that calls that in our QA suite, at a quick glance.

Answering my own question: generate_ceph_corpus.sh uses it and it was added fairly recently. Still, I'm not sure that's worth the maintenance burden. We could replace that with a python script or something.

I think the SyntheticClient may be useful in the future for some artificial workload testing. I don't think we've done much with it recently because there hasn't been need for benchmarking CephFS (e.g. for academic conference papers).

In any case, the way SyntheticClient is using these options was only incidental. We can modify Client::pick_my_perms to just choose 0 (which is a reasonable default?).

The current default is to set it to -1, so that's probably what we'll do here.

Further down the rabbit hole, we have a bit of a problem. With removing client_mount_uid/gid, pick_my_perms is now a trivial "default_perms" function. That's fine so far, but we do have one testcase (AccessTest, User) that sets client_mount_uid/gid to some specific values before calling ceph_mount.

ceph_mount does this:

  return cmount->mount(mount_root, cmount->default_perms);

...and now cmount->default_perms is always uid=-1, gid=-1. What we need is a way to call ceph_mount and pass in a UserPerm structure.

Maybe a ceph_mount_with_perms() function?

Another idea would be to just change the ceph_init prototype to take a UserPerm object. Then we could just call ceph_init before ceph_mount with the right perms. That function is not commonly called by most consumers of libcephfs, but changing it would technically be an ABI break. In hindsight, we should have changed this when we revved the soname of the library recently. It's probably too late now.

Thoughts?

What I think I'm going to do is just add a ceph_mount_perms_set() function to the API that will reset it to a UserPerm that's passed in. You'll have to do it before ceph_mount to prevent races, as copying a UserPerm object is not atomic, AFAICT.

Part of the problem here is that there are really two sets of default permissions in this code. There is one in the Client, and one in struct ceph_mount_info. When ceph_mount_info is first ->init'ed it copies the default permissions from the Client.

Removing the default perms from Client is relatively easy and only really affects SyntheticClient, but removing it from ceph_mount_info is not really possible. Most of the high-level API for libcephfs relies on passing down these permissions, so we do need some way to set them.

The other complicating factor is that there is documentation and code in the field that uses these options. Should we try to keep those programs limping along for now? We could do something like add a warning to the logs for a year or so and do the final rip-out after a certain release?

Yes. I had started some patches to do that a while back. I'll plan to pick them back up sometime soon.

PR is up:

https://github.com/ceph/ceph/pull/20719