[PATCH] Add quick erase format option
dedekind1 at gmail.com
Tue Aug 31 20:47:23 EDT 2010
you have strong points, but I'm still not entirely convinced.
On Tue, 2010-08-31 at 08:42 +0200, Stefani Seibold wrote:
> > I would like to change the option name so that it would reflect the
> > exact use-case we are creating it for: wiped out flash. So I'd be
> > happier with something like --pristine-flash.
> "Pristine" is not a word which non native speaker have in its
Agree, not very simple word, when I met it in JFFS2 sources, I looked it
up in the dictionary :-)
> Quick-format is the best, because it is exactly what it is
No, it is misleading. If I was a dumb user, I'd be thinking: oh, why I
should do slow format if I can do quick? It is probably like my FAT32
partition formatting in Windows, I always shoos quick format.
This is why I do not like your naming - it encourages to use it, while
my name discourages.
Also, your use-case is new/virgin/pristine/whatever NOR chips, which are
guaranteed to be erased, and I wanted to use option name which reflects
Or --do-not-use-me :-)
> > OK. But did you consider to pre-create the image with ubinize and
> > mkfs.ubifs tools and just flash the raw image in production? This is the
> > fastest possible way.
> This did not work in our NSN transport environment. It would take to
> much time to explain why, because the PCU software managment server is a
> 10 year old application which handles a wide range of transport boards
> in the same way, including the old JFFS2 systems and the new UBIFS based
> > It does assume that if the beginning of the flash contains 0xFFs then it
> > is safe to treat it as erased. Instead, I think you should just trust
> > the user and not even check the beginning of the flash. And this will be
> > also faster.
> Never trust the user. And why should we remove this check? The coast is
> very minimal and it will make live much easier.
Well, this is a good principle, no doubts. But on NAND, it will hurt
performance, because we'll end up with reading whole page. And since
NAND erase is ultra-fast, comparing to NOR, reading whole page will
introduce a noticeable overhead.
IOW, as the maintainer, I have to care about code in general, not only
How about checking only the first and last eraseblocks? It would give
_some_ sanity check at least, with less overhead?
Or, do the check only if this is NOR, but I'm less happy about this
> For example: In our production environment everything is automated by
> scripts, so the software bring up did not know if the flash is already
> erased or not. It is possible that an broken used board is returned into
> the production after it was repaired.
Well, you can check the flash before running ubiformat.
> What you assume is that the user or the scripts does know the status of
> the flash, but this is not true in real production environment, where
> thousands of boards are prepared.
Again, I do not mind to add checks if they are cheap in general, but
this one is not cheap for NAND.
Artem Bityutskiy (Битюцкий Артём)
More information about the linux-mtd