Date: Sun, 6 May 2007 17:26:10 +0800 From: "Wilkinson, Alex" <alex.wilkinson@dsto.defence.gov.au> To: freebsd-geom@freebsd.org Subject: Re: graid5 after-reboot problem Message-ID: <20070506092610.GB34390@obelix.dsto.defence.gov.au> In-Reply-To: <86fy6bqocr.fsf@dwp.des.no> References: <171980743.20070504223126@uzvik.kiev.ua> <125507.38194.qm@web30304.mail.mud.yahoo.com> <f1i3s4$j4n$1@sea.gmane.org> <86fy6bqocr.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
0n Sat, May 05, 2007 at 05:31:00PM +0200, Dag-Erling Smrgrav wrote:
>Ivan Voras <ivoras@fer.hr> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070506092610.GB34390>