From patchwork Mon May 8 11:48:07 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Boris BREZILLON X-Patchwork-Id: 9716115 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 81B1360234 for ; Mon, 8 May 2017 11:48:31 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6E33321E5A for ; Mon, 8 May 2017 11:48:31 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 62D1B223C7; Mon, 8 May 2017 11:48:31 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1408821E5A for ; Mon, 8 May 2017 11:48:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754022AbdEHLsS (ORCPT ); Mon, 8 May 2017 07:48:18 -0400 Received: from mail.free-electrons.com ([62.4.15.54]:60278 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752759AbdEHLsR (ORCPT ); Mon, 8 May 2017 07:48:17 -0400 Received: by mail.free-electrons.com (Postfix, from userid 110) id 88E1520854; Mon, 8 May 2017 13:48:15 +0200 (CEST) Received: from bbrezillon (unknown [91.160.177.164]) by mail.free-electrons.com (Postfix) with ESMTPSA id 3EB972083A; Mon, 8 May 2017 13:48:15 +0200 (CEST) Date: Mon, 8 May 2017 13:48:07 +0200 From: Boris Brezillon To: Richard Weinberger Cc: Pavel Machek , David Woodhouse , "linux-scsi@vger.kernel.org" , Hans de Goede , LKML , linux-ide@vger.kernel.org, "linux-mtd@lists.infradead.org" , Henrique de Moraes Holschuh , Tejun Heo Subject: Re: Race to power off harming SATA SSDs Message-ID: <20170508134807.498b3ee7@bbrezillon> In-Reply-To: References: <20170410232118.GA4816@khazad-dum.debian.net> <20170410235206.GA28603@wtj.duckdns.org> <20170507204007.GA25628@atrey.karlin.mff.cuni.cz> <1494228094.6528.14.camel@infradead.org> <20170508092846.GA11029@amd> <1494236048.6528.32.camel@infradead.org> <20170508104953.GA17773@amd> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, 8 May 2017 13:06:17 +0200 Richard Weinberger wrote: > On Mon, May 8, 2017 at 12:49 PM, Pavel Machek wrote: > > Aha, nice, so it looks like ubifs is a step back here. > > > > 'clean marker' is a good idea... empty pages have plenty of space. > > If UBI (not UBIFS) faces an empty block, it also re-erases it. Unfortunately, that's not the case, though UBI can easily be patched to do that (see below). > The EC header is uses as clean marker. That is true. If the EC header has been written to a block, that means this block has been correctly erased. > > > How do you handle the issue during regular write? Always ignore last > > successfully written block? I guess UBIFS can know what was written last, because of the log-based approach + the seqnum stored along with FS nodes, but I'm pretty sure UBIFS does not re-write the last written block in case of an unclean mount. Richard, am I wrong? > > The last page of a block is inspected and allowed to be corrupted. Actually, it's not really about corrupted pages, it's about pages that might become unreadable after a few reads. > > > Do you handle "paired pages" problem on MLC? > > Nope, no MLC support in mainline so far. Richard and I have put a lot of effort to reliably support MLC NANDs in mainline, unfortunately this projects has been paused. You can access the last version of our work here [1] if you're interested (it's clearly not in a shippable state ;-)). [1]https://github.com/bbrezillon/linux-sunxi/commits/bb/4.7/ubi-mlc --->8--- diff --git a/drivers/mtd/ubi/attach.c b/drivers/mtd/ubi/attach.c index 93ceea4f27d5..3d76941c9570 100644 --- a/drivers/mtd/ubi/attach.c +++ b/drivers/mtd/ubi/attach.c @@ -1121,21 +1121,20 @@ static int scan_peb(struct ubi_device *ubi, struct ubi_attach_info *ai, return err; goto adjust_mean_ec; case UBI_IO_FF_BITFLIPS: + case UBI_IO_FF: + /* + * Always erase the block if the EC header is empty, even if + * no bitflips were reported because otherwise we might + * expose ourselves to the 'unstable bits' issue described + * here: + * + * http://www.linux-mtd.infradead.org/doc/ubifs.html#L_unstable_bits + */ err = add_to_list(ai, pnum, UBI_UNKNOWN, UBI_UNKNOWN, ec, 1, &ai->erase); if (err) return err; goto adjust_mean_ec; - case UBI_IO_FF: - if (ec_err || bitflips) - err = add_to_list(ai, pnum, UBI_UNKNOWN, - UBI_UNKNOWN, ec, 1, &ai->erase); - else - err = add_to_list(ai, pnum, UBI_UNKNOWN, - UBI_UNKNOWN, ec, 0, &ai->free); - if (err) - return err; - goto adjust_mean_ec; default: ubi_err(ubi, "'ubi_io_read_vid_hdr()' returned unknown code %d", err);