2 <-------MDS_REINT
//////////////////////////////////////////////////////////////////////
-1 - Client1 issues an MDS_REINT with the REINT_SETATTR sub-operation.
+*1 - Client1 issues an MDS_REINT with the REINT_SETATTR sub-operation.*
In addition to the 'ptlrpc_body' (Lustre RPC descriptor), the MDS_REINT
request RPC from the client has the REINT structure 'mdt_rec_setattr', and a
identifies this lock. Only lock_count and lock_handle are used, and
the rest of the ldlm_request is cleared, i.e. all fields set to zero.
-2 - The MDS_REINT reply acknowledges the updated attributes.
+*2 - The MDS_REINT reply acknowledges the updated attributes.*
In addition to the 'ptlrpc_body' (Lustre RPC descriptor), the MDS_REINT
reply RPC to the client has the 'mdt_body' structure. For a detailed
//////////////////////////////////////////////////////////////////////
-1 - The client issues an MDS_REINT with the REINT_SETATTR sub-operation.
+*1 - The client issues an MDS_REINT with the REINT_SETATTR
+ sub-operation.*
The MDS_REINT request RPC closely resembles the one described above,
but in this case the 'setattr' wants to set the time attributes on the
There is again an early lock cancellation, since the client knows it
no longer need to have a lock on the MDT resource attributes.
-2 - The MDS_REINT reply acknowledges the updated times.
+*2 - The MDS_REINT reply acknowledges the updated times.*
The MDS_REINT reply is identical to the previous case in every way,
including which valid attributes it echoes back.
-3 - The client asks for a intent lock on the layout data for the
-resource.
+*3 - The client asks for a intent lock on the layout data for the
+resource.*
Before communicating with the OSTs the client needs to know which ones
are involved with this resource, and before it can ask for that
IT_LAYOUT. The 'layout_intent' has the 'li_opc' value 0:
LAYOUT_INTENT_ACCESS.
-4 - The MDS replies with a read lock on the layout.
+*4 - The MDS replies with a read lock on the layout.*
The LDLM_ENQUEUE reply that the MDS sends back grants the read lock on
the layout and provides a Lock Value Block (LVB) describing the
-----------------------------------------
//////////////////////////////////////////////////////////////////////
-5 - The client issues an OST_SETATTR with the updated times, which are
-maintained on the OST.
+*5 - The client issues an OST_SETATTR with the updated times, which
+are maintained on the OST.*
At last the client can send an update to the OST. The OST_SETATTR RPC
has an 'ost_body' structure.
| OBD_MD_FLFID |
|====
-6 - The OST acknowledges the update.
+*6 - The OST acknowledges the update.*
The reply RPC for the OST_SETATTR operation has the same form as the
request.
12 <--------------------OST_PUNCH
//////////////////////////////////////////////////////////////////////
-1 - The client issues an MDS_REINT with the REINT_SETATTR sub-operation.
+*1 - The client issues an MDS_REINT with the REINT_SETATTR
+sub-operation.*
The MDS_REINT request RPC closely resembles the one described above,
but in this case the 'setattr' wants to modify the size attribute on the
case it is empty (all fields set to zero), so no early lock
cancellation.
-2 - The MDS_REINT reply acknowledges the updated times.
+*2 - The MDS_REINT reply acknowledges the updated times.*
The MDS_REINT reply is identical to the previous cases in every way,
including which valid attributes it echoes back.
-3 - The client asks the OST for a write lock of type LDLM_EXTENT.
+*3 - The client asks the OST for a write lock of type LDLM_EXTENT.*
The 'ldlm_request' asks for a write lock with the lock descriptor
resource's type set to LDLM_EXTENT, the policy data covering the whole
the lock request is blank (zeroes). The RPC resembles the simplest
request form in <<ldlm-enqueue-rpc>>.
-4 - The OST contacts Client2 to ask for the return of the lock.
+*4 - The OST contacts Client2 to ask for the return of the lock.*
The LDLM_BL_CALLBACK is initiated by the OST and sent to the client,
identifying the resource in question. The content of the ldlm_request
------------------------------
//////////////////////////////////////////////////////////////////////
-5 - Client2 acknowledges the request and returns the lock.
+*5 - Client2 acknowledges the request and returns the lock.*
The LDLM_BL_CALLBACK is an "empty" RPC in that it only has the
LDLM_BL_CALLBACK opcode and no other content beyond the
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 acknowleging 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,
--------------------------------------
//////////////////////////////////////////////////////////////////////
-7 - Client2 cancels its lock
+*7 - Client2 cancels its lock*
Having received an LDLM_BL_CALLBACK Client2 must finish up with its
lock. Once it does it sends an LDLM_CANCEL request to the OST to
waiting on that lock, which it finds is Client1. It waits to reply to
Client2 with an LDLM_CANCEL reply until after it has notified Client1.
-8 - The OST notifies Client1 that it now has the lock.
+*8 - The OST notifies Client1 that it now has the lock.*
The 'ldlm_request' structure now has the granted mode set to protected
write. It also sends along any updated attributes as, for example, if
----------------------------------------
//////////////////////////////////////////////////////////////////////
-9 - Client1 acknowledges the lock update.
+*9 - Client1 acknowledges the lock update.*
The reply is "empty" in this case as well. The opcode in the
'ptlrpc_body' is sufficient to inform the OST that Client1 got its
---------------
//////////////////////////////////////////////////////////////////////
-10 - Client1 issues an OST_PUNCH request.
+*10 - Client1 issues an OST_PUNCH request.*
As with the OST_SETATTR RPC there is an 'ost_body' structure.
| OBD_MD_FLQOS | quality of service
|====
-11 - The OST acknowledges the LDLM_CANCEL (step 7) from Client2
+*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
The LDLM_CANCEL reply is a so-called "empty" RPC. Its only purpose is
to acknowldge receipt of the LDLM_CANCEL request.
-12 - The OST an OST_PUNCH reply.
+*12 - The OST an OST_PUNCH reply.*
The OST_PUNCH reply also resembles the OST_SETATTR reply:
git://git.whamcloud.com / doc / protocol.git / blobdiff