[Gluster-devel] Blocking client feature request

Geoff Kassel gkassel at users.sourceforge.net
Fri Jan 16 23:32:19 UTC 2009


Hi,
   There's been a lot of talk lately about NFS versus GlusterFS - particularly 
when it comes to having the client block whenever the server(s) go down. I'd 
like to put my vote in for a blocking GlusterFS client. Here's my 2 cents as 
to why I'd like this feature.

   I'd been using 1.3 TLA 636 GlusterFS on my production servers, and thanks 
to the extra bit of security (PaX) I use, I was experiencing somewhat more 
GlusterFS daemon crashes than I'd seen reported elsewhere. (Hence my attempts 
at QA efforts some months ago - PaX as anti-buffer overflow tool is very 
sensitive to any memory issues.)

   Whenever these crashes happen, I have to restart every process that depends 
in any way on GlusterFS mounts. Which is pretty much everything my servers 
run - Apache, Postfix, BIND, Courier, FTP daemon, etc. Apache in particular 
can take a long time to restart.

   I've automated around this, so that when it happens under heavy usage 
(about the only trigger I've ever found - there's nothing in the logs) I can 
recover unattended within about 5 to 10 minutes. But this is still a big 
reliability impact, and it's quite visible (deleteriously so) to my hosting 
clients.

   What I've realized is that a blocking GlusterFS client would solve this 
negative visibility problem for me while I look again at the crash issues. 
(I've just upgraded to the latest 1.4/2.0 TLA, so my experiences are relevant 
to the majority again. Yes, I'm still getting crashes.) 

   That way, I'd just have to restart the GlusterFS daemon(s), and my running 
services would block, but not have to be restarted. My clients would see a 
lack of responsiveness for up to 20 seconds, not a five to ten minute outage.

   Is there any possibility of this feature being added to GlusterFS?

Kind regards,

Geoff Kassel.





More information about the Gluster-devel mailing list