04 Jul, 2011

2 commits

  • Switch the rest of direct UBI calls to UBIFS helper functions.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     
  • This patch introduces helper functions for all debugging checks, so instead of
    doing

    if (!(ubifs_chk_flags & UBIFS_CHK_GEN))

    we now do

    if (!dbg_is_chk_gen(c))

    This is a preparation to further changes where the flags will go away, and
    we'll need to only change the helper functions, but the code which utilizes
    them won't be touched.

    At the same time this patch removes 'dbg_force_in_the_gaps()',
    'dbg_force_in_the_gaps_enabled()', and dbg_failure_mode helpers for
    consistency.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     

16 May, 2011

1 commit


03 May, 2011

1 commit

  • Currently UBIFS has a small optimization - it frees write-buffers when it is
    re-mounted from R/W mode to R/O mode. Of course, when it is mounted R/O, it
    does not allocate write-buffers as well.

    This optimization is nice but it leads to subtle problems and complications
    in recovery, which I can reproduce using the integck test. The symptoms are
    that after a power cut the file-system cannot be mounted if we first mount
    it R/O, and then re-mount R/W - 'ubifs_rcvry_gc_commit()' prints:

    UBIFS error (pid 34456): could not find an empty LEB

    Analysis of the problem.

    When mounting R/W, the reply process sets journal heads to buds [1], but
    when mounting R/O - it does not do this, because the write-buffers are not
    allocated. So 'ubifs_rcvry_gc_commit()' works completely differently for the
    same file-system but for the following 2 cases:

    1. mounting R/W after a power cut and recover
    2. mounting R/O after a power cut, re-mounting R/W and run deferred recovery

    In the former case, we have journal heads seeked to the a bud, in the latter
    case, they are non-seeked (wbuf->lnum == -1). So in the latter case we do not
    try to recover the GC LEB by garbage-collecting to the GC head, but we just
    try to find an empty LEB, and there may be no empty LEBs, so we just fail.
    On the other hand, in the former case (mount R/W), we are able to make a GC LEB
    (@c->gc_lnum) by garbage-collecting.

    Thus, let's remove this small nice optimization and always allocate
    write-buffers. This should not make too big difference - we have only 3
    of them, each of max. write unit size, which is usually 2KiB. So this is
    about 6KiB of RAM for the typical case, and only when mounted R/O.

    [1]: Note, currently the replay process is setting (seeking) the journal heads
    to _some_ buds, not necessarily to the buds which had been the journal heads
    before the power cut happened. This will be fixed separately.

    Signed-off-by: Artem Bityutskiy
    Cc: stable@kernel.org

    Artem Bityutskiy
     

20 Sep, 2010

1 commit

  • Commit 2fde99cb55fb9d9b88180512a5e8a5d939d27fec "UBIFS: mark VFS SB RO too"
    introduced regression. This commit made UBIFS set the 'MS_RDONLY' flag in the
    VFS superblock when it switches to R/O mode due to an error. This was done
    to make VFS show the R/O UBIFS flag in /proc/mounts.

    However, several places in UBIFS relied on the 'MS_RDONLY' flag and assume this
    flag can only change when we re-mount. For example, 'ubifs_put_super()'.

    This patch introduces new UBIFS flag - 'c->ro_mount' which changes only when
    we re-mount, and preserves the way UBIFS was originally mounted (R/W or R/O).
    This allows us to de-initialize UBIFS cleanly in 'ubifs_put_super()'.

    This patch also changes all 'ubifs_assert(!c->ro_media)' assertions to
    'ubifs_assert(!c->ro_media && !c->ro_mount)', because we never should write
    anything if the FS was mounter R/O.

    All the places where we test for 'MS_RDONLY' flag in the VFS SB were changed
    and now we test the 'c->ro_mount' flag instead, because it preserves the
    original UBIFS mount type, unlike the 'MS_RDONLY' flag.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     

17 Sep, 2010

1 commit

  • The R/O state may have various reasons:

    1. The UBI volume is R/O
    2. The FS is mounted R/O
    3. The FS switched to R/O mode because of an error

    However, in UBIFS we have only one variable which represents cases
    1 and 3 - 'c->ro_media'. Indeed, we set this to 1 if we switch to
    R/O mode due to an error, and then we test it in many places to
    make sure that we stop writing as soon as the error happens.

    But this is very unclean. One consequence of this, for example, is
    that in 'ubifs_remount_fs()' we use 'c->ro_media' to check whether
    we are in R/O mode because on an error, and we print a message
    in this case. However, if we are in R/O mode because the media
    is R/O, our message is bogus.

    This patch introduces new flag - 'c->ro_error' which is set when
    we switch to R/O mode because of an error. It also changes all
    "if (c->ro_media)" checks to "if (c->ro_error)" checks, because
    this is what the checks actually mean. We do not need to check
    for 'c->ro_media' because if the UBI volume is in R/O mode, we
    do not allow R/W mounting, and now writes can happen. This is
    guaranteed by VFS. But it is good to double-check this, so this
    patch also adds many "ubifs_assert(!c->ro_media)" checks.

    In the 'ubifs_remount_fs()' function this patch makes a bit more
    changes - it fixes the error messages as well.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     

15 Sep, 2009

1 commit


10 Sep, 2009

1 commit

  • At the moment UBIFS print large and scary error messages and
    flash dumps in case of nearly any corruption, even if it is
    a recoverable corruption. For example, if the master node is
    corrupted, ubifs_scan() prints error dumps, then UBIFS recovers
    just fine and goes on.

    This patch makes UBIFS print scary error messages only in
    real cases, which are not recoverable. It adds 'quiet' argument
    to the 'ubifs_scan()' function, so the caller may ask 'ubi_scan()'
    not to print error messages if the caller is able to do recovery.

    Signed-off-by: Artem Bityutskiy
    Reviewed-by: Adrian Hunter

    Artem Bityutskiy
     

21 Mar, 2009

1 commit


17 Feb, 2009

1 commit

  • Trivial cleanup, list_del(); list_add{,_tail}() is equivalent
    to list_move{,_tail}(). Semantic patch for coccinelle can be
    found at www.cccmz.de/~snakebyte/list_move_tail.spatch

    Signed-off-by: Eric Sesterhenn
    Signed-off-by: Artem Bityutskiy

    Eric Sesterhenn
     

13 Aug, 2008

2 commits

  • Increment the commit number at the beginnig of the commit, instead
    of doing this after the commit. This is needed for further
    optimizations.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     
  • UBI transparently handles write errors by automatically copying
    and remapping the affected eraseblock. If UBI is unable to do
    that, for example its pool of eraseblocks reserved for bad block
    handling is empty, then the error is propagated to UBIFS. UBIFS
    must protect the media from falling into an inconsistent state
    by immediately switching to read-only mode. In the case of log
    updates, this was not being done.

    Signed-off-by: Adrian Hunter

    Adrian Hunter
     

15 Jul, 2008

1 commit