"Yan, Zheng" <zyan@xxxxxxxxxx> writes: >> On 6 Sep 2017, at 22:12, Luis Henriques <lhenriques@xxxxxxxx> wrote: <snip> > This bottom-up dentry traversal code worries me. I vaguely remember that bottom-up > dentry traversal in kernel is discouraged. Then there are multiples clients modifying > the filesystem at the same time, the rename_lock does not help. That's why user space > code Client::get_quota_root() checks dentry lease and does lookup parent. I’m not sure > if we can do the same operations in kernel, because locking is much more complex in > kernel. So, you're saying that in addition to using the rename_lock (for local renames), that loop will also need to do something similar to what's being done already in function ceph_d_revalidate. I.e., it needs to validate the lease (as in function dentry_lease_is_valid) and send a CEPH_MDS_OP_LOOKUP if a dentry is invalid. Or am I missing something? > For the long term, I prefer unifying quota and snapshot implementation. The inode > trace in MClientReply contains information about which quota realm the inode belongs > to. So client can find quota information easily. (This requires bigger change for both > mds and client) My motivation for trying to bring the kernel client a bit closer to the fuse client was that there are currently valid use-cases for this quota implementation, with all its limitations. Now, I completely agree that ideally the core quota implementation should be moved to the MDS. This would simplify the clients side, and, above all, would remove the limitation of requiring clients cooperation. Obviously, I would be more than happy to help on the kernel client side of this solution. But I'm afraid that the real hard work would be on the MDS code, where things such as multi-MDS and dir fragmentation would make this solution quite complex. Cheers, -- Luís -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
