lkml.org 
[lkml]   [2012]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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:1.400 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site