Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <0a4fc94213ca5c2040796a66942f626587483721.camel@gmail.com>
Subject: Re: [PATCH v6 0/5] Micron SLC NAND filling block
From:   Bean Huo <huobean@gmail.com>
To:     miquel.raynal@bootlin.com, vigneshr@ti.com, s.hauer@pengutronix.de,
        boris.brezillon@collabora.com, derosier@gmail.com,
        Richard Weinberger <richard@nod.at>
Cc:     linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
        Bean Huo <beanhuo@micron.com>
Date:   Mon, 01 Jun 2020 23:10:43 +0200
In-Reply-To: <829d76189beff5a50ddc56123d22bff3aa6a3378.camel@gmail.com>
References: <20200525121814.31934-1-huobean@gmail.com>
         <829d76189beff5a50ddc56123d22bff3aa6a3378.camel@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


Hi Richard 
would you please help us confirm below question??

Thanks,
Bean

On Thu, 2020-05-28 at 16:14 +0200, Bean Huo wrote:
> hi, Richard
> 
> 
> On Mon, 2020-05-25 at 14:18 +0200, Bean Huo wrote:
> > After submission of patch V1 [1] and V2 [2], we stopped its update
> > since we get
> > stuck in the solution on how to avoid the power-loss issue in case
> > power-cut
> > hits the block filling. In the v1 and v2, to avoid this issue, we
> > always damaged
> > page0, page1, this's based on the hypothesis that NAND FS is UBIFS.
> > This
> > FS-specifical code is unacceptable in the MTD layer. Also, it
> > cannot
> > cover all
> > NAND based file system. Based on the current discussion, seems that
> > re-write all
> > first 15 page from page0 is a satisfactory solution.
> 

> This patch has overwrite page0~page14, damage EC and VID header
> boths.
> I know this is safe for UBIFS, even fastmap is enabled (you fixed
> this in (ubi: fastmap: Correctly handle interrupted erasures in
> EBA)).
> Now, how about jffs2? 
> 
> 
> Thanks,
> Bean
>