[Gluster-users] NFS client blocking reboot
Anand Avati
anand.avati at gmail.com
Sun Jul 28 16:12:45 UTC 2013
On Sun, Jul 28, 2013 at 8:58 AM, Marcus Bointon
<marcus at synchromedia.co.uk>wrote:
> On 28 Jul 2013, at 17:31, Anand Avati <anand.avati at gmail.com> wrote:
>
> Mounting NFS export from localhost is a recipe for disaster for many other
> reasons (including deadlocks under heavy IO).
>
>
> Docs? I'm only doing it because it's the only workable solution I've found
> for gluster at all.
> Gluster native client performance is too bad, and pointing it non-local
> servers implies anti-redundancy (someone else mentioned the same problem
> for the same reason on here just recently) and is worse than not using
> gluster at all.
> If you have a better solution, I'm all ears.
>
>
What is your typical workload, and what kind of tests did you compare
native client perf against NFS perf?
Avati
> it stops gluster before unmounting volumes. This causes the NFS client to
> hang waiting for a response from the gluster server (which will never
> happen because it's stopped), blocking the reboot, leaving the server
> hanging indefinitely. The only way out seems to be to power-cycle the
> server.
>
>>
>> How is this supposed to work? Is there some way of scheduling unmounts
>> before killing gluster?
>>
>
> Not sure about this - should the init.d shutdown script be de-prioritized
> for your runlevel? But then, we are talking about a use case which is
> highly non-recommended.
>
>
> I've not experimented with init scripts yet, but I think the unmounts are
> done by /etc/init.d/umountfs.
>
> Marcus
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130728/8985c257/attachment.html>
More information about the Gluster-users
mailing list