[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