From owner-freebsd-fs@FreeBSD.ORG Fri Feb 10 10:19:31 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A066106564A for ; Fri, 10 Feb 2012 10:19:31 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id B3A688FC14 for ; Fri, 10 Feb 2012 10:19:30 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0LnShi-1SS6zH34RS-00gxgJ; Fri, 10 Feb 2012 11:19:29 +0100 Message-ID: <4F34EF30.1030706@brockmann-consult.de> Date: Fri, 10 Feb 2012 11:19:28 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4F33CA4D.6060400@brockmann-consult.de> <4F33E952.80102@brockmann-consult.de> In-Reply-To: <4F33E952.80102@brockmann-consult.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:S1CoNA657bsX0vJiE80q9BUsNlMv2i7qwDQMsPZgujT RqZeIIhtG8LMy3cVnwZCrTcochMmtw/oRt/fIW7KekGOu4CRLW Eqgs/xrAxwgpjjwETIwDyajct6TL1fli/JMcaVyYLWOQ8mKyOz bIjVzW6Pot5Xa/YkZFM7AktWmmEdIjA6REG3+nDeKCuI93xwr4 Rd6VucfQfnNHxH3IiFEnKmnRmuJna5OgBsUxUSZIjUR7X7ga7a UCcmghqIKTYDSCyZkLUXHOP3Mu1GMGkynK7hkIkk0bI+P18ruE 6+JxAJylTlN408FsqfwxBZtwJ2ReARwcquiDHG5CLRPF5cnzUZ 1VaujUksVqO99sFBUg0DyWeC80XbGS3Z46iOx8+Qz Subject: Re: zfs snapdir NFS hang X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 10:19:31 -0000 On 02/09/2012 04:42 PM, Peter Maloney wrote: > ... > And for the record, I have tested full scans of the .zfs/snapshot > directory using "find" to see if it "brings the server to its knees" as > is often said, but even that does not cause any problems at all (with 48 > GB of memory on this machine). I am currently running another run of > that test, and will tell you the result in 20 or so hours when it is done. > > # time find /tank/bcnasvm1/.zfs/snapshot -type f > /dev/null 2>&1 The result was that the system seemed fine, for a while, but after fiddling with NFS and snapshots, eventually every new process (eg. a local login on the machine terminals) would be killed with a message about being out of swap space. I guess it can only eat all your memory when you have more data or snapshots, because fun stuff like this didn't happen before. Or perhaps I didn't catch it before, because I didn't try fiddling with other things the last time I tested it.