Date: Thu, 26 Jul 2007 07:59:23 +0100 (BST) From: "Mark Powell" <M.S.Powell@salford.ac.uk> To: Doug Rabson <dfr@rabson.org> Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>, Mark Powell <M.S.Powell@salford.ac.uk> Subject: Re: ZfS & GEOM with many odd drive sizes Message-ID: <20070726075607.W68220@rust.salford.ac.uk> In-Reply-To: <1185389856.3698.11.camel@herring.rabson.org> References: <20070725174715.9F47E5B3B@mail.bitblocks.com> <1185389856.3698.11.camel@herring.rabson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 25 Jul 2007, Doug Rabson wrote: > On Wed, 2007-07-25 at 10:47 -0700, Bakul Shah wrote: >> Does it really do this? As I understood it, only one of the >> disks in a mirror will be read for a given block. If the >> checksum fails, the same block from the other disk is read >> and checksummed. If all the disks in a mirror are read for >> every block, ZFS read performance would get somewhat worse >> instead of linear scaling up with more disks in a mirror. In >> order to monitor data on both disks one would need to >> periodically run "zpool scrub", no? But that is not >> *continuous* monitoring of the two sides. > > This is of course correct. I should have said "continuously checks the > data which you are actually looking at on a regular basis". The > consistency check is via the block checksum (not comparing the date from > the two sides of the mirror). ACcording to this: http://www.opensolaris.org/jive/thread.jspa?threadID=23093&tstart=0 RAID-Z has to read every drive to be able to checksum a block. Isn't this the reason why RAID-Z random reads are so slow and also the reason the pre-fetcher exists to speed up sequential reads? Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information Services Division, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070726075607.W68220>