Date: Mon, 22 Jun 2009 01:22:02 +0000 From: Nathanael Hoyle <nhoyle@hoyletech.com> To: Dan Naumov <dan.naumov@gmail.com> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: ufs2 / softupdates / ZFS / disk write cache Message-ID: <4A3EDCBA.7010204@hoyletech.com> In-Reply-To: <cf9b1ee00906211557l72aec9d9rab7561d12cf11b81@mail.gmail.com> References: <570433.20373.qm@web37308.mail.mud.yahoo.com> <cf9b1ee00906211557l72aec9d9rab7561d12cf11b81@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Naumov wrote: > 2009/6/21 Šimun Mikecin <numisemis@yahoo.com> > > >> 21. lip. 2009., u 13:41, Andrew Snow <andrew@modulus.org> napisao: >> >>> Folks who need to maximize safety and can't afford the performance >>> hit of no write cache need to do what they always have had to do in >>> the past - buy a controller card with battery-backed cached. >>> >> Or: >> B) use SCSI instead of ATA disks >> C) use UFS+gjournal instead of UFS+SU >> D) use ZFS instead of UFS+SU >> > > > Actually I think a need a few clarifications regarding ZFS: > > 1) Does FreeBSD honor the "flush the cache to disk now" commands issued by > ZFS to the harrdive only when ZFS is used directly on top of a disk device > directly or does this also work when ZFS is used on top of a > slice/partition? > 2) If we compare ZFS vs UFS+SU while using a regular "lying" SATA disk (with > write cache enabled) under heavy IO followed by a power loss. Which one is > going to recover better and why? > > > Sincerely, > - Dan Naumov > ZFS should recover better I believe. It's copy-on-write semantics mean that you always have a valid, intact (even if not the most recent) copy of the data. I believe with soft updates it is still possible to have partially written metadata updates cause problems. I'm not as much of an expert on soft updates semantics however, so I'll defer to those who are to correct me if I'm off-base. -Nathanael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A3EDCBA.7010204>