[Lustre-devel] Sub Tree lock ideas.

Nikita Danilov Nikita.Danilov at Sun.COM
Tue Feb 3 07:01:58 PST 2009

Oleg Drokin writes:
 > Hello!
 >     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 mailing list