From: Holger Brunck <holger.brunck@keymile.com>
To: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Anatolij Gustschin <agust@denx.de>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Norbert van Bolhuis <nvbolhuis@aimvalley.nl>
Subject: Re: [PATCH 0/7] UBIFS: fix recovery on CFI NOR
Date: Wed, 02 Feb 2011 16:21:07 +0100 [thread overview]
Message-ID: <4D497663.3070806@keymile.com> (raw)
In-Reply-To: <1296634917-19335-1-git-send-email-dedekind1@gmail.com>
Hi Artem,
Artem Bityutskiy wrote:
> From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
>
> Hi,
>
> here is the patch-set against the latest Linux kernel (e.g. 2.6.38-rc3)
> which should fix CFI NOR flash recovery.
>
> The previous attempt was not entirely successful - it broke backward
> compatibility and was reverted:
>
> http://marc.info/?l=linux-kernel&m=129631939419818&w=2
>
> This patch-set goes the following way:
> 1. Incorporates the notion of 'writebufsize' into UBI and UBIFS as
> 'max_write_size', because using term write-buffer would be confusing, as
> UBIFS has its own write-buffers.
> 2. Changes UBIFS write-buffer and makes it of 'max_write_size', instead of
> 'min_io_size'. This presumably leads to better performance because we
> accumulate more data and write them in larger chunks and faster.
> And we do not waste space when synchronizing UBIFS write-buffers because we
> write only the used amount of bytes aligned to 'min_io_size'. So this is an
> improvement.
> 3. Tweak UBIFS recovery and make it aware of the fact that we can write in
> chunks larger than 'min_io_size'. Namely, we can write in 'max_write_size'
> chunks.
>
> Could you guys please test this WRT power cuts and let me know if it solves the
> issues?
>
I have tested this patches on an ppc82xx and ppc83xx boards with different NOR
flashes with different writebuffers (64 and 1024 bytes) and check wether I am
able to mount previous created UBIFS partitions and this works without any
problems. So the incompatbility seems to be solved. Additionaly I tried it on a
NAND based system and this runs also without problems.
But I am not able to check for power cut problems. We see some problems in the
combination with UBI and NOR flashes with large writebuffers (1024). But
currently we suspect some CFI driver problems see ML entry from an colleague:
http://lists.infradead.org/pipermail/linux-mtd/2011-February/033849.html
Another question related to the writebuffer adaptions for UBI. What should be
done during creation of ubi images on a host system with ubinize if your patches
find their way in the "standard" UBI/UBIFS code. In the past we had "only" NOR
flashes with a writebuffer of 64 bytes and we create our ubi images without the
-m parameter during executing ubinize for the esw image. Now we got a new flash
with writebuffer = 1024. Whats the way forward in the future? Is it ok to omit
the "-m" parameter or do we have to create the images with "-m 64" or "-m 1024"?
Best regards
Holger
next prev parent reply other threads:[~2011-02-02 15:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-02 8:21 [PATCH 0/7] UBIFS: fix recovery on CFI NOR Artem Bityutskiy
2011-02-02 8:21 ` [PATCH 1/7] UBI: incorporate maximum write size Artem Bityutskiy
2011-02-02 8:21 ` [PATCH 2/7] UBIFS: " Artem Bityutskiy
2011-02-02 8:21 ` [PATCH 3/7] UBIFS: introduce write-buffer size field Artem Bityutskiy
2011-02-02 8:21 ` [PATCH 4/7] UBIFS: use max_write_size for write-buffers Artem Bityutskiy
2011-02-02 8:21 ` [PATCH 6/7] UBIFS: amend commentaries in io.c to match new situation Artem Bityutskiy
2011-02-02 8:21 ` [PATCH 7/7] UBIFS: use max_write_size during recovery Artem Bityutskiy
2011-02-02 12:48 ` [PATCH 0/7] UBIFS: fix recovery on CFI NOR Anatolij Gustschin
2011-02-02 15:21 ` Holger Brunck [this message]
2011-02-02 17:16 ` Artem Bityutskiy
2011-02-03 9:01 ` Holger Brunck
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=4D497663.3070806@keymile.com \
--to=holger.brunck@keymile.com \
--cc=agust@denx.de \
--cc=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=nvbolhuis@aimvalley.nl \
/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