1. 02 May, 2011 1 commit
    • Artem Bityutskiy's avatar
      UBIFS: do not free write-buffers when in R/O mode · b50b9f40
      Artem Bityutskiy authored
      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: default avatarArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Cc: stable@kernel.org
      b50b9f40
  2. 27 Apr, 2011 2 commits
  3. 26 Apr, 2011 15 commits
  4. 25 Apr, 2011 13 commits
  5. 24 Apr, 2011 9 commits