From owner-freebsd-fs@FreeBSD.ORG Sat Jan 23 10:05:39 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 3BC87106566C for ; Sat, 23 Jan 2010 10:05:39 +0000 (UTC) (envelope-from rincebrain@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id C467B8FC0C for ; Sat, 23 Jan 2010 10:05:38 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 16so296690fgg.13 for ; Sat, 23 Jan 2010 02:05:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=xhhzeFejFgUpsMRJE6ap5peUfbpc3NRIlyowAVJPOL4=; b=RueLfTLRxiV49QCOg2g7pe96xDyJRNQnMlq5+iTbM7ZjFnhk5pZyXA7juIyOf3qkBm CV734FXAKH9Khh9PEf0HxiGmVIGl1tFI1D8T1Y4DwQE0lnYfvNF8NqoftXIBSTmUVZeh sJLG9Vir3F7l/cgUq7E/rWMdjo+T7aF+vUIpo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AiNr6utpb/Exd6rR3GNttvaUxLVMnR2/uausabhfc0D9hk73Tw/16rSfKcWX/7FEYK 2yfL/HJwmX0SXLekyooQLmogKn4/+v2nIqow1KRAwYwh/QwU+owKQXKPz2tobIj3HJLl Rbjazem8ZI8W3/Fzq8MXT7HEpLGjqI86xOGgg= MIME-Version: 1.0 Received: by 10.239.188.82 with SMTP id o18mr464021hbh.129.1264241137470; Sat, 23 Jan 2010 02:05:37 -0800 (PST) In-Reply-To: References: <5da0588e1001222223m773648am907267235bdcf882@mail.gmail.com> <5da0588e1001230014k1b8a32f8v42046497265429ed@mail.gmail.com> <5da0588e1001230136j52442acfw306dccaa889af7bb@mail.gmail.com> Date: Sat, 23 Jan 2010 05:05:37 -0500 Message-ID: <5da0588e1001230205y43f359dh68268a9c59b6ce53@mail.gmail.com> From: Rich To: Artem Belevich Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs 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: Sat, 23 Jan 2010 10:05:39 -0000 On Sat, Jan 23, 2010 at 4:57 AM, Artem Belevich wrote: > I guess it's a feature. Without redundancy all ZFS can do is report > corruption. If corruption is in the file data, it cen be removed along > with the file. If corruption is in directory or in metadata there's > little ZFS can do because that particular portion of filesystem is > inconsistent. The best that could be done is to keep those portions > read-only and try not to crash right away. > > With 7TB of data with no redundancy of any kind you are asking for > trouble even with all hardware functioning within spec. I'm well aware, thank you. The data is all retrievable from other sources, which is why redundancy wasn't a large concern in this particular pool, just speed, and knowledge of when bits flip. Of course, when all ZFS claims to do is raise EIO on corruption, and requires you to nuke the pool from orbit in order to get it to stop, rather than isolating and removing the offending segments, it's rather frustrating. - Rich