All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Richard Weinberger <richard.weinberger@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>,
	David Woodhouse <dwmw2@infradead.org>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	Hans de Goede <hdegoede@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-ide@vger.kernel.org,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
	Tejun Heo <tj@kernel.org>
Subject: Re: Race to power off harming SATA SSDs
Date: Mon, 8 May 2017 13:48:07 +0200	[thread overview]
Message-ID: <20170508134807.498b3ee7@bbrezillon> (raw)
In-Reply-To: <CAFLxGvzAmURHU_6K3gmBfOqHKgvQOkkO_+qgMKsmzhWZwwGnqw@mail.gmail.com>

On Mon, 8 May 2017 13:06:17 +0200
Richard Weinberger <richard.weinberger@gmail.com> wrote:

> On Mon, May 8, 2017 at 12:49 PM, Pavel Machek <pavel@ucw.cz> 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);

  reply	other threads:[~2017-05-08 11:48 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-10 23:21 Race to power off harming SATA SSDs Henrique de Moraes Holschuh
2017-04-10 23:34 ` Bart Van Assche
2017-04-10 23:50   ` Henrique de Moraes Holschuh
2017-04-10 23:49 ` sd: wait for slow devices on shutdown path Henrique de Moraes Holschuh
2017-04-10 23:52 ` Race to power off harming SATA SSDs Tejun Heo
2017-04-10 23:57   ` James Bottomley
2017-04-11  2:02     ` Henrique de Moraes Holschuh
2017-04-11  1:26   ` Henrique de Moraes Holschuh
2017-04-11 10:37   ` Martin Steigerwald
2017-04-11 14:31     ` Henrique de Moraes Holschuh
2017-04-12  7:47       ` Martin Steigerwald
2017-05-07 20:40   ` Pavel Machek
2017-05-07 20:40     ` Pavel Machek
2017-05-08  7:21     ` David Woodhouse
2017-05-08  7:38       ` Ricard Wanderlof
2017-05-08  7:38         ` Ricard Wanderlof
2017-05-08  8:13         ` David Woodhouse
2017-05-08  8:36           ` Ricard Wanderlof
2017-05-08  8:36             ` Ricard Wanderlof
2017-05-08  8:54             ` David Woodhouse
2017-05-08  9:06               ` Ricard Wanderlof
2017-05-08  9:06                 ` Ricard Wanderlof
2017-05-08  9:09                 ` Hans de Goede
2017-05-08 10:13                   ` David Woodhouse
2017-05-08 11:50                     ` Boris Brezillon
2017-05-08 15:40                       ` David Woodhouse
2017-05-08 21:36                         ` Pavel Machek
2017-05-08 16:43                       ` Pavel Machek
2017-05-08 17:43                         ` Tejun Heo
2017-05-08 18:56                           ` Pavel Machek
2017-05-08 19:04                             ` Tejun Heo
2017-05-08 18:29                         ` Atlant Schmidt
2017-05-08 10:12                 ` David Woodhouse
2017-05-08 10:12                   ` David Woodhouse
2017-05-08  9:28       ` Pavel Machek
2017-05-08  9:34         ` David Woodhouse
2017-05-08 10:49           ` Pavel Machek
2017-05-08 11:06             ` Richard Weinberger
2017-05-08 11:48               ` Boris Brezillon [this message]
2017-05-08 11:55                 ` Boris Brezillon
2017-05-08 12:13                 ` Richard Weinberger
2017-05-08 11:09             ` David Woodhouse
2017-05-08 12:32               ` Pavel Machek
2017-05-08  9:51         ` Richard Weinberger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170508134807.498b3ee7@bbrezillon \
    --to=boris.brezillon@free-electrons.com \
    --cc=dwmw2@infradead.org \
    --cc=hdegoede@redhat.com \
    --cc=hmh@hmh.eng.br \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=richard.weinberger@gmail.com \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.