Static UBI volumes and ubiupdatevol ?

[Ricard Wanderlof]

On Thu, 16 Dec 2010, Artem Bityutskiy wrote:

> > Using 'static' UBI volumes seems to be the preferred way of creating read 
> > only file systems.
> 
> No, I think the _original_ idea behind static volumes was storing some
> important r/o blobs there without any FS. So UBI static volumes simplify
> this by making the volume size being = the contents size, even if the
> contents size is not multiple of LEB size, and static volumes also
> protect the data with CRC-32.

That's good news, because that's what exactly what I'd need.

> But UBIFS has its own CRC32 protection, so does not need UBI static
> volume services.
> [...] 
> All eraseblocks are protected with CRC-32. Fist time the static volume
> is openend, it is checked. See the 'ubi_check_volume()' function. It is
> also checked after it has been updated.

The thing is, I'd like to be able to checksum, or otherwise verify, a 
couple of read-only partitions on the flash _before_ attempting to boot 
Linux. No point in trying to boot Linux if the kernel or the root file 
system is not intact. So although it is nice that UBI verifies static 
volumes during attach, and UBIFS during mount, it is really too late as I 
need to do this in the boot loader.

Of course, extending the bootloader to be able to verify UBI volumes is 
probably doable. I could then use cramfs, squashfs or similar for the root 
file system, with gluebi, and use the static volume UBI CRC32 for 
verification by the bootloader. Makeing the boot loader understand UBIFS I 
think would be too much work.

>> With a system based on mtd+jffs2 it is actually possible to reflash the
>> partition with the [read only] root file system on it without unmounting,
>> as long as no accesses are made to the physical flash during the rewrite
>> or afterwards. In other words, immediately after reflashing the system
>> must be rebooted.
> The same with UBIFS - we never write when we are mounted R/O. There are
> many ubifs_assert()s to check this as well.

... but UBI might still do writes during the course of scrubbing I guess, 
unless ...

> [ ... ] you need to make sure all the backgound stuff like moving and 
> eraseing eraseblocs is done before doing this by doing fsync() on your 
> /dev/ubiX_Y device (UBI volume character device), see the 
> 'vol_cdev_fsync()' function. Ah, and of course you need to sync UBIFS 
> before this.

That would be no problem, it is basically the same stuff we need to do 
with JFFS2 before reflashing.

> >  so it is possible to use a 
> > simple checksum to verify data integrity.
> 
> You can do this with UBIFS I think, did not try though.

What I meant was 'a simple checksum on the raw mtd partition', which can't 
work with UBIFS as the UBI erase counters etc can change over time as a 
result of scrubbing.

I guess I could read from the /dev/ubix_y device to just get the raw UBIFS 
data which shouldn't change even in the event of scrubbing? Or should I 
use gluebi to get both a raw mtd partition corresponding to the raw UBIFS 
data, as well as using UBIFS (on /dev/ubix_y) for the file system?

> The difference between JFFS2 and UBIFS is that JFFS2 cannot distinguish
> between nodes corrupted because of power cuts, and nodes corrupted
> because something bad happened to the flash. UBIFS does better job here
> - it recovers only from errors which could possibly be caused by power
> cuts, and it switches to R/O mode for other errors.
> [...]
> Just call sync(), then fsync on the UBI volume, and you won't have
> background processes if there is not I/O.
>
> Be beware, even reading from UBIFS can cause scrubbing in UBI.

That's very good. My basic problem though is still that I need to verify 
the integrity before booting, although it is very nice that the file 
system can detect errors during mount. With JFFS2 there's always a 
nagging idea that errors will go undetected and we won't notice until a 
file is missing or contains zeros.

I often get complaints from other developers in our company saying "can't 
we suppress these 'jffs2 crc error' messages if they don't actually 
indicate a failure. My answer is always a) We don't know if they indicate 
a failure or not and b) Since mostly they are harmless, come back when you 
have found that a file has disappeared from the file system or other file 
problem. So far no one has come back with any complaints referring to b).

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30