Date: Fri, 04 Oct 2019 19:56:12 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Ian Lepore <ian@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: ZFS with 32-bit, non-x86 kernel Message-ID: <63664.1570218972@critter.freebsd.dk> In-Reply-To: <b7c2b26488c0238f4e77657b5fce0d798ba13ebd.camel@freebsd.org> References: <bdfecbf4-00c6-e104-4090-c1013bac5a7f@FreeBSD.org> <2264fde0-d386-518f-2bdb-2b86afe1faf3@blastwave.org> <CANCZdfqyof2_DmbW3G3S2q2ZsFo8_zr2YUzO0SrFo1eg-HhiJw@mail.gmail.com> <b7c2b26488c0238f4e77657b5fce0d798ba13ebd.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-------- In message <b7c2b26488c0238f4e77657b5fce0d798ba13ebd.camel@freebsd.org>, I= an Le pore writes: >There have also been some bug reports as recently as 2017 indicating >that people are still doing this on small armv7 systems. I actually have a potential off-site backup server in my lab right now, consisting of a BeagleBoneBlack and two USB disks, seems to work. The basic scheme is a cronjob which: zfs import inl run various rsyncs zfs snapshot -r inl@$YYMMDDHHMM zfs export inl The import/export is so the USB disks spin down. Not sure if ZFS will croak the 512M RAM on other workloads, but for this one it seems to work fine so far. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= .
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?63664.1570218972>