Date: Tue, 28 Aug 2007 20:02:28 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Bakul Shah <bakul@bitblocks.com> Cc: current@FreeBSD.org, Pascal Hofstee <caelian@gmail.com> Subject: Re: ZFS kernel panic Message-ID: <20070828180228.GD39562@garage.freebsd.pl> In-Reply-To: <20070828170242.1559F5B30@mail.bitblocks.com> References: <20070828165331.GA39562@garage.freebsd.pl> <20070828170242.1559F5B30@mail.bitblocks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--uxuisgdDHaNETlh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 28, 2007 at 10:02:42AM -0700, Bakul Shah wrote: > > When you don't use redundant configuration (no mirror, no raidz, no > > copies>1) then ZFS is going to panic on a write failure. It looks like > > ZFS found a bad block on your disk. >=20 > Does SUN really say this about ZFS? Is this acceptable in a > production environment? What if one of your mirrored disk > fails and in the "degraded" environment (before you have had > a chance to replace the bad disk) ZFS discovers that a write > fails? Why can't it find an alternative block to write to? There were many complains on zfs-discuss@, you may want to look into archive. The short version is that many users doesn't like that, and it should change in the future - because of COW model it should be quite easy to just mark block as bad and take next one, but it's not currently implemented. It's much less of a problem when one uses redundancy. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --uxuisgdDHaNETlh8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG1GM0ForvXbEpPzQRArAmAKCxNQTAPw5zym9a0TmqJpp3ucombACfSJA4 9nv40SueyQal5WcwMKfWubw= =5NnR -----END PGP SIGNATURE----- --uxuisgdDHaNETlh8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070828180228.GD39562>