Messages in this thread | | | Date | Thu, 02 Oct 2014 16:42:47 +0300 | From | Tanya Brokhman <> | Subject | Re: [RFC/PATCH 1/5] mtd: ubi: Read disturb infrastructure |
| |
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
| |