From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 03:15:14 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B21531065692 for ; Sun, 24 Jan 2010 03:15:14 +0000 (UTC) (envelope-from grog@lemis.com) Received: from w3.lemis.com (w3.lemis.com [208.86.224.149]) by mx1.freebsd.org (Postfix) with ESMTP id 7ECAC8FC1D for ; Sun, 24 Jan 2010 03:15:14 +0000 (UTC) Received: from dereel.lemis.com (121-200-1-204.cust.aussiebb.net [121.200.1.204]) by w3.lemis.com (Postfix) with ESMTP id 1E79D3BACE; Sun, 24 Jan 2010 03:04:57 +0000 (UTC) Received: by dereel.lemis.com (Postfix, from userid 1004) id 872A2A1098; Sun, 24 Jan 2010 14:04:51 +1100 (EST) Date: Sun, 24 Jan 2010 14:04:51 +1100 From: Greg 'groggy' Lehey To: Rich Message-ID: <20100124030451.GB88876@dereel.lemis.com> References: <5da0588e1001230014k1b8a32f8v42046497265429ed@mail.gmail.com> <5da0588e1001231415t403f29ceq6e8dcd16edb4a28@mail.gmail.com> <5da0588e1001231541l246769eao410c5ea6ccca0de4@mail.gmail.com> <5da0588e1001231615t37c22575uedaae938be40f530@mail.gmail.com> <4B5B94B8.7070509@modulus.org> <5da0588e1001231638i349f8f17t297e970b08825441@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DKU6Jbt7q3WqK7+M" Content-Disposition: inline In-Reply-To: <5da0588e1001231638i349f8f17t297e970b08825441@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Organization: The FreeBSD Project Phone: +61-3-5346-1370 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: freebsd-fs@freebsd.org Subject: Re: Errors on a file on a zpool: How to remove? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 03:15:14 -0000 --DKU6Jbt7q3WqK7+M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [sequence recovered] On Saturday, 23 January 2010 at 19:38:47 -0500, Rich wrote: > On Sat, Jan 23, 2010 at 7:30 PM, Andrew Snow wrote: >> Rich wrote: >>> >>> I claim this is still Bad Behavior, and should be resolvable without >>> doing something like that. >> >> I cannot agree that silent corruption (which would have happened with any >> other filesystem) is preferable to what ZFS is doing here. >> >> You had bad RAM, and no redundancy in a huge RAID0, I think it would be >> reasonable to have to restore from backups or recreate the data and not pin >> blame on ZFS. > > I'm not claiming that restoring data from backups is unreasonable, or > that silent data corruption is better. > > I'm claiming that my inability to delete the corrupted data in order > to restore from backups without nuking unaffected data or remaking the > filesystem is unreasonable. You have a file system with broken metadata. How can ZFS know how to work around this corruption? By continuing things could get worse. I haven't been following this thread, but the way I see it: Reasonable: to be able to mount the file system read-only and recover what data you can from it. Unreasonable: to expect the file system to repair corruption of an unknown type. The only safe path is to create the file system from scratch. This has nothing to do with how you recover the data. Greg -- See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua --DKU6Jbt7q3WqK7+M Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAktbuNMACgkQIubykFB6QiPQMgCeLGly2NzemOpmhGFy/gMZsq7E E/MAn0Xjji6KbsY2btFmlYxFlCoGK0Ad =EMrR -----END PGP SIGNATURE----- --DKU6Jbt7q3WqK7+M--