15 Sep, 2009

2 commits


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
     

05 Jul, 2009

3 commits


08 Jun, 2009

1 commit

  • UBIFS uses timers for write-buffer write-back. It is not
    crucial for us to write-back exactly on time. We are fine
    to write-back a little earlier or later. And this means
    we may optimize UBIFS timer so that it could be groped
    with a close timer event, so that the CPU would not be
    waken up just to do the write back. This is optimization
    to lessen power consumption, which is important in
    embedded devices UBIFS is used for.

    hrtimers have a nice feature: they are effectively range
    timers, and we may defind the soft and hard limits for
    it. Standard timers do not have these feature. They may
    only be made deferrable, but this means there is effectively
    no hard limit. So, we will better use hrtimers.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     

26 Mar, 2009

1 commit

  • Now UBIFS is supported by u-boot. If we ever decide to change the
    media format, then people will have to upgrade their u-boots to
    mount new format images. However, very often it is possible to
    preserve R/O forward-compatibility, even though the write
    forward-compatibility is not preserved.

    This patch introduces a new super-block field which stores the
    R/O compatibility version.

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

    Artem Bityutskiy
     

16 Mar, 2009

1 commit


08 Mar, 2009

1 commit


29 Jan, 2009

2 commits

  • This UBIFS feature has never worked properly, and it was a mistake
    to add it because we simply have no use-cases. So, lets still accept
    the fast_unmount mount option, but ignore it. This does not change
    much, because UBIFS commit in sync_fs anyway, and sync_fs is called
    while unmounting.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     
  • - preserve the idx_gc list - it will be needed in the same
    state, should UBIFS be remounted rw again
    - prevent remounting ro if we have switched to read only
    mode (due to a fatal error)

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

    Adrian Hunter
     

27 Jan, 2009

1 commit

  • When data CRC checking is disabled, UBIFS returns incorrect return
    code from the 'try_read_node()' function (0 instead of 1, which means
    CRC error), which make the caller re-read the data node again, but using
    a different code patch, so the second read is fine. Thus, we read the
    same node twice. And the result of this is that UBIFS is slower
    with no_chk_data_crc option than it is with chk_data_crc option.
    This patches fixes the problem.

    Reported-by: Reuben Dowle
    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     

26 Jan, 2009

3 commits


20 Jan, 2009

1 commit


18 Jan, 2009

1 commit


31 Dec, 2008

2 commits

  • Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     
  • These are mostly long lines and wrong indentation warning
    fixes. But also there are two volatile variables and
    checkpatch.pl complains about them:

    WARNING: Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt
    + volatile int gc_seq;

    WARNING: Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt
    + volatile int gced_lnum;

    Well, we anyway use smp_wmb() for c->gc_seq and c->gced_lnum, so
    these 'volatile' modifiers can be just dropped.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     

23 Dec, 2008

4 commits


04 Dec, 2008

1 commit

  • This patch fixes the following section mismatch:

    WARNING: fs/ubifs/ubifs.o(.init.text+0xec): Section mismatch in reference from the function init_module() to the function .exit.text:ubifs_compressors_exit()

    Signed-off-by: Artem Bityutskiy

    Alexey Dobriyan
     

03 Dec, 2008

5 commits


22 Nov, 2008

3 commits

  • To avoid memory allocation failure during bulk-read, pre-allocate
    a bulk-read buffer, so that if there is only one bulk-reader at
    a time, it would just use the pre-allocated buffer and would not
    do any memory allocation. However, if there are more than 1 bulk-
    reader, then only one reader would use the pre-allocated buffer,
    while the other reader would allocate the buffer for itself.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     
  • Bulk-read allocates 128KiB or more using kmalloc. The allocation
    starts failing often when the memory gets fragmented. UBIFS still
    works fine in this case, because it falls-back to standard
    (non-optimized) read method, though. This patch teaches bulk-read
    to allocate exactly the amount of memory it needs, instead of
    allocating 128KiB every time.

    This patch is also a preparation to the further fix where we'll
    have a pre-allocated bulk-read buffer as well. For example, now
    the @bu object is prepared in 'ubifs_bulk_read()', so we could
    path either pre-allocated or allocated information to
    'ubifs_do_bulk_read()' later. Or teaching 'ubifs_do_bulk_read()'
    not to allocate 'bu->buf' if it is already there.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     
  • Bulk-read allocates a lot of memory with 'kmalloc()', and when it
    is/gets fragmented 'kmalloc()' fails with a scarry warning. But
    because bulk-read is just an optimization, UBIFS keeps working fine.
    Supress the warning by passing __GFP_NOWARN option to 'kmalloc()'.

    This patch also introduces a macro for the magic 128KiB constant.
    This is just neater.

    Note, this is not really fixes the problem we had, but just hides
    the warnings. The further patches fix the problem.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     

30 Sep, 2008

7 commits

  • Also add debugging checks for LPT size and separate
    out c->check_lpt_free from unrelated bitfields.

    Signed-off-by: Adrian Hunter

    Adrian Hunter
     
  • Znode may refer both data nodes and indexing nodes

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     
  • We cannot store bit-fields together if the processes which
    change them may race, unless we serialize them.

    Thus, move the nospc and nospc_rp bit-fields eway from
    the mount option/constant bit-fields, to avoid races.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     
  • The "bulk_read" and "no_chk_data_crc" have only 2 values -
    0 and 1. We already have bit-fields in corresponding data
    structers, so make "bulk_read" and "no_chk_data_crc"
    bit-fields as well.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     
  • UBIFS read performance can be improved by skipping the CRC
    check when data nodes are read. This option can be used if
    the underlying media is considered to be highly reliable.
    Note that CRCs are always checked for metadata.

    Read speed on Arm platform with OneNAND goes from 19 MiB/s
    to 27 MiB/s with data CRC checking disabled.

    Signed-off-by: Adrian Hunter

    Adrian Hunter
     
  • Some flash media are capable of reading sequentially at faster rates.
    UBIFS bulk-read facility is designed to take advantage of that, by
    reading in one go consecutive data nodes that are also located
    consecutively in the same LEB.

    Read speed on Arm platform with OneNAND goes from 17 MiB/s to
    19 MiB/s.

    Signed-off-by: Adrian Hunter

    Adrian Hunter
     
  • 'ubifs_get_lprops()' and 'ubifs_release_lprops()' basically wrap
    mutex lock and unlock. We have them because we want lprops subsystem
    be separate and as independent as possible. And we planned better
    locking rules for lprops.

    Anyway, because they are short, it is better to inline them.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy