From owner-freebsd-current@FreeBSD.ORG Wed Jul 9 11:43:17 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33FAA1065683 for ; Wed, 9 Jul 2008 11:43:17 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6B3B88FC14; Wed, 9 Jul 2008 11:43:16 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4874A453.7060406@FreeBSD.org> Date: Wed, 09 Jul 2008 13:43:15 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Dmitry Morozovsky References: <20080708100701.57031cda@twoflower.in.publishing.hu> <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> In-Reply-To: <20080709152739.Q58331@woozle.rinet.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: Thinking of using ZFS/FBSD for a backup system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2008 11:43:17 -0000 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 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