On 10/2/2014 4:24 PM, Richard Weinberger wrote:
Am 02.10.2014 14:50, schrieb Tanya Brokhman:
Consider the case where you have a board with a fastmap enabled bootloader and
a Linux OS.
The bootloader does a fastmap attach and boots the kernel from UBI and the
kernel it self has the rootfs
on UBI too. If you install a new kernel with your changes applied it will write
the fastmap in a different
format and the bootloader will fail badly. In worst case the board bricks, in
best case the bootloader can fall back
to scanning mode but it will be slow and the customer unhappy.
Ok, I understand the problem now. I wanted to discuss a possible solution
before implementing it:
We have a "fastmap version" in fm_sb. At the moment UBI_FM_FMT_VERSION = 1 and
any other is not supported. We can use that; Add another fm version
(UBI_FM_FMT_VERSION_RD = 2) and
then decide according to it. Meaning, if during attach process we find fm
superblock we check it's version, if it's != UBI_FM_FMT_VERSION_RD, we fall
back to full scan. The next
fastmap will be written with the new layout (and new version number) so second
boot will attach from fastmap without any issues.
Yes, if we change the fastmap on-disk layout we need to change
UBI_FM_FMT_VERSION.
Then other fastmap implementations will notice the change and can hopefully
recover.
Implementations which do not evaluate UBI_FM_FMT_VERSION deserve breaking. ;-)
good. will work on the fix and upload a new set when ready&tested.
That said, I'll not block a layout change but we have to be sure that it is
*really* needed.
In order to support read-disturb, I think its really needed. There is no
other way to save read counter per PEB but in fastmap.
I'm currently heavily working on fastmap and my local queue with fastmap fixes
keeps growing.
If I find a horror bug which needs a fastmap layout change I want to change the
layout only once,
not twice.
How do you test all of your fastmap fixes? Some of them are not easy to
reproduce (the pq saving for example). Besides heavy stability testing,
I was testing my changes manually by a lot of dbg prints in the code and
analyzing the logs manually. Not the optimal way....
Thanks,
//richard
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Thanks,
Tanya Brokhman
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
