What I am arguing is that if you are going to use time, use it in a way
that plays well with a distributed system.
That is where leases come from. What you are suggesting is very similar to
the original design, that says keep track of allocated
blocks (the original design doc that was shared) and
Hi Steven,
Thank you for the comments, my earlier comment was very brief, and I did
not explain things in sufficient detail.
Your comments made me realize that, and I have taken the opportunity to
clarify what I was thinking. Hopefully, it is much clearer now.
1. The Lease is a simple lock wi
I am not sure I understand every bits of the discussion, but let me add
some thought as well here.
Waiting on clients to finish writes, and see if the container is full
after, sounds like a horrible idea, as with that we will decrease the
amount of writes that can be done parallelly and make it to
I would recommend a proof of concept on your cluster, doing the simplest
thing first, which is holding the close commands in SCM for a configurable
delay, and see if you can alleviate the problem that way.
Adding a lease will be quite complex, and may not be needed if the simple
delay works. You w
Thanks Anu and Steven for the suggestion. Granting a lease to client
sounds like a more controllable way.
However, if I understand correctly, clients don't talk to SCM directly.
Does it mean OM has to relay the renew lease request to SCM?
Is there a better way to implement it?
Regards
Kaijie
--
