From: Richard Weinberger <richard@nod.at>
To: artem.bityutskiy@linux.intel.com
Cc: Tim Bird <tim.bird@am.sony.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"adrian.hunter@intel.com" <adrian.hunter@intel.com>,
"Heinz.Egger@linutronix.de" <Heinz.Egger@linutronix.de>,
"thomas.wucher@linutronix.de" <thomas.wucher@linutronix.de>,
"shmulik.ladkani@gmail.com" <shmulik.ladkani@gmail.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"Marius.Mazarel@ugal.ro" <Marius.Mazarel@ugal.ro>,
"nyoushchenko@mvista.com" <nyoushchenko@mvista.com>
Subject: Re: UBI fastmap updates
Date: Thu, 2 Aug 2012 19:45:38 +0200 [thread overview]
Message-ID: <20120802194538.26e2ec98@spider.haslach.nod.at> (raw)
In-Reply-To: <1343929200.25013.197.camel@sauron.fi.intel.com>
Am Thu, 02 Aug 2012 20:40:00 +0300
schrieb Artem Bityutskiy <artem.bityutskiy@linux.intel.com>:
> Hi Tim,
>
> On Thu, 2012-08-02 at 10:03 -0700, Tim Bird wrote:
> > I'm don't understand what "UBI liability" is. Can you please
> > clarify? What breaks if the PEBs get consumed?
>
> let me try. Let's forget about bad blocks and assume we are talking
> about NOR flash. For simplicity.
>
> Let's also first forget about fastmap so far and talk about the
> current design.
>
> Suppose you have 100 PEBs on your flash. Suppose UBI reserves 10 for
> its internal needs (volume table, etc). 90 PEBs are available to the
> user.
>
> User now can create one or many volumes, but the overall size of the
> volumes cannot be larger than 90 LEBs.
>
> This means that UBI guarantees that you can always fill all volumes
> with data there will always be enough PEBs to map to. This is UBI
> liability.
>
> UBI will not allow you to create a volume of 100 LEBs because in this
> case it will not be able to guarantee that all LEBs will be writable.
>
> I have invented this "liability" term on the spot actually. It
> basically means what UBI already "promised", what it reserved an put
> aside.
>
> Now let's add fastmap support to the picture.
>
> Suppose fastmap took another 10 PEBs and now we have 80 PEBs for the
> user.
>
> The user can create a volume of 80 LEBs in size. And UBI has to
> guarantee that the user can at any point of time fill all of them with
> data.
>
> This means that fastmap in no circumstances can grab any more than 10
> PEBs, because they are all reserved, UBI liability is 80 PEBs.
>
> On other words, fastmap has to know how much PEBs it needs at the UBI
> initialization time, and reserve them. The _maximum_ value.
>
> The same way other UBI sub-systems do. E.g., the volume table code
> reserves 2 PEBs, because this is the maximum it needs at any point of
> time. The WL subsystem reserves 1 PEB.
>
> Of course this is not about reserving any specific PEB, this is just
> accounting - we have a couple of variable for reserved PEBs count.
>
> So let's return to the error messages I spotted. They say that fastmap
> needs a PEB but cannot find one. The flash is nandsim and has no
> badblocks. Why fastmap did not find one? Because it did not reserve
> enough. And UBI tests create volumes of maximum possible size and fill
> it with data, so all available PEBs are mapped and thus, used.
>
> What this means that the following situation is possible: the UBI
> volume is not fully filled yet and not all LEBs are mapped, so there
> are available PEBs, and fastmap successfully grows and reduces the
> amount of available PEBs. And when the user writes more data, he gets
> -ENOSPC.
>
> And this is basically the problem I indicated.
>
> To make my description complete, let's add NAND to the picture. We
> simply reserve 2% (by default, it is configurable) of PEBs for bad
> blocks handling. This is because vendors typically say that this is
> the maximum amount for the flash life-time.
>
> If NAND wears-out a lot, and we run out of reserved PEBs, we switch to
> R/O mode, because we cannot anymore keep our "promise", the liability.
>
> You can look at it this way. If you create an UBI volume, and mount it
> with UBIFS, you usually expect that all the free file-system space is
> available to you.
>
> You probably will be disappointed if you write your file and get
> -ENOSPC because fastmap does grew and consumed a PEB which which was
> promised to your volume.
>
Okay, then let's explicitly reserve a few PEBs for fastmap.
This should be very easy task.
How much PEB should be reserved? 2 x sizeof(fastmap)?
Thanks,
//richard
next prev parent reply other threads:[~2012-08-02 17:45 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-09 12:18 UBI fastmap updates Richard Weinberger
2012-07-09 12:18 ` [PATCH 1/7] UBI: Fastmap: Fix lock imbalance in case of an error Richard Weinberger
2012-07-09 12:18 ` [PATCH 2/7] UBI: Fastmap: Get rid of find_fastmap switch Richard Weinberger
2012-07-09 12:18 ` [PATCH 3/7] UBI: Fastmap: Fix memory leak in error path Richard Weinberger
2012-07-09 12:18 ` [PATCH 4/7] UBI: Fastmap: Fix double free " Richard Weinberger
2012-07-09 12:18 ` [PATCH 5/7] UBI: Fastmap: Kerneldoc fixes Richard Weinberger
2012-07-09 12:18 ` [PATCH 6/7] UBI: Fastmap: Make sure that find_wl_entry() never returns NULL Richard Weinberger
2012-07-09 12:18 ` [PATCH 7/7] UBI: Fastmap: Make checkpatch.pl happy Richard Weinberger
2012-08-02 14:12 ` UBI fastmap updates Artem Bityutskiy
2012-08-02 14:15 ` Richard Weinberger
2012-08-02 14:29 ` Artem Bityutskiy
2012-08-02 14:51 ` Richard Weinberger
2012-08-02 16:17 ` Artem Bityutskiy
2012-08-02 16:32 ` Richard Weinberger
2012-08-02 16:45 ` Artem Bityutskiy
2012-08-02 16:54 ` Richard Weinberger
2012-08-02 17:03 ` Tim Bird
2012-08-02 17:06 ` Richard Weinberger
2012-08-02 17:40 ` Artem Bityutskiy
2012-08-02 17:45 ` Richard Weinberger [this message]
2012-08-02 17:59 ` Artem Bityutskiy
2012-08-02 18:03 ` Richard Weinberger
2012-08-02 18:15 ` Artem Bityutskiy
2012-08-05 8:23 ` Shmulik Ladkani
2012-08-05 14:25 ` Richard Weinberger
2012-08-02 17:50 ` Artem Bityutskiy
2012-08-02 14:58 ` Artem Bityutskiy
2012-08-02 14:59 ` Richard Weinberger
2012-08-02 15:18 ` Artem Bityutskiy
2012-08-02 15:19 ` Richard Weinberger
2012-08-06 17:36 ` Richard Weinberger
2012-08-07 4:21 ` Artem Bityutskiy
2012-08-07 7:29 ` Richard Weinberger
2012-08-07 18:53 ` Artem Bityutskiy
2012-08-02 18:50 ` Artem Bityutskiy
2012-08-02 18:56 ` Artem Bityutskiy
2012-08-03 8:47 ` Artem Bityutskiy
2012-08-03 8:56 ` Richard Weinberger
2012-08-17 13:11 ` Artem Bityutskiy
2012-08-17 13:33 ` Richard Weinberger
2012-08-17 13:41 ` Artem Bityutskiy
2012-08-17 13:43 ` Richard Weinberger
2012-08-17 14:06 ` Artem Bityutskiy
-- strict thread matches above, loose matches on Subject: below --
2013-09-28 13:55 Richard Weinberger
2013-10-03 16:44 ` Artem Bityutskiy
2012-07-02 16:23 Richard Weinberger
2012-06-29 15:14 Richard Weinberger
2012-06-30 10:43 ` Artem Bityutskiy
2012-06-30 10:53 ` Richard Weinberger
2012-06-30 11:24 ` Artem Bityutskiy
2012-06-30 14:24 ` Artem Bityutskiy
2012-07-08 11:47 ` Shmulik Ladkani
2012-07-08 12:07 ` Richard Weinberger
2012-07-08 15:11 ` Richard Weinberger
2012-07-09 7:37 ` Shmulik Ladkani
2012-07-09 8:19 ` Richard Weinberger
2012-06-27 15:57 Richard Weinberger
2012-06-23 13:03 Richard Weinberger
2012-06-27 4:20 ` Namjae Jeon
2012-06-27 6:48 ` Nikita V. Youshchenko
2012-06-27 7:17 ` Richard Weinberger
2012-06-18 16:18 UBI Fastmap updates 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=20120802194538.26e2ec98@spider.haslach.nod.at \
--to=richard@nod.at \
--cc=Heinz.Egger@linutronix.de \
--cc=Marius.Mazarel@ugal.ro \
--cc=adrian.hunter@intel.com \
--cc=artem.bityutskiy@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=nyoushchenko@mvista.com \
--cc=shmulik.ladkani@gmail.com \
--cc=tglx@linutronix.de \
--cc=thomas.wucher@linutronix.de \
--cc=tim.bird@am.sony.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).