[Lustre-devel] Reducing amount of glimpses
Oleg Drokin
Oleg.Drokin at Sun.COM
Fri Feb 1 23:00:24 PST 2008
Hello!
On Feb 2, 2008, at 1:39 AM, Eric Barton wrote:
> Reduction (as you describe) is an absolutely essential strategy
> to achieve scalability. So without having checked through all the
> details of your idea, it feels like absolutely the right solution.
Yes, I just afraid that a bit stale size data might be reported, and
not yet
sure how critical is that to us.
> If your idea not only changes latencies but also significant
> orderings,
> I'll feel less secure. Have you thought it all through?
There is no ordering changes other than I would think perfectly normal
race.
Let me explain with a control flow:
client3 holds highest write lock. clients 1 and 2 do glimpse.
Right now (racy scenario):
client 1 sends glimpse->server on its behalf sends glimpse ast to
client3 -> client3 receives ast, sends reply
client 2 sends glimpse->server on its behalf sends glimpse ast to
client3 ->
client3 writes some more data
glimpse on behalf of client2 arrives to client3 -> client3 sends in
updated size
server now sends different sizes back to client 1 and client2.
If we consolidate, it will look like this:
client 1 sends glimpse->server on its behalf sends glimpse ast to
client3 -> client3 receives ast, sends reply
client 2 sends glimpse->server notices there is glimpse ast in flight
already to client3, and waits for it
client3 writes some more data
server receives reply and sends identical sizes to client1 and client2.
I tend to think this is normal race (kind of like with 2 processes
doing stat on a local file and 3rd writing to file constantly,
it is possible that when two stats are done closely apart, they would
come with identical size), but just want to check if
there are no objections about it.
Bye,
Oleg
More information about the lustre-devel
mailing list