Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 09 Jul 2008 13:43:15 +0200
From:      Kris Kennaway <kris@FreeBSD.org>
To:        Dmitry Morozovsky <marck@rinet.ru>
Cc:        current@FreeBSD.org
Subject:   Re: Thinking of using ZFS/FBSD for a backup system
Message-ID:  <4874A453.7060406@FreeBSD.org>
In-Reply-To: <20080709152739.Q58331@woozle.rinet.ru>
References:  <bd9320b30807072315x105cf058tf9f952f0f5bb2a6a@mail.gmail.com> <20080708100701.57031cda@twoflower.in.publishing.hu> <bd9320b30807080131j5e0e02a4y3231d7bfa1738517@mail.gmail.com> <4873C4FA.2020004@FreeBSD.org> <20080709062533.J58331@woozle.rinet.ru> <48749087.4070802@FreeBSD.org> <20080709145010.Q58331@woozle.rinet.ru> <48749EA7.40702@FreeBSD.org> <20080709152739.Q58331@woozle.rinet.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
Dmitry Morozovsky wrote:
> On Wed, 9 Jul 2008, Kris Kennaway wrote:
> 
> KK> > marck@wizzle:/usr/ports> grep -Ril zfs Tools/
> KK> > Tools/portbuild/scripts/claim-chroot
> KK> > Tools/portbuild/scripts/clean-chroot
> KK> > Tools/portbuild/scripts/cleanup-chroots
> KK> > 
> KK> > ;-)
> KK> > 
> KK> > Any pitfalls while using this? Thanks!
> KK> 
> KK> It's still settling on pointyhat, but you could check it out there if you
> KK> like.  The most annoying thing is actually a limitation of the FreeBSD NFS
> KK> server, since it returns errors to clients while it is reloading the export
> KK> list.
> 
> Argh. And, which process is reporting an error? nfsd or some of kthreads? In 
> the former case, is it possible to create new master-slave process 
> tree, rebinding and signalling old tree to exit when all requests are finished?
> 
> The same approach is used by www/nginx to both seamless configuration change 
> and also binary file upgrade.
> 
> CC:ing -current@ to ensure the theme have a bit broader audience.

The problem is that updating the NFS export list is not atomic. 
Instead, it is deleted and reloaded.  This means that client I/O 
requests that are received during the window do not correspond to a 
valid export, and the server dutifully returns an error to the client.

This is made worse by the practice of mount(8) (and zfs(8)) of 
SIGHUP'ing mountd every time a new filesystem is mounted (even if it's 
not exported).  I have disabled this locally, but it doesn't help when I 
really do want to export a newly mounted filesystem but I have clients 
doing I/O.

A few years ago there was a patch from Andrey Simonenko 
<simon@comsys.ntu-kpi.kiev.ua> that implemented atomically reloading the 
mount list, although it was unfortunately a mixture of these and other 
changes including some that might be seen as gratuitous (e.g. it 
depended on a new library).  Unfortunately the patch no longer seems to 
be available on the original website and my attempt to contact Andrey 
has failed.

Kris



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4874A453.7060406>