1. 03 5月, 2011 2 次提交
    • A
      UBIFS: seek journal heads to the latest bud in replay · 52c6e6f9
      Artem Bityutskiy 提交于
      This is the second fix of the following symptom:
      
      UBIFS error (pid 34456): could not find an empty LEB
      
      which sometimes happens after power cuts when we mount the file-system - UBIFS
      refuses it with the above error message which comes from the
      'ubifs_rcvry_gc_commit()' function. I can reproduce this using the integck test
      with the UBIFS power cut emulation enabled.
      
      Analysis of the problem.
      
      Currently UBIFS replay seeks the journal heads to the last _replayed_ bud.
      But the buds are replayed out-of-order, so the replay basically seeks journal
      heads to the "random" bud belonging to this head, and not to the _last_ one.
      
      The result of this is that the GC head may be seeked to a full LEB with no free
      space, or very little free space. And 'ubifs_rcvry_gc_commit()' tries to find a
      fully or mostly dirty LEB to match the current GC head (because we need to
      garbage-collect that dirty LEB at one go, because we do not have @c->gc_lnum).
      So 'ubifs_find_dirty_leb()' fails and we fall back to finding an empty LEB and
      also fail. As a result - recovery fails and mounting fails.
      
      This patch teaches the replay to initialize the GC heads exactly to the latest
      buds, i.e. the buds which have the largest sequence number in corresponding
      log reference nodes.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Cc: stable@kernel.org
      52c6e6f9
    • A
      UBIFS: do not free write-buffers when in R/O mode · b50b9f40
      Artem Bityutskiy 提交于
      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: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Cc: stable@kernel.org
      b50b9f40
  2. 27 4月, 2011 5 次提交
  3. 26 4月, 2011 25 次提交
  4. 24 4月, 2011 8 次提交