From owner-freebsd-fs@FreeBSD.ORG Tue Jan 24 14:59:10 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 03CFC106566B for ; Tue, 24 Jan 2012 14:59:10 +0000 (UTC) (envelope-from claudius@ambtec.de) Received: from server.ambtec.de (server.ambtec.de [IPv6:2a01:4f8:131:1381::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8EDD18FC18 for ; Tue, 24 Jan 2012 14:59:09 +0000 (UTC) Received: from server.ambtec.de (localhost [127.0.0.1]) by server.ambtec.de (Postfix) with ESMTP id 0BC92E313 for ; Tue, 24 Jan 2012 15:59:08 +0100 (CET) X-Virus-Scanned: by amavisd-new using ClamAV at ambtec.de Received: from server.ambtec.de ([127.0.0.1]) by server.ambtec.de (server.ambtec.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5bSc2RbqJIbZ for ; Tue, 24 Jan 2012 15:58:51 +0100 (CET) Received: from [192.168.0.101] (e176013248.adsl.alicedsl.de [85.176.13.248]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.ambtec.de (Postfix) with ESMTPSA id 2F467E309 for ; Tue, 24 Jan 2012 15:58:51 +0100 (CET) Message-ID: <4F1EC72B.7000405@ambtec.de> Date: Tue, 24 Jan 2012 15:58:51 +0100 From: Claudius Herder User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120114 Thunderbird/9.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4F1A1564.4080003@ambtec.de> <4F1DC716.6050202@brockmann-consult.de> In-Reply-To: <4F1DC716.6050202@brockmann-consult.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: zfs arc eating up all memory 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: Tue, 24 Jan 2012 14:59:10 -0000 On 23/01/12 21:46, Peter Maloney wrote: > Dunno, but I make it a policy to always hide it. You can still type in > the .zfs directory and it uses it even if hidden. > > Try it. > > zfs set snapdir=hidden mypool/home/claudius > cd ~claudius/.zfs/snapshot > ls > yes I know and I think it is a really nice feature for users to be able to restore files by themselves. > The reason I decided to do that, is because I found that when an NFS > client does an ls inside the .zfs/snapshot directory, it hangs the server ;) at my server `ls .zfs/snapshot/` works, but `ls -R .zfs/snapshot/` kills the server. Same for `find .zfs/snapshot -name foo`. > But the client can still do the same, just manually typing the > directory... so I also mounted /var/empty on top of it to hide it on the > client. (and my users use the client system through samba, not the zfs > system with NFS) I'm not very fond of this idea, but for the moment it will prevent server crashes, which is fine. Thanks for the hint. I did some further testing: My i368 vm is able to search 100 snapshots with 8601040 files without problems with 1gb ram und 1 gb swap. My amd64 server is not able to search 4280597 files with 8gb ram and 4gb swap. At the last halt arc consumed only 5,5gb memory and as I understand arc would not steal memory from other processes, is this assumption correct? Maybe this problem is totally unrelated to arc and there is something else claiming all memory? How can I investigate this issue further? -- Claudius