From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-bw0-f49.google.com ([209.85.214.49]) by bombadil.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1Oyqdc-0005pX-2o for linux-mtd@lists.infradead.org; Thu, 23 Sep 2010 18:35:21 +0000 Received: by bwz19 with SMTP id 19so1981609bwz.36 for ; Thu, 23 Sep 2010 11:35:18 -0700 (PDT) Subject: Re: UBI/UBIFS interrupted write page handling From: Artem Bityutskiy To: Matthieu CASTET In-Reply-To: <4C9B7CD8.4070806@parrot.com> References: <4C88DDD5.4060507@parrot.com> <1284054669.11335.21.camel@brekeke> <1285006478.1762.1.camel@brekeke> <4C9B7CD8.4070806@parrot.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 23 Sep 2010 21:35:13 +0300 Message-ID: <1285266914.1766.1.camel@brekeke> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: "linux-mtd@lists.infradead.org" Reply-To: dedekind1@gmail.com List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, 2010-09-23 at 18:14 +0200, Matthieu CASTET wrote: > Hi Artem, > > Artem Bityutskiy a écrit : > > On Thu, 2010-09-09 at 20:51 +0300, Artem Bityutskiy wrote: > >>> On one of our test, we are in case 3. Ubifs find a valid interrupt page > >>> on mount and trust it. Latter the page become corrupted [1] because it > >>> is unstable. > >> OK, I see. > >> > >>> To identify a interrupted write page we : > >>> - could use interrupted flags for static volume > >>> - handle with care data move (copy flags) : if sqnum of the copy is the > >>> biggest, we should ignore it/copy it. > >>> - use upper layer for dynamic volume. For ubifs this could be a journal. > >> Actually, for UBIFS things are rather simple. In UBIFS every writes go > >> to the journal. Even GC writes to the journal. So when we are mounting > >> after an unclean reboot, we can simply refresh the last LEBs of all > >> journal heads using the 'ubi_leb_change()' call. This should handle all > >> the three cases you describe. > >> > >> I do not think it is very difficult to do. > > > > Matthieu, I can try to do to make some patches for you, but when you > > come back on-line and start actively testing :-) I do want to help you > > and improve UBIFS, but I'm not very motivated to do this unless this is > > really needed. I think we have few other pending issues, and the ball is > > on your side. :-) > > > Ok. > > I will run some tests this weekend. > > What I have to test ? > > - > http://git.infradead.org/users/dedekind/ubifs-v2.6.28.git/commit/7240a7396fa4b1998d0463123c6d1d192935f969 > - UBI reliability improvements patch > - c->gc_lnum is -1 patch Yes. But it would be less confusing if you just back-ported all ubifs-2.6.git / master. c->gc_lnum is a separate patch, of course. -- Best Regards, Artem Bityutskiy (Битюцкий Артём)