All of lore.kernel.org
 help / color / mirror / Atom feed
From: Iwo Mergler <Iwo.Mergler@netcommwireless.com>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: "Jeff Lauruhn \(jlauruhn\)" <jlauruhn@micron.com>,
	"dedekind1@gmail.com" <dedekind1@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	Andrea Scian <rnd4@dave-tech.it>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Andrea Marson <andrea.marson@dave.eu>
Subject: RE: RFC: detect and manage power cut on MLC NAND
Date: Mon, 23 Mar 2015 13:18:52 +1100	[thread overview]
Message-ID: <EACD232272DA4849B060F0828564D13B57804E272F@ntcex01.corp.netcomm.com.au> (raw)
In-Reply-To: <20150320092611.2648f3d5@bbrezillon>

On Fri, 20 Mar 2015 19:26:11 +1100
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:

> You want to do that in order to avoid using 2 Jumbo pages to only
> store a few bytes ?

Yes. I'm already a little unhappy about using two whole pages
for UBI, and don't want to be guilty of doubling that.

> Artem suggested another solution to deal with that: duplicate the EC
> header in the VID header so that EC information can be recovered when
> writing to the page paired with the EC header.

Sounds good to me. It won't avoid the loss of the VID header,
but it will safeguard the EC. It's free, too.

> You'd still have to prevent any write on the page paired with the EC
> header, but you're still saving one page with this approach and avoid
> any corruption of UBI metadata caused by paired pages.

Ah, you probably meant VID header here, right?

> Maybe there are better solution, and I've been thinking about a
> different approach to avoid writing the EC and VID headers in 2
> different pages: store EC header information in a specific UBI volume
> (containing one or two LEBs).
> This volume would store a log of EC information update, so that when
> you erase a page you don't have to write the EC header right away, but
> should just add an entry in the UBI EC log.
> This way you write EC and VID information in one go when someone maps
> a LEB (attach it to a specific volume).

I like that. Maybe UBI could try grouping erases to reduce the
stress on the EC log - write the (future) ECs for a number of
PEBs to the log, then delete the PEBS at leisure, then mark
them as done in the log.

In fact, you could even go and pad the log pages with future
ECs for active PEBs, to be used in case they need erasing later.
Just never erase a PEB that doesn't have an EC log entry.

Would it be possible to push that further, and defer the writing
of the VID header until the first payload write is pending? Up to
that point, it shouldn't matter where the LEB is mapped.

I'm aware that UBIFS would have to cooperate here (first page is
64 bytes smaller), but VID and integrated EC could share the
page 0 with the first payload nodes of the LEB.


Best regards,

Iwo

  parent reply	other threads:[~2015-03-23  2:19 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-10 11:57 RFC: detect and manage power cut on MLC NAND Andrea Scian
2015-03-10 12:51 ` Richard Weinberger
2015-03-11  7:20   ` Artem Bityutskiy
2015-03-11  8:57     ` Richard Weinberger
2015-03-11  9:05       ` Artem Bityutskiy
2015-03-11  9:09         ` Richard Weinberger
2015-03-11 17:01           ` Andrea Scian
2015-03-11 17:23             ` Jeff Lauruhn (jlauruhn)
2015-03-11 17:29               ` Richard Weinberger
2015-03-11 21:16                 ` Jeff Lauruhn (jlauruhn)
2015-03-12 10:28                   ` Richard Weinberger
2015-03-12 22:57                     ` Jeff Lauruhn (jlauruhn)
2015-03-13 20:31                       ` Boris Brezillon
2015-03-13 23:51                         ` Jeff Lauruhn (jlauruhn)
2015-03-14  9:46                           ` Andrea Marson - DAVE Embedded Systems
2015-03-16 16:02                             ` Jeff Lauruhn (jlauruhn)
2015-03-17  8:00                               ` Andrea Scian
2015-03-14 10:32                           ` Boris Brezillon
2015-03-16 21:11                             ` Jeff Lauruhn (jlauruhn)
2015-03-17  9:30                               ` Andrea Scian
2015-03-17 10:02                                 ` Boris Brezillon
2015-03-17 16:42                                   ` Jeff Lauruhn (jlauruhn)
2015-03-18  8:45                                     ` RFC: detect and manage power cut on MLC NAND (linux-mtd Digest, Vol 144, Issue 70) Andrea Marson
2015-03-18  9:07                                       ` Boris Brezillon
2015-03-18  9:56                                         ` Andrea Marson
2015-03-18 10:03                                           ` Boris Brezillon
2015-03-18 12:07                                         ` Richard Weinberger
2015-03-18 17:11                                           ` Jeff Lauruhn (jlauruhn)
2015-03-18 16:12                                       ` Jeff Lauruhn (jlauruhn)
2015-03-19  8:47                                         ` RFC: detect and manage power cut on MLC NAND Andrea Marson
2015-03-19  9:12                                           ` Boris Brezillon
2015-03-19 17:45                                             ` Jeff Lauruhn (jlauruhn)
2015-03-20  0:25                                             ` Iwo Mergler
2015-03-20  3:38                                               ` nick
2015-03-20  5:40                                                 ` Iwo Mergler
2015-03-20  8:26                                               ` Boris Brezillon
2015-03-20 17:15                                                 ` Nick Krause
2015-03-22 23:45                                                 ` Iwo Mergler
2015-03-23  2:18                                                 ` Iwo Mergler [this message]
2015-03-23  7:06                                                   ` Artem Bityutskiy
2015-03-23 19:05                                                     ` Boris Brezillon
2015-03-24  7:05                                                       ` Artem Bityutskiy
2015-03-19 18:00                                           ` Jeff Lauruhn (jlauruhn)
2015-03-20  8:07                                             ` Andrea Marson
2015-03-17 17:04                                 ` Jeff Lauruhn (jlauruhn)
2015-03-16  9:01                         ` Ricard Wanderlof
2015-03-16 17:27                           ` Jeff Lauruhn (jlauruhn)
2015-03-14 10:03                       ` Richard Weinberger
2015-03-12  9:32               ` Ricard Wanderlof
2015-03-23  4:08           ` Iwo Mergler
2015-03-23 21:15             ` Jeff Lauruhn (jlauruhn)
2015-03-24  1:17               ` Iwo Mergler
2015-03-24 16:50                 ` Jeff Lauruhn (jlauruhn)
2015-03-25  3:38                   ` Iwo Mergler
2015-03-25  8:33                     ` Ricard Wanderlof
2015-03-26  1:57                       ` Jeff Lauruhn (jlauruhn)
2015-03-26  8:55                         ` Ricard Wanderlof
2015-03-11  7:21 ` Artem Bityutskiy
  -- strict thread matches above, loose matches on Subject: below --
2015-03-12 10:31 Andrea Marson - DAVE Embedded Systems
     [not found] <mailman.37176.1426610573.22890.linux-mtd@lists.infradead.org>

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=EACD232272DA4849B060F0828564D13B57804E272F@ntcex01.corp.netcomm.com.au \
    --to=iwo.mergler@netcommwireless.com \
    --cc=andrea.marson@dave.eu \
    --cc=boris.brezillon@free-electrons.com \
    --cc=dedekind1@gmail.com \
    --cc=jlauruhn@micron.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    --cc=rnd4@dave-tech.it \
    /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.