linux-kernel - Re: [PATCH] Add quick erase format option

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1281353344.2332.8.camel@brekeke>
Date:	Mon, 09 Aug 2010 14:29:04 +0300
From:	Artem Bityutskiy <dedekind1@...il.com>
To:	Stefani Seibold <stefani@...bold.net>
Cc:	David Woodhouse <dwmw2@...radead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	Artem Bityutskiy <Artem.Bityutskiy@...ia.com>,
	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>
Subject: Re: [PATCH] Add quick erase format option

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@...bold.net wrote:
> > > From: Stefani Seibold <stefani@...bold.net>
> > > 
> > > 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@...bold.net> 
> > 
> > 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/