On 08/02/2012 09:45 AM, Artem Bityutskiy wrote: > Richard, > > On Thu, 2012-08-02 at 18:32 +0200, Richard Weinberger wrote: >>> This should not happen. Fastmap should _reserve_ enough of PEBs for it >>> to operate. It should always find the PEB to write. >> >> What is the benefit? >> IOW what is wrong with the current approach? > > Several reasons. The main is: fastmap will start consuming PEBs reserved > for volumes when the amount of available PEBs is just enough to map all > LEBs. This will break UBI liability.
I'm don't understand what "UBI liability" is. Can you please clarify? What breaks if the PEBs get consumed? > >> Why? >> If everything goes wrong, fastmap makes sure that no fastmap is on >> flash. >> In case of a powercut we fall back to scanning mode. >> R/O mode is overkill IMHO. > > So can I interpret this the following way. Not only fastmap give no > guarantees that it exists after an unclean reboot, it does not even give > guarantees that it exists after a clean reboot. > > Unless I am confused, the fastmap design is over-simplified. Fastmap is an optimization. Maybe I'm missing something, but I'm not sure why, if the optimization stopped working, you would want to reduce the functionality of the file system. ============================= Tim Bird Architecture Group Chair, CE Workgroup of the Linux Foundation Senior Staff Engineer, Sony Network Entertainment ============================= -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
