> On 8 Sep 2017, at 16:33, Luis Henriques <lhenriques@xxxxxxxx> wrote: > > "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? yes > >> 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. I will start to hammer this code soon, please wait a few days. Regards Yan, Zheng > > 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
