From: Artem Bityutskiy <dedekind@infradead.org>
To: John Smith <john@arrows.demon.co.uk>
Cc: linux-mtd@lists.infradead.org
Subject: Re: UBI: Incorrect initial value for ubi->avail_pebs
Date: Tue, 17 Jul 2007 11:29:03 +0300 [thread overview]
Message-ID: <1184660943.3531.141.camel@sauron> (raw)
In-Reply-To: <Pine.LNX.4.33.0707141836500.19907-100000@arrows.demon.co.uk>
Hi,
On Sat, 2007-07-14 at 19:08 +0100, John Smith wrote:
> I suggest that the initial calculation of ubi->avail_pebs
> is incorrect. But perhaps it is intentionally done this way.
>
> A number of erase blocks, controlled by CONFIG_MTD_UBI_BEB_RESERVE,
> are reserved for handling bad blocks. The number of actual bad blocks
> are also reserved. I think it would be better if the actual bad blocks
> were taken from the CONFIG_MTD_UBI_BEB_RESERVE allocation.
Yeah, we always reserve this configurable percent of good eraseblocks in
case we have more bad eraseblock in future
>
> In more detail, during scan time the calculation of ubi->avail_pebs
> goes roughly:
>
> /* in attach_by_scanning() */
> ubi->good_peb_count = ubi->peb_count - ubi->bad_peb_count;
>
> /* in ubi_read_volume_table() */
> ubi->avail_pebs = ubi->good_peb_count;
>
> /* in init_volumes() */
> reserved_pebs = sum of volume sizes
> reserved_pebs += size of layout volume
> ubi->avail_pebs -= reserved_pebs
>
> /* in ubi_wl_init_scan() */
> #define WL_RESERVED_PEBS 1
> ubi->avail_pebs -= WL_RESERVED_PEBS
>
> /* In calculate_reserved() */
> ubi->beb_rsvd_level = ubi->good_peb_count/100;
> ubi->beb_rsvd_level *= CONFIG_MTD_UBI_BEB_RESERVE;
>
> /* in ubi_eba_init_scan() */
> ubi->beb_rsvd_pebs = min(ubi->beb_rsvd_level, ubi->avail_pebs)
> ubi->avail_pebs -= ubi->beb_rsvd_pebs;
>
> The effect is that existing bad blocks on the device are allocated
> from the budget of blocks for data rather than from the budget of
> blocks for bad blocks.
When a NAND device is shipped it already has some bad eraseblocks. The
number of them is unknown, but they usually guarantee that the number
does not exceed some limit. I just wanted to ensure we always have a
reserved pool which does not depend on the number of already existing
bad eraseblocks. But yes, I can believe that this approach may be too
simple and cause troubles.
>
> To fix, I suggest that in ubi_read_volume_table() in vtbl.c the
> initial value of ubi->avail_pebs should be set by
>
> ubi->avail_pebs = ubi->peb_count ;
>
> and for consistancy, the beb_rsvd_level should come from
>
> ubi->beb_rsvd_level = ubi->peb_count/100;
> ubi->beb_rsvd_level *= CONFIG_MTD_UBI_BEB_RESERVE;
Well, may be. Provide some arguments against current approach please.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
prev parent reply other threads:[~2007-07-17 8:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-14 18:08 UBI: Incorrect initial value for ubi->avail_pebs John Smith
2007-07-17 8:29 ` Artem Bityutskiy [this message]
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=1184660943.3531.141.camel@sauron \
--to=dedekind@infradead.org \
--cc=john@arrows.demon.co.uk \
--cc=linux-mtd@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox