From owner-freebsd-stable@FreeBSD.ORG Thu Sep 3 03:19:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22E9A106566B for ; Thu, 3 Sep 2009 03:19:12 +0000 (UTC) (envelope-from emikulic@gmail.com) Received: from ipmail03.adl6.internode.on.net (ipmail03.adl6.internode.on.net [203.16.214.141]) by mx1.freebsd.org (Postfix) with ESMTP id A5BD88FC0A for ; Thu, 3 Sep 2009 03:19:11 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAL/SnkqWZZrw/2dsb2JhbACSAbgTkWuEGwWBVw X-IronPort-AV: E=Sophos;i="4.44,322,1249223400"; d="scan'208";a="29262153" Received: from ppp154-240.static.internode.on.net ([150.101.154.240]) by ipmail03.adl6.internode.on.net with ESMTP; 03 Sep 2009 12:49:09 +0930 Received: by ppp154-240.static.internode.on.net (Poo-fix, from userid 1001) id 5FCEF5C6E; Thu, 3 Sep 2009 13:19:08 +1000 (EST) Date: Thu, 3 Sep 2009 13:19:08 +1000 From: Emil Mikulic To: Mark Stapper Message-ID: <20090903031908.GA18410@dmr.ath.cx> References: <061541E3-F301-46C4-8ECB-5B05854F0EAA@exscape.org> <4A9D558A.9070609@quip.cz> <4A9E1CB5.6030906@mapper.nl> <20090902074445.GA13588@dmr.ath.cx> <4A9E2C7C.6030904@mapper.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A9E2C7C.6030904@mapper.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: zfs on gmirror slice X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 03:19:12 -0000 On Wed, Sep 02, 2009 at 10:27:40AM +0200, Mark Stapper wrote: > Emil Mikulic wrote: > > As Thomas Backman pointed out, this means you won't get self-healing. > > > self-healing sounds very nice, but with mirrorring you have data on two > discs, so in that case there no "healing" involved, it's just > checksumming and reading the non-corrupted copy. This won't work through gmirror because ZFS sees the mirror as a single disk. When it gets corrupt data, it has no way of signalling the gmirror layer to try reading the other disk(s) in the mirror. It's simply stuck with the corrupt data. Whereas with mirroring done by ZFS itself, it -can- try the other disks. And "self-healing" is where it writes the correct data back to the damaged disk on the fly. That's pretty cool. > From the gmirror manpage: "All operations like failure detection, stale > component detection, rebuild of stale components, etc. are also done > automatically." > This would indicate the same functionality, with a much less fancy name. Sorry, but no. ZFS can do some much fancier things if you let it manage the disks directly, e.g.: - it can detect disks returning bad data (because it has checksums) whereas gmirror's "failure detection" requires the disk to return errors or stop responding entirely - rebuild of stale components ("resilver") is proportional to the amount of data stored rather than the full capacity of the disks being used. i.e. ZFS won't rebuild the free space in the filesystem. > gmirror is fast though. I've even heard it's faster than software > RAID1/ataraid. (not confirmed). gmirror -is- software raid. ataraid is really broken based on my reading of these lists, I wouldn't trust my data to it. > Even if this is true, running zfs on top of gmirror probably isn't > faster then running zfs with a mirrored pool. Maybe you wouldn't see a speed difference, but there's a significant difference in features and reliability. --Emil