Hi
a) documentation says "All operations that do not modify the file
or directory are sent to all the subvolumes and the first successful
reply is returned to the application", why is blocking then ?
it's suposed that the reply from the non blocked server will
come first and nothing will block, but clients are blocking on
a simple ls operation
My impression is that you have to imagine the setup as serialized queue on the
server. If there was one operation with a hang, all future ones will be
hanging, too.
if it says that it will take the first answer to come then the
only way is that the client does not block in any request, it
will have very little sense to do that. The only thing i can imagine
is that it blocked when trying to write the last access time of some
folder
My idea of a solution would be to implement something like a bail-out timeout
configurable on the client vol file for every brick. This would allow to
intermix slow and fast servers and it would cope with a situation where some
clients are far away with a slow connnections and others are nearby with very
fast connection to the same servers.
completly agree
The biggest problem about it probably is not to bail out servers, but to
re-integrate them. Currently there seems to be no userspace tool to tell a
client to re-integrate a formerly dead server. Obviously this should not
happen auto-magically to prevent flapping.
in our case, rebooting the hanged server make all clients runs again
without any notable bad effect, the ones that were reading from the
blocked volume continued reading as if nothing has happened, in this
aspect everything run ok.
--
Best regards ...
----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. telf +34 902 50 29 75
----------------------------------------------------------------
_______________________________________________
Gluster-users mailing list
[email protected]
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
