Client1 it has to interact with Client2. The OST sends an
LDLM_BL_CALLBACK request to Client2 asking Client 2 to finish up with
the lock it has. Client2 replies with a simple acknowledgment. When
-Client2 is no longer using the lock it will send an LDLM_CANEL RPC to
+Client2 is no longer using the lock it will send an LDLM_CANCEL RPC to
the OST. At that point the OST grants the original request sending an
LDLM_CP_CALLBACK request to Client1 to notify it. With that taken care
of Client1 is finally able to issue the OST_PUNCH request that
Its effect is to notify the OST that the lock has been returned.
-*6 - The OST replies acknowleging the lock request.*
+*6 - The OST replies acknowledging the lock request.*
The ldlm_reply's lock descriptor acknowledges the request for an
extent write lock without granting it ('l_req_mode' == LCK_PW,
*11 - The OST acknowledges the LDLM_CANCEL (step 7) from Client2*
The OST finishes up with the lock cancel (after having notified
-Client1) by replying to Clietn2. This happens asynchronously with the
+Client1) by replying to Client2. This happens asynchronously with the
arrival of the OST_PUNCH request, and in <<truncate-rpcs>> it is shown
-occuring after the OST_PUNCH, but that is not required.
+occurring after the OST_PUNCH, but that is not required.
.LDLM_CANCEL Reply Packet Structure
image::ldlm-cancel-reply.png["LDLM_CANCEL Reply Packet Structure",height=50]
//////////////////////////////////////////////////////////////////////
The LDLM_CANCEL reply is a so-called "empty" RPC. Its only purpose is
-to acknowldge receipt of the LDLM_CANCEL request.
+to acknowledge receipt of the LDLM_CANCEL request.
*12 - The OST an OST_PUNCH reply.*