From owner-freebsd-geom@FreeBSD.ORG Sun May 6 09:26:33 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA73C16A400 for ; Sun, 6 May 2007 09:26:33 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 18DB713C44B for ; Sun, 6 May 2007 09:26:32 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (8.13.8/8.13.8) with ESMTP id l469H69F023571 for ; Sun, 6 May 2007 18:47:06 +0930 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.5) with ESMTP id for ; Sun, 6 May 2007 18:56:24 +0930 Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 May 2007 18:56:23 +0930 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.13.8/8.13.8) with ESMTP id l469QBsp034574 for ; Sun, 6 May 2007 17:26:11 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.13.8/8.13.8/Submit) id l469QAtY034573 for freebsd-geom@freebsd.org; Sun, 6 May 2007 17:26:10 +0800 (WST) (envelope-from wilkinsa) Date: Sun, 6 May 2007 17:26:10 +0800 From: "Wilkinson, Alex" To: freebsd-geom@freebsd.org Message-ID: <20070506092610.GB34390@obelix.dsto.defence.gov.au> Mail-Followup-To: freebsd-geom@freebsd.org References: <171980743.20070504223126@uzvik.kiev.ua> <125507.38194.qm@web30304.mail.mud.yahoo.com> <86fy6bqocr.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <86fy6bqocr.fsf@dwp.des.no> User-Agent: Mutt/1.5.14 (2007-02-12) X-OriginalArrivalTime: 06 May 2007 09:26:24.0052 (UTC) FILETIME=[9D658F40:01C78FC0] X-TM-AS-Product-Ver: SMEX-7.0.0.1526-3.6.1039-15156.001 X-TM-AS-Result: No-6.786900-8.000000-31 Content-Transfer-Encoding: 7bit Subject: Re: graid5 after-reboot problem X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2007 09:26:33 -0000 0n Sat, May 05, 2007 at 05:31:00PM +0200, Dag-Erling Smrgrav wrote: >Ivan Voras writes: >> Is the write cache in graid5 aware of what happens on the VFS / UFS >> layers (something like gjournal does)? Otherwise, how can you guarantee >> consistency with write caching at the GEOM layer when there's a power >> outage or some other system interruption? > >You can't. Google for "RAID 5 write hole" for an explanation. > >The way this is handled by hardware RAID 5 controllers is that they >keep a journal in the controller's memory (which has its own battery >backup) and replay it when the power returns. If the controller is >fried, you're SOL. > >ZFS uses copy-on-write, so its raidz and raidz2 do not have a "write >hole". "ZFS uses its end-to-end checksums to detect and correct silent data corruption. If a disk returns bad data transiently, ZFS will detect it and retry the read. If the disk is part of a mirror or RAID-Z group, ZFS will both detect and correct the error: it will use the checksum to determine which copy is correct, provide good data to the application, and repair the damaged copy." A good read about this exact issue by sun kernel-fs wizard Jeff Bonwick: [http://blogs.sun.com/bonwick/entry/zfs_end_to_end_data] -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email.