All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Hunter <ext-adrian.hunter@nokia.com>
To: ext Nancy <nancydreaming@gmail.com>
Cc: linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: UBI: badblock management confusion!
Date: Mon, 28 Apr 2008 10:57:36 +0300	[thread overview]
Message-ID: <48158370.9090001@nokia.com> (raw)
In-Reply-To: <bae050c10804250508g68df553qcce03bb6551aa5c5@mail.gmail.com>

ext Nancy wrote:
> On Fri, Apr 25, 2008 at 6:47 PM, Adrian Hunter
> <ext-adrian.hunter@nokia.com> wrote:
>> ext Nancy wrote:
>>> Hi all,
>>>        I don't quite understand the UBI badblock management unit.
>>> But I think there must be something wrong, or I take a wrong operation.
>>>        Please follow my test below:
>>>
>>> # ubiformat /dev/mtd5
>>> ubiformat: mtd5 (NAND), size 536870912 bytes (512.0 MiB), 262144
>> eraseblocks of
>>> 262144 bytes (256.0 KiB), min. I/O size 2048 bytes
>>> libscan: scanning eraseblock 2047 -- 100 % complete
>>> ubiformat: 2045 eraseblocks have valid erase counter, mean value is 23
>>> ubiformat: bad eraseblocks: 10, 40, 84
>>> ubiformat: formatting eraseblock 2047 -- 100 % complete
>>>
>>> # modprobe ubi mtd=5
>>> UBI: physical eraseblock size:   262144 bytes (256 KiB)
>>> UBI: logical eraseblock size:    258048 bytes
>>> UBI: smallest flash I/O unit:    2048
>>> UBI: VID header offset:          2048 (aligned 2048)
>>> UBI: data offset:                4096
>>> UBI: attached mtd5 to ubi0
>>> UBI: MTD device name:            "NAND VFAT partition"
>>> UBI: MTD device size:            512 MiB
>>> UBI: number of good PEBs:        2045
>>> UBI: number of bad PEBs:         3
>>> UBI: max. allowed volumes:       128
>>> UBI: wear-leveling threshold:    256
>>> UBI: number of internal volumes: 1
>>> UBI: number of user volumes:     0
>>> UBI: available PEBs:             2021
>>> UBI: total number of reserved PEBs: 24
>>> UBI: number of PEBs reserved for bad PEB handling: 20
>>> UBI: max/mean erase counter: 38/24
>>> UBI: background thread "ubi_bgt0d" started, PID 233
>>>
>>>
>> ***************************************************************************
>>> I'm going to make one big volume which take all available space this ubi
>>> device has.
>>>
>>> I think the volume size should be equal to
>>> (total number of PEB this ubi device has - total number of reserved PEBs)
>> \
>>> * LEB size
>>> In this case, it should be : (2048-24) * 258048 bytes
>>>
>>> But that is not what UBI count.
>>> UBI think the volume size
>>> = (number of good PEBs - total number of reserved PEBs) * LEB size
>>>
>>> Q: Number of bad PEBs at initialization are not included in resered for
>> bad
>>> PEBs handling. That mean there should never has badblocks overflow issue
>>> happen. What a good idea! But is there really a possible way to implement
>> this
>>> idea?
>>>
>> It does work.
>>
>>
>>>   Suppose there's only one volume take all the ubi device space, there's
>> no
>>> badblocks at the very beginning. The user does never shut down the device
>> but
>>> hibernate for a long time. Then, suppose there is 3 badblocks and the
>> volume
>>> just full of data. No space left. Then reboot the device, beside the 3
>> badblocks
>>> which used to be count in reserved PEBs, now be seperate from the reserved
>> PEBs,
>>> But there's no space, reserved PEB will fail.
>>>
>> No, there will just be a warning - as shown in your test:
>>
>>
>>        UBI warning: ubi_eba_init_scan: cannot reserve enough PEBs for bad
>> PEB handling, reserved 19, need 20
>>
>> There *would* be problem if you marked 21 bad and only 20 were reserved for
>> bad block handling.
>>
>>
>>>   The following test showes even the volume data is blank, there still
>> comes
>>> problem.
>>>   Is it an UBI bug or my wrong operation?
>>>
>> Your wrong operation.
>>
>>
>>
>>>   Thanks for your notice about it!
>>>
>> ****************************************************************************
>>> # ubimkvol /dev/ubi0 -n 0 -N vfat -s 509292KiB
>>> Volume ID 0, size 2021 LEBs (521515008 bytes, 497.4 MiB), LEB size
>>> 258048 bytes (252.0 KiB), dynamic, name "vfat", alignment 1
>>> # rmmod ubi
>>> UBI: mtd5 is detached from ubi0
>>>
>>>
>> *****************************************************************************
>>> "markbadblock" is a tool I force to mark a block bad manually, just for
>> test
>> *****************************************************************************
>>> # markbadblock -l 17 /dev/mtd5
>>> Block size 262144, page size 2048, OOB size 64
>>> mark block 17 to be badblock done
>>>
>>> # modprobe ubi mtd=5
>>> UBI: physical eraseblock size:   262144 bytes (256 KiB)
>>> UBI: logical eraseblock size:    258048 bytes
>>> UBI: smallest flash I/O unit:    2048
>>> UBI: VID header offset:          2048 (aligned 2048)
>>> UBI: data offset:                4096
>>> UBI warning: ubi_eba_init_scan: cannot reserve enough PEBs for bad PEB
>>> handling, reserved 19, need 20
>>> UBI: attached mtd5 to ubi0
>>> UBI: MTD device name:            "NAND VFAT partition"
>>> UBI: MTD device size:            512 MiB
>>> UBI: number of good PEBs:        2044
>>> UBI: number of bad PEBs:         4
>>> UBI: max. allowed volumes:       128
>>> UBI: wear-leveling threshold:    256
>>> UBI: number of internal volumes: 1
>>> UBI: number of user volumes:     1
>>> UBI: available PEBs:             0
>>> UBI: total number of reserved PEBs: 2044
>>> UBI: number of PEBs reserved for bad PEB handling: 19
>>> UBI: max/mean erase counter: 39/24
>>> UBI: background thread "ubi_bgt0d" started, PID 263
>>> # modprobe ubifs
>>>
>>> # mount -t ubifs ubi0:ubifs /mnt/1
>>> UBIFS error (pid 293): ubifs_get_sb: cannot open "ubi0:ubifs", error -19
>>>
>> You named the volume "vfat" (-N option of ubimkvol), but you are trying
>> to mount a volume named "ubifs" i.e. should be:
>>
>>        mount -t ubifs ubi0:vfat /mnt/1
> 
> Oh, thank you for ponting out my mistake!
> You mean UBI admit the amount of current badblocks are part of
> reserved PEBs, right?

Not exactly.  It is just that UBI does not mind if there are not enough
PEBs to meet the number desired for bad-block handling.

> If the answer is yes, then the volume size I'm goting to create should
> be equal to
> 
> (total number of PEB this ubi device has - total number of reserved
> PEBs) * LEB size
> 
> not what UBI think:
> (number of good PEBs - total number of reserved PEBs) * LEB size
> 
> Am I right?

I am not sure what you are trying to achieve.  You can always use
the -m option of ubimkvol to set volume size to maximum available size.

  parent reply	other threads:[~2008-04-28  8:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-25  6:54 UBI: badblock management confusion! Nancy
2008-04-25 10:47 ` Adrian Hunter
2008-04-25 12:08   ` Nancy
2008-04-25 12:12     ` Nancy
2008-04-28  7:59       ` Adrian Hunter
2008-04-28 11:45         ` Nancy
2008-04-28  7:57     ` Adrian Hunter [this message]
2008-04-28 11:50       ` Nancy
2008-04-28 11:58         ` Adrian Hunter
2008-04-28 12:24           ` Nancy
2008-04-28 14:08             ` Adrian Hunter
2008-04-29  2:06               ` Nancy
2008-04-30  9:14                 ` Adrian Hunter
2008-05-04  1:42                   ` Nancy

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=48158370.9090001@nokia.com \
    --to=ext-adrian.hunter@nokia.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=nancydreaming@gmail.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 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.