Questions about ceph/cephfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey Jeff,
Hey everyone,

I have a question about the relationship between the cephfs kernel
client/filesystem and the code in [1].

I'm working on patches to let cephfs support mapped mounts. I've got
everything in place and I'm able to run the full mapped mounts/vfs
testsuite against a ceph cluster. So things like:

mount -t ceph 1.2.3.4:6789:/ /mnt -o name=admin,secret=wootwoot
mount-idmapped --map-mount b:1000:0:1 /mnt /opt

(Where in /opt all inodes owned by id 1000 are owned by id 0 and callers
with id 0 write files to disk as id 1000.)

My next step was to read to the ceph code in github.com/ceph/ceph to
make sure that I don't miss any corner cases that wouldn't work
correctly with mapped mounts after the relevant kernel changes.

So I read through [1] and I could use some guidance if possible. The
code in there to me reads like it is a full implementation of cephfs in
userspace and I'm wondering how this related to the cephfs kernel
client/filesystem.

The client code in [1] seems to implement full-blown userspace path
lookup and permission checking that seems to reimplement the vfs layer
in userspace.
A lot of the helpers such as ceph_ll_mknod() in addition expose a
UserPerms struct that seems to be settable by the caller which is used
during lookup.

How does this permission/path lookup code relate to the cephfs kernel
client/filesystem? Do they interact with each other in any way?

Thanks for taking the time to answer!
Christian

[1]: https://github.com/ceph/ceph/tree/master/src/client/*



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Ceph Dev]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux