On Mon, Mar 11, 2019 at 2:11 PM Jeff Layton <jlayton@xxxxxxxxxxxxxxx> wrote: > > This may, on its face, sound like a stupid question, but I'm going over > the rules to ensure that our cap handling rules will be able to properly > support buffered creates/unlinks. It's not stupid. I had trouble with these too; they don't show up in many places; and I've forgotten them again. > > Dentry leases seem to be really poorly documented. The "rules" for them > are unclear, but also the rationale. What was the supposed benefit of > the dentry leases in ceph over just relying on appropriate caps on the > parent directory? > > In principle I suppose it would allow you to continue caching most of > your dentries when only some small subset changes. Was that it or was > there some other reason to add them? Yeah. I *think* it's that leases allow us to satisfy an "ls" (but not an "ls -l" or anything requiring any details!) — and skimming through the client code maybe also to map from dentries to inode numbers? But that should be governed by Ls — quickly and cheaply without requiring any caps that hold up other operations. The caps on the parent directory are pretty expensive in comparison, right? Holding shared caps requires notification on any timestamp updates; holding exclusive caps requires that whole revoke dance before anybody else can do something; with leases you only need to get notified on actual directory content changes and we don't have a good mapping for that in the cap system. If that sounds like a weird optimization that doesn't do much good (I actually think it might?), keep in mind that there are some silly behaviors in the HPC world that CephFS was originally targeted at. Or maybe I'm misremembering this and Sage or Zheng will respond quickly to my terrible, terrible lies. ;) -Greg > > If that was the reason, what was the rationale for making them time- > based (they all have a lease_ttl)? > -- > Jeff Layton <jlayton@xxxxxxxxxxxxxxx> >
