Add quick erase format option
in [Kernel]
|
Prev: regulator: lp3971 - remove unnecessary ret value checking in lp3971_i2c_write()
Next: regulator: lp3971 - remove unnecessary ret value checking in lp3971_i2c_write()
From: David Woodhouse on 9 Aug 2010 04:40 On Mon, 2010-08-09 at 09:25 +0100, stefani(a)seibold.net wrote: > From: Stefani Seibold <stefani(a)seibold.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(a)seibold.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. -- David Woodhouse Open Source Technology Centre David.Woodhouse(a)intel.com Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stefani Seibold on 9 Aug 2010 05:00 Am Montag, den 09.08.2010, 09:37 +0100 schrieb David Woodhouse: > On Mon, 2010-08-09 at 09:25 +0100, stefani(a)seibold.net wrote: > > From: Stefani Seibold <stefani(a)seibold.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(a)seibold.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. 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. - Stefani -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Artem Bityutskiy on 9 Aug 2010 07:30 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(a)seibold.net wrote: > > > From: Stefani Seibold <stefani(a)seibold.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(a)seibold.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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stefani Seibold on 9 Aug 2010 10:00
Am Montag, den 09.08.2010, 14:29 +0300 schrieb 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(a)seibold.net wrote: > > > > From: Stefani Seibold <stefani(a)seibold.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(a)seibold.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. > I was never able to mount a UBIFS without a previous ubimkvol, despite the flash is already erased. Here are my timing results mounting an already erased flash as UBIFS: ubiattach /dev/ubi_ctrl -m 5 -d 1 --> 2.023s ubimkvol /dev/ubi1 -m -N flash --> 294.574s mount -t ubifs -o sync ubi1:flash /mnt --> 0.221s And this are the timing results when i do an ubiformat first: ubiformat /dev/mtd5 --> 299.111s ubiattach /dev/ubi_ctrl -m 5 -d 1 --> 0.129s ubimkvol /dev/ubi1 -m -N flash --> 1.784s mount -t ubifs -o sync ubi1:flash /mnt --> 0.220s And this are the results with my patched version of the ubiformat tool using an already erased flash: ubiformat /dev/mtd5 -E --> 5.475s ubiattach /dev/ubi_ctrl -m 5 -d --> 0.130s ubimkvol /dev/ubi1 -m -N flash --> 1.699s mount -t ubifs -o sync ubi1:flash /mnt --> 0.220s As you can see this is 296.818s vs. 7.524 or 40 times faster. Maybe i do something wrong, but i have no idea. Can u explain it to me? BTW: The flash is a 128 MB CFI AMD NOR and the size of the mtd5 partition is 47 MB. > 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. > No, we only initialize the flash, mount it as UBIFS and copy files. > 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. > This patch assumes nothing, it will skip the erase of the PEB if all bytes in the EC header are 0xff. I think this is safer than your suggestion. - Stefani -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |