[Lustre-devel] Sub Tree lock ideas.
Nikita.Danilov at Sun.COM
Tue Feb 3 07:01:58 PST 2009
Oleg Drokin writes:
> We discussed a bit of this in Beijing last week, but decided to
> continue the discussion via email.
> So, I think it is a given we do not want to revoke a subtree lock
> every time somebody steps through it, because that will be too costly
> in a lot of cases.
> Anyway here is what I have in mind.
> STL locks could be granted by server regardless if they were
> requested by the client or not.
> We would require clients to provide a lock "cookie" with every
> operation they perform, in normal case that would be a handle they
> have on a parent directory.
> This cookie should allow a way to find out what server this cookie
> originates from (needed for CMD support).
> For the case of a different client stepping into area covered by
> STL lock, this client would get STL lock's cookie and will start
> present it for all subsequent
> operations (also a special flag meaning that the client is not
> operating within STL).
How is it determined that a given point in a namespace is covered by an
STL lock? E.g., client A holds an STL on /a, and client B accesses
/a/b/c/f (where /a/b/c is a working directory of some process on B)?
This looks especially problematic in the CMD case.
More information about the lustre-devel