From owner-freebsd-hackers@freebsd.org Wed Dec 23 17:58:03 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0010A508E9 for ; Wed, 23 Dec 2015 17:58:03 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B00C110EC for ; Wed, 23 Dec 2015 17:58:03 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: by mailman.ysv.freebsd.org (Postfix) id AC5D4A508E7; Wed, 23 Dec 2015 17:58:03 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ABF30A508E6 for ; Wed, 23 Dec 2015 17:58:03 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 42D2010EA for ; Wed, 23 Dec 2015 17:58:02 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [194.32.164.24] ([194.32.164.24]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id tBNHrdJi061248; Wed, 23 Dec 2015 17:53:39 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: The minimum amount of memory needed to use ZFS. From: Bob Bishop In-Reply-To: <20151223121445.GA85016@ozzmosis.com> Date: Wed, 23 Dec 2015 17:53:41 +0000 Cc: Stephen Hocking , hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <26557C02-C591-4232-BBD0-988B0EB89575@gid.co.uk> References: <20151223121445.GA85016@ozzmosis.com> To: andrew clarke X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 17:58:03 -0000 Hi, > On 23 Dec 2015, at 12:14, andrew clarke wrote: >=20 > On Wed 2015-12-23 21:43:37 UTC+1100, Stephen Hocking = (stephen.hocking@gmail.com) wrote: >=20 >> Inspired by this article: >> = http://arstechnica.com/information-technology/2015/12/rsync-net-zfs-replic= ation-to-the-cloud-is-finally-here-and-its-fast/ >>=20 >> I am wondering about changing my offsite back strategy, which = currently is >> made up of a Raspberry Pi with an external 3TB drive sitting at my >> brother's house, with periodic manual rsyncs. I'd like to change that = to >> doing zfs replications. >>=20 >> I want to use some of my ARM based hardware as the target for the ZFS >> replication, owing to its low power usage. I have a few Cubiboxes = floating >> around with around 2G of RAM, and a RPI2 or a Banana Pi with 1G. It'd = have >> a UFS root on the SD card, and ZFS on the external drive. >>=20 >> Any ideas? >=20 > I'm curious about this too. >=20 > Currently I run a root-on-ZFS FreeBSD 10.2 amd64 system with 2 GB RAM > that I use for offline backups. The ZFS pool consists of 2 x 1 TB > drives in a mirror setup. I've never had FreeBSD run out of memory on > that machine. >=20 > I suggest you avoid using the deduplication feature of ZFS which from > what I understands likes to chew through memory. >=20 > I don't use ZFS snapshots on that machine, so can't speak about their > memory usage. Perhaps it's fairly insignificant, though. >=20 > An alternative might be to use something like rsnapshot, still on ZFS. >=20 > You might get a bigger audience if you ask on the freebsd-questions > list. >=20 > Regards > Andrew FWIW we have a backup box currently running 9.2 amd64 with 4GB RAM and a = ZFS mirror. We use rsync to transfer the data daily, and ZFS snapshots = to maintain a Time Machine-like structure (currently something over 150 = snapshots in play). We did have some instances of apparent memory = exhaustion until we limited vfs.zfs.arc_max to 2GB; that doesn=E2=80=99t = seem to have affected performance. Deduplication seems like a very bad idea unless you have both a lot of = duplicated data and a serious shortage of disk. It needs a lot of RAM, = increasing over time. Depending on the hardware and the use case, = compression (which effectively only costs CPU) might be a better option. -- Bob Bishop rb@gid.co.uk