From owner-freebsd-fs@FreeBSD.ORG Wed Mar 14 05:08:05 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2552106566C for ; Wed, 14 Mar 2012 05:08:05 +0000 (UTC) (envelope-from markm-lists@intellasoft.net) Received: from mail.mystoragebox.com (mail.mystoragebox.com [64.27.7.19]) by mx1.freebsd.org (Postfix) with ESMTP id 979EA8FC0A for ; Wed, 14 Mar 2012 05:08:05 +0000 (UTC) Received: from cpe-67-240-79-210.nycap.res.rr.com ([67.240.79.210] helo=[192.168.35.110]) by mail.mystoragebox.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1S7g7R-0001EC-1l for freebsd-fs@freebsd.org; Wed, 14 Mar 2012 00:47:25 -0400 Message-ID: <4F6027B3.5080006@intellasoft.net> Date: Wed, 14 Mar 2012 01:08:03 -0400 From: Mark Murawski User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4F5F7116.3020400@intellasoft.net> <4F5F97A4.6070000@brockmann-consult.de> <4F60266D.1090302@intellasoft.net> In-Reply-To: <4F60266D.1090302@intellasoft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ZFS file corruption problem 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: Wed, 14 Mar 2012 05:08:05 -0000 On 03/14/12 01:02, Mark Murawski wrote: > On 03/13/12 14:53, Peter Maloney wrote: >> Am 13.03.2012 17:08, schrieb Mark Murawski: >>> So I have this zpool with corrupted files running on freebsd 9-release >>> amd64. The corrupted files can go away, that's not a big deal >>> >>> Here's the problem. >>> >>> $ ls -al /storage/zfs/0-Pics/2012-03-01-peterskill/155CANON/IMG_5576.CR2 >>> >> Since this is one of the corrupt files, I guess ZFS would like to block >> until it can return a good copy (such as if you put the mirror disk back >> in)... so to fix this, you need to remove the file or restore from >> backup (or add that mirror disk back in, which I will assume you can't): >> >> rm /storage/zfs/0-Pics/2012-03-01-peterskill/155CANON/IMG_5576.CR2 >> (in the case of a file that should exist empty instead of being removed, >> eg. a log where the log writer does not have write permission to the >> directory, do touch also) >> >> or maybe this works: >> >> mv /somewhere_with_backup/IMG_5576.CR2 >> /storage/zfs/0-Pics/2012-03-01-peterskill/155CANON/IMG_5576.CR2 >> >> >> And if there are more errors, you probably need to scrub to expand the >> pool or for "zpool clear" to work. >> > > Oh wow. For some reason I never thought of rm. That works on getting rid > of the file. > > Why would the whole pool now become available upon access to a bad file? Also... isn't this pretty terrible behavior that the process accessing the bad file is unkillable?