From owner-freebsd-fs@FreeBSD.ORG Fri May 18 16:56:39 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9154F106566C; Fri, 18 May 2012 16:56:39 +0000 (UTC) (envelope-from trent@snakebite.org) Received: from exchange.liveoffice.com (exchla3.liveoffice.com [64.70.67.188]) by mx1.freebsd.org (Postfix) with ESMTP id 6358B8FC12; Fri, 18 May 2012 16:56:39 +0000 (UTC) Received: from EXHUB03.exchhosting.com (192.168.11.104) by exhub05.exchhosting.com (192.168.11.101) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 18 May 2012 09:55:29 -0700 Received: from EXMBX10.exchhosting.com ([fe80::9c37:32f6:a508:a44f]) by EXHUB03.exchhosting.com ([fe80::ac41:fbe5:3959:ad64%12]) with mapi; Fri, 18 May 2012 09:55:26 -0700 From: Trent Nelson To: "araujo@FreeBSD.org" Date: Fri, 18 May 2012 09:55:24 -0700 Thread-Topic: Mirror of Raidz for data reliability Thread-Index: Ac01FwX48EsTh0EbQWykJg8N2G75Hg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-fs@freebsd.org" Subject: Re: Mirror of Raidz for data reliability 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, 18 May 2012 16:56:39 -0000 Hi Marcelo,=20 On 5/17/12 9:34 PM, "Marcelo Araujo" wrote: >2012/5/17 George Kontostanos > >> On Thu, May 17, 2012 at 1:52 PM, George Kontostanos >> wrote: >> >> >> Ok, after reading more carefully your first post I realized what you >> are trying to do. >> >> 2 Machines, 2 different controllers. Yet interconnected. So, in a way >> both machines would be able to see both controllers. >> >> 2) Both machines have to be online and the pool has to be mounted >> readonly on the standby! You don't want both of them to accidentally >> write at the same pool. >> >> >Not no.You can use Devd to start some scripts to mount the FS in another >machine or something like that. >But I can't be focused only in this scenario, I believe there are much >more >application for it. I'm in a similar situation with Snakebite. I have two boxes that can see a common set of disks (via FC SAN). I'm interested in failover, but like you, I don't want to use HAST -- why duplicate data when both machines can access the disks? I came across these articles yesterday, which are pretty neat: CARP and devd on FreeBSD: http://blather.michaelwlucas.com/archives/224 Automated CARP/HAST Failover: http://blather.michaelwlucas.com/archives/241 (Both of those posts reference lots of other articles; all of which I also found to be very good reads.) The author uses CARP/devd/HAST to automate failover and rebuild. Our situation is a little different because we don't want/need to use HAST. So, my thinking is=8A because both machines can see all disks, the master could import the zpool as normal, and the slave could import it read-only. (Or not import it at all...) Then, when CARP detects that the master has failed, some script will kick in on the slave (via devd?) and re-mount the zpools read-write. (Or import them for the first time.) That approach seems like a feasible starting point to me. It'll take a bit of fiddling of course, as FreeBSD isn't really set up to utilize ZFS like that. I'm planning on having my own /etc/rc.* type scripts that manually import/load zpools, rather than using /etc/rc.conf's zfs_enable=3D"YES" (which will definitely break things). Now the only thing that confuses me about your original e-mail is with regards to adding raidz vdevs. Can I enquire what you'll actually be doing with the zpools once they're loaded? I.e. You mentioned failover; what services will you be providing (NFS? Apache?) that you want to fail over? In my case, I'd *like* to be able to offer NFS, iSCSI and FC-target-mode in such a way that if the master dies, failover to the slave is automatic and transparent. At least, that's the ideal scenario :-) It'll sure take a bit of fiddling/hacking to get that working. Regards, Trent.