Am 02.10.2014 15:42, schrieb Tanya Brokhman: > 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. The question is, do we really need all this values on-flash? You could create a simple sysfs or ioctl() interface to pass these values to userspace. Then you can hack up an userspace daemon which monitors the counters and triggers a check if needed. The daemon can also store the counter into a flat file. If think you don't need exact counters, there it does not hurt if the daemon does not store the most current values at a power cut. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
