Re: [PATCH] Add quick erase format option

[Artem Bityutskiy]

On Mon, 2010-08-09 at 10:52 +0200, Stefani Seibold wrote:
> Am Montag, den 09.08.2010, 09:37 +0100 schrieb David Woodhouse:
> > On Mon, 2010-08-09 at 09:25 +0100, stefani@xxxxxxxxxxx wrote:
> > > From: Stefani Seibold <stefani@xxxxxxxxxxx>
> > > 
> > > This patch add a quick format option which skips erasing of already erased
> > > flash blocks. This is useful for first time production environments where
> > > the flash arrived erased.
> > > 
> > > Signed-off-by: Stefani Seibold <stefani@xxxxxxxxxxx> 
> > 
> > This scares me, given the lengths we had to go to in JFFS2 to cope with
> > blocks which *look* like they're erased, but which actually start losing
> > data as soon as you start writing to them because the erase didn't
> > complete.
> > 
> 
> I know the drawback. This is why it is only an option which must be
> enabled. And in most use cases there is a subsequent ubimkvol, which
> will fail if the flash is not correct initialized.
> 
> Flash are normally delivered erased. So this save in our production
> environment (Nokia Siemens Networks) about 5 minutes per device (256 MB
> NOR CFI Flash).
> 
> The old JFFS2 was very fast to install the first time on a flash, it was
> only a simple mount of the MTD partition. 

Not sure what you do, but both UBI and UBIFS auto-format flash if it is
empty, and attaching empty flash should be very fast.

But yes, the first volume creation ioctl will block until everything is
erased, although this is just an implementation issue and in theory,
fixable.

> Which the quick format option i have now only a slightly first time
> installation overhead compared to JFFS2. Without this option the
> overhead is more than 5 minutes.

Are you flashing an UBI image in production? Then what you can do if you
want to be faster is to flash only the blocks which contain image date,
and leave the rest intact, UBI will erase them and write EC header to
them when you first boot the device.

So I think it is better to add an --pristine-flash option, or something
like this. In this case ubiformat won't erase anything, and will assume
everything is 0xFFed without reading. This should be faster and I think
is better to do.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/