Bug #22801
closed
client: Client::flush_snaps still uses obsolete Client::user_id/group_id
Added by Patrick Donnelly over 6 years ago.
Updated about 6 years ago.
Description
This appears to be a hold-out from the UserPerm work last year and the last remaining user of Client::user_id|user_gid (with the exception of SyntheticClient).
- Blocks Bug #22802: libcephfs: allow setting default perms added
- Subject changed from client: Client::flush_snaps still uses obsolete user_id/user_gid to client: Client::flush_snaps still uses obsolete Client::user_id/group_gid
- Subject changed from client: Client::flush_snaps still uses obsolete Client::user_id/group_gid to client: Client::flush_snaps still uses obsolete Client::user_id/group_id
I don't have the best grasp of how snapshots work in cephfs, so I'm a little confused as to what should be done here:
flush_snaps is called from all sorts of async contexts, so we can't rely on the thread context to get credentials. send_cap sets those values to in->cap_dirtier_uid/gid. Should we do the same here?
I think we should cap_dirtier_uid/gid into CapSnap
Hmm...cap_dirtier_uid is only set to anything non-default in _do_setattr(). That function does this very early:
if (in->snapid != CEPH_NOSNAP) {
return -EROFS;
}
So it looks like it'd only ever be set to -1 on a snapshot? If so, then maybe we should just have this flush_snaps set these values to -1?
CapSnap is for flushing snapshoted metadata (the metadata that were dirty at the time of mksnap), nothing do with setatrr on snap inode
- Status changed from New to Resolved
Also available in: Atom
PDF