I have not looked at the new replication code in much details yet.
Technically it's possible for either MDS ot the client to ask for lock revocation.
(btw in the picture it's a bit strange how there are two INTENT_WRITE replies,
probably should only be one, second).
In case of replication it's not necessary to flush primary replica locks because the
content does not really change, I imagine (as opposed to a restriping where all objects
are moved).
It also might be implying that the client holds the primary replica lock too, I guess with
all the updates it is doing there and the diagram does not really show what
happens with non-primary replicas (where the locks would nened to be revoked I guess in
order for all caches to stay consistent).
Please keep in mind this is the first baby steps in this direction and since getting
distributed updates is not all that easy, the initial implementation
would just declare all replicas but the primary one invalid as long as there are writers
and then would resync them at a later point in time (e.g. after all
file open handles with write bit set have been gone for some time) an then reenable so
that subsequent readers could use many of them again.
(primary replica could be dynamically chosen amongst all present replicas, they are
identical after all).
On Apr 7, 2015, at 11:09 PM, Akhilesh Gadde wrote:
Hi Oleg,
Thanks a lot for the detailed explanation. Things look much clearer to me now.
A few questions that still linger in my mind. Sorry for asking too many questions.
1. Since the interaction between the OSS and client is through the OSC in the client, I
suppose it would also take care of the data locking mechanism. (locked from the OSS). I
hope my understanding is correct here.
2. "For all stripes that would need to change, revoke OST data locks -> this
causes all clients having caches for these objects to flush those caches."
--> Here you mentioned that in case of restriping, the OST data locks would be
revoked. Here would the MDS/MST contact the OSS/OST asking those locks to be revoked or
the client would contact OSS/OSTs. I am trying to understand the below diagram showing the
restriping steps. (Specifically the "Update L.Gen" message from the client to
the primary replica).
Regards,
Akhilesh Gadde.