From patchwork Fri Jan 28 17:13:20 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: twebb X-Patchwork-Id: 80875 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id D0EE21007D1 for ; Sat, 29 Jan 2011 04:17:39 +1100 (EST) Received: from canuck.infradead.org ([2001:4978:20e::1]) by bombadil.infradead.org with esmtps (Exim 4.72 #1 (Red Hat Linux)) id 1Pirt1-00014A-4B; Fri, 28 Jan 2011 17:13:27 +0000 Received: from localhost ([127.0.0.1] helo=canuck.infradead.org) by canuck.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1Pirsz-0006J0-MT; Fri, 28 Jan 2011 17:13:25 +0000 Received: from mail-gx0-f177.google.com ([209.85.161.177]) by canuck.infradead.org with esmtps (Exim 4.72 #1 (Red Hat Linux)) id 1Pirsw-0006IZ-Gf for linux-mtd@lists.infradead.org; Fri, 28 Jan 2011 17:13:23 +0000 Received: by gxk21 with SMTP id 21so1185016gxk.36 for ; Fri, 28 Jan 2011 09:13:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BDOXDi5bFgzAncYR46xsIz660tCMx7wtkQmL85h4XNA=; b=cGE+EdOlPSxtg9MU4Sx+/KcvxIWyzQLd32tD2nBhe181l7QXEI9cmytaLuVfi8+KLK ZDE5TKVM3RJioLFpW9Fd9QYp8Jl24ipYKNDd+5MtwNhkHhOctEJXOTb+P2u2j4HdCg8h kl4pcWJm1GOWubpOQl808uQV90LUfdZVnoJ2w= 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=NZVR4KUddFYZznQUyH727gYjgyXq3pZ2ZDuUBA13/RmkHJPfNGnB6xI9DaOQ7sEZXk cXEuMwf/Hfvtsvg1zIt2iKQB1Immfqzp/V5m5ZFe1l0SmZEIubsnj07f74kkZYVr31NZ 2szeBeqFEqTP5KoI4zeZvh07B2NhF3CPmhl2A= MIME-Version: 1.0 Received: by 10.236.108.33 with SMTP id p21mr5759063yhg.79.1296234800599; Fri, 28 Jan 2011 09:13:20 -0800 (PST) Received: by 10.236.108.5 with HTTP; Fri, 28 Jan 2011 09:13:20 -0800 (PST) In-Reply-To: <1278995528.16634.129.camel@localhost> References: <1278995289.16634.126.camel@localhost> <1278995528.16634.129.camel@localhost> Date: Fri, 28 Jan 2011 12:13:20 -0500 Message-ID: Subject: Re: ubifs_scan() error handling From: twebb To: dedekind1@gmail.com X-CRM114-Version: 20090807-BlameThorstenAndJenny ( TRE 0.7.6 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20110128_121322_694440_DE4AA190 X-CRM114-Status: GOOD ( 14.63 ) X-Spam-Score: 1.4 (+) X-Spam-Report: SpamAssassin version 3.3.1 on canuck.infradead.org summary: Content analysis details: (1.4 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is freemail (taliaferro62[at]gmail.com) 2.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (taliaferro62[at]gmail.com) -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.161.177 listed in list.dnswl.org] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 T_TO_NO_BRKTS_FREEMAIL T_TO_NO_BRKTS_FREEMAIL Cc: Lei Wen , linux-mtd@lists.infradead.org X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org > On Tue, 2010-07-13 at 07:28 +0300, Artem Bityutskiy wrote: >> > Would it make sense and be acceptable to make this call any time >> > ubifs_scan() returns an error? >> >> May be. I'll think and return to you. > > We can probably go for it, but the current recovery is not enough for > MLC anyway. So I'd prefer to do the change you propose as a part of > larger UBIFS on MLC patch-set. > > Please, analyse ubifs_recover_leb(), find out what should be changed > there for MLC, send a patch-set. > It's been awhile but I wanted to reopen the discussion on this topic. Could you take a look at this proposed patch? Essentially this change results in the LEB being cleaned/recovered regardless of whether is_last_write() is true or not. There may be a better way to do this earlier in the same function, but I'm not familiar enough with it to know the significance of the is_last_write() call. diff -Naru a/fs/ubifs/recovery.c b/fs/ubifs/recovery.c --- a/fs/ubifs/recovery.c 2011-01-26 16:08:04.000000000 -0500 +++ b/fs/ubifs/recovery.c 2011-01-26 16:08:25.000000000 -0500 @@ -665,19 +665,8 @@ } if (!empty_chkd && !is_empty(buf, len)) { - if (is_last_write(c, buf, offs)) { - clean_buf(c, &buf, lnum, &offs, &len); - need_clean = 1; - } else { - int corruption = first_non_ff(buf, len); - - ubifs_err("corrupt empty space LEB %d:%d, corruption " - "starts at %d", lnum, offs, corruption); - /* Make sure we dump interesting non-0xFF data */ - offs = corruption; - buf += corruption; - goto corrupted; - } + clean_buf(c, &buf, lnum, &offs, &len); + need_clean = 1; } /* Drop nodes from incomplete group */