From owner-freebsd-fs@FreeBSD.ORG Fri May 20 00:11:12 2011 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 A94D11065673; Fri, 20 May 2011 00:11:12 +0000 (UTC) (envelope-from pvz@itassistans.se) Received: from zcs1.itassistans.net (zcs1.itassistans.net [212.112.191.37]) by mx1.freebsd.org (Postfix) with ESMTP id 3535A8FC1A; Fri, 20 May 2011 00:11:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs1.itassistans.net (Postfix) with ESMTP id 2E5A2C01CE; Fri, 20 May 2011 02:11:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at zcs1.itassistans.net Received: from zcs1.itassistans.net ([127.0.0.1]) by localhost (zcs1.itassistans.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j359LKl7CxRR; Fri, 20 May 2011 02:11:07 +0200 (CEST) Received: from [192.168.1.239] (c213-89-160-61.bredband.comhem.se [213.89.160.61]) by zcs1.itassistans.net (Postfix) with ESMTPSA id 445E6C0181; Fri, 20 May 2011 02:11:07 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) From: Per von Zweigbergk In-Reply-To: <5B27EAAB-5D23-4844-B7C7-F83289BCABE7@itassistans.se> Date: Fri, 20 May 2011 02:11:06 +0200 Message-Id: <61D2B7A3-1778-4A42-8983-8C325D2F849E@itassistans.se> References: <85EC77D3-116E-43B0-BFF1-AE1BD71B5CE9@itassistans.se> <20110519181436.GB2100@garage.freebsd.pl> <4DD5A1CF.70807@itassistans.se> <20110519230921.GF2100@garage.freebsd.pl> <5B27EAAB-5D23-4844-B7C7-F83289BCABE7@itassistans.se> To: Per von Zweigbergk X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek Subject: Re: HAST + ZFS self healing? Hot spares? 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, 20 May 2011 00:11:12 -0000 20 maj 2011 kl. 01.27 skrev Per von Zweigbergk: > You're describing taking the entire array offline while you perform = work on it. My apologies, I was a bit too quick reading what you (Freddie Cash) = wrote. What you're describing is relying on ZFS's own redundancy while you = replace the failed disk, bringing down the entire HAST resource just so = you can replace one of the two failed disks. The only reason the ZFS = array continues to function is because it's redundant in ZFS itself. Ideally, the HAST resource could continue to remain operational while = the failed disk was replaced. After all, it can remain operational while = the primary disk has failed, and it can remain operational while the = data is being resynchronized, so why would the resource need to be = brought down just to transition between these two states? I guess it's because HAST isn't quite "finished" yet feature-wise, and = that particular feature does not yet exist. Still, I suppose this is good enough, this just shows that raidz:ing = together a bunch of HAST mirrors solves one and a half of my operational = problems - replacing failed drives (by momentarily downing the whole = HAST resource while work is being done) and providing checksumming = capability (although not self-healing). The setup described (a bunch of HAST mirrors in a raidz) will not = self-heal entirely. Imagine if a bit error occurred while writing to one = of the secondary disks. Since that data is never read by ZFS or HAST, = the error would remain undetected. To ensure data integrity on both the = primary and secondary servers, you'd have to failover the servers once = every N days/weeks/months (depending on your operational requirements) = and perform a zfs scrub on "both sides" of the HAST resource, as part of = regular maintenance. It'd probably even be scriptable, assuming you can = live with a few seconds of scheduled downtime during the switchover.=