From: Artem Bityutskiy <dedekind@infradead.org>
To: John Smith <john@arrows.demon.co.uk>
Cc: linux-mtd@lists.infradead.org
Subject: Re: UBI: Cannot create static volumes when FTL is enabled
Date: Sat, 05 May 2007 14:39:29 +0300 [thread overview]
Message-ID: <1178365169.3659.76.camel@sauron> (raw)
In-Reply-To: <Pine.LNX.4.33.0705042249130.30496-100000@arrows.demon.co.uk>
On Fri, 2007-05-04 at 23:22 +0100, John Smith wrote:
> Probably not a major bug, but here it is....
>
> I have a slightly muddled kernel using MTD and UBI from a recent snapshot
> from kernel.org, and the rest of the kernel from a derivative of 2.6.18.
>
> I accidentally enabled the CONFIG_FTL as well as MTD and UBI.
>
> When trying to create a static UBI volume with the command
>
> # ubimkvol -d 0 -n 1 -N ubi-volume --type=static -s 123000
>
> I trigger a kernel stack dump. It arises from the ubi_assert
>
> ubi_assert(vol->vol_type != UBI_STATIC_VOLUME);
>
> in function ubi_eba_read_leb() of file drivers/mtd/ubi/eba.c
Yeah, you have found a flaw. We actually assume that mtd devices are
emulated _only_ for dynamic volumes, but we do not disable the MTD
device emulation for static volumes. This should we fixed.
The reason why only dynamic volumes may have emulated MTD devices is
that they have "stable" size. I mean, if you create dynamic volume of
size N, you can always read N bytes from it. And it does not depend on
how many bytes of data you have on them.
In case of static volumes the situation is different. When you create an
empty static volume, it contains no data, and a read operation returns
EOF immediately. Then you write put some data to it using the "volume
update" operation. In this case you'll be able to read that amount of
data back.
Here is an example:
1. Create static volume A of size Sa.
2. Create dynamic volume B of size Sb.
3. Read whole A - 0 bytes are read.
4. Read whole B - Sb bytes are read, all of them contain 0xFFs.
5. Update A with Xa bytes of data (Xa <= Sa).
6. Update B with Xb bytes of data (Xb <= Sb).
7. Read whole A - Sa bytes are read.
8. Read whole B - Xb bytes are read.
See the difference in semantics? In case of dynamic volumes we always
read Sb bytes. If there is only Xb bytes of data, the rest will be 0xFF
bytes.
So you see that dynamic volumes are mapped to the MTD device model quite
nicely: mtd device size = volume size.
Size of static volumes depends on how much data you put there. And since
MTD infrastructure assumes that MTD device sizes are stable, there is no
good and nice way to emulate MTD devices on top of static volumes,
unless MTD subsystem is somehow re-designed.
But anyway, you have found a bug. I am going to disable MTD device
emulation for static volumes.
Thanks.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
next prev parent reply other threads:[~2007-05-05 11:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-04 22:22 UBI: Cannot create static volumes when FTL is enabled John Smith
2007-05-05 11:39 ` Artem Bityutskiy [this message]
2007-05-05 11:54 ` Artem Bityutskiy
2007-05-05 13:40 ` Artem Bityutskiy
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=1178365169.3659.76.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