[lkml]   [2012]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: UBI fastmap updates
    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

     \ /
      Last update: 2012-08-02 19:41    [W:0.025 / U:9.296 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site