Date: Fri, 12 Dec 2008 13:29:24 +0100 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-geom@freebsd.org Subject: Re: Encrypting raid5 volume with geli Message-ID: <ghtlf1$8qs$1@ger.gmane.org> In-Reply-To: <20081212130848.GB39875@carrot.studby.ntnu.no> References: <4940FF0F.2020404@field.hu> <20081211205659.GA72478@keira.kiwi-computer.com> <49419680.4010003@field.hu> <20081212040137.GA76422@keira.kiwi-computer.com> <20081212083708.GA1455@carrot.studby.ntnu.no> <ghtd59$ego$1@ger.gmane.org> <20081212130848.GB39875@carrot.studby.ntnu.no>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB04A2D7738FD0766A66FE88C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ulf Lilleengen wrote: > On Fri, Dec 12, 2008 at 11:07:40AM +0100, Ivan Voras wrote: >> Ulf Lilleengen wrote: >>> On tor, des 11, 2008 at 10:01:37pm -0600, Rick C. Petty wrote: >>> *snip* >>>> There are a set of patches that lulf@ has which I believe put the vo= lume in >>>> "up" state initially instead of "down", but maybe it only works for >>>> mirrors. The code in current and RELENG_7 does initially put the vo= lume in >>>> "down" state. >>>> >>> Yes, it only works for mirrors, since I thought it doesn't really mat= ter if a >>> mirror is properly initialized, since the user need to put data into = the >>> mirror for it to be useful anyway. The same goes for RAID-5 I guess, = but I >>> was not sure if it might trigger some weird behaviour since parity wo= uld not >>> match if reading the volume. I will test out a small modification I m= ade, >>> which removes the need to run 'gvinum start' on the raid5 plexes. >> It doesn't have to be "weird" behaviour, depending on whether gvinum >> checks parity on reads (does it?). If it does, it will only have to >> ignore checksum errors in this case. > It does check parity on reads. But I think it doesn't matter, since no = sane data > has been written in that block anyway.=20 >=20 > But as you say, one way to handle it is to ignore the checksums if the = data > is known to not be initialized, but then wouldn't one have to keep trac= k of > which blocks have a valid parity and which who does not? >=20 >> I suppose people will want to run utilities like diskinfo -vt on the >> volume with invalid parities so it's not a theoretical scenario :) >> > I guess, but I then one can just initialize the volume anyway. In the interest of simplicity, maybe a single, well documented flag that says "don't check checksums on reads" will do best. It will also probably help read performance. Of course, it should be off by default and its implications explained in the man page :) --------------enigB04A2D7738FD0766A66FE88C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJQlkkldnAQVacBcgRApUQAKD0eupyquvLWzYn/CbczuHqL+w3RACbBhPG acftybWfOZLfIIq+YtpUzPQ= =vFAl -----END PGP SIGNATURE----- --------------enigB04A2D7738FD0766A66FE88C--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ghtlf1$8qs$1>