Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 18 5月, 2009 3 次提交
  3. 27 1月, 2009 1 次提交
  5. 18 1月, 2009 1 次提交
  7. 16 12月, 2008 2 次提交
  9. 24 7月, 2008 5 次提交
  11. 22 4月, 2008 1 次提交
  13. 17 4月, 2008 1 次提交
  15. 04 3月, 2008 1 次提交
  17. 25 1月, 2008 5 次提交
    • A
      UBI: implement atomic LEB change ioctl · e653879c
      由 Artem Bityutskiy 提交于 
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      e653879c
    • A
      UBI: simplify internal interfaces · 1b68d0ee
      由 Artem Bityutskiy 提交于 
      Instead of passing vol_id to all functions and then find
struct ubi_volume, pass struct ubi_volume pointer.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      1b68d0ee
    • A
      UBI: add auto-resize feature · 4ccf8cff
      由 Artem Bityutskiy 提交于 
      The problem: NAND flashes have different amount of initial bad physical
eraseblocks (marked as bad by the manufacturer). For example, for 256MiB
Samsung OneNAND flash there might be from 0 to 40 bad initial eraseblocks,
which is about 2%. When UBI is used as the base system, one needs to know
the exact amount of good physical eraseblocks, because this number is
needed to create the UBI image which is put to the devices during
production. But this number is not know, which forces us to use the
minimum number of good physical eraseblocks. And UBI additionally
reserves some percentage of physical eraseblocks for bad block handling
(default is 1%), so we have 1-3% of PEBs reserved at the end, depending
on the amount of initial bad PEBs. But it is desired to always have
1% (or more, depending on the configuration).

Solution: this patch adds an "auto-resize" flag to the volume table.
The volume which has the "auto-resize" flag will automatically be re-sized
(enlarged) on the first UBI initialization. UBI clears the flag when
the volume is re-sized. Only one volume may have the "auto-resize" flag.

So, the production UBI image may have one volume with "auto-resize"
flag set, and its size is automatically adjusted on the first boot
of the device.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      4ccf8cff
    • A
      UBI: use bit-fields · 896c0c06
      由 Artem Bityutskiy 提交于 
      Save 12 bytes of RAM per volume by using bit-fields instead of integers.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      896c0c06
    • A
      UBI: get rid of ubi_ltree_slab · b9a06623
      由 Artem Bityutskiy 提交于 
      This slab cache is not really needed since the number of objects
is low and the constructor does not make much sense because we
allocate oblects when doint I/O, which is way slower then allocation.
Suggested-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      b9a06623
  19. 27 12月, 2007 15 次提交
  21. 14 10月, 2007 3 次提交
    • A
      UBI: fix atomic LEB change problems · e8823bd6
      由 Artem Bityutskiy 提交于 
      When the UBI device is nearly full, i.e. all LEBs are mapped, we have
only one spare LEB left - the one we reserved for WL purposes. Well,
I do not count the LEBs which were reserved for bad PEB handling -
suppose NOR flash for simplicity. If an "atomic LEB change operation"
is run, and the WL unit is moving a LEB, we have no spare LEBs to
finish the operation and fail, which is not good. Moreover, if there
are 2 or more simultanious "atomic LEB change" requests, only one of
them has chances to succeed, the other will fail with -ENOSPC. Not
good either.

This patch does 2 things:
1. Reserves one PEB for the "atomic LEB change" operation.
2. Serealize the operations so that only on of them may run
   at a time (by means of a mutex).
Pointed-to-by: NBrijesh Singh <brijesh.s.singh@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      e8823bd6
    • A
      UBI: do not use vmalloc on I/O path · e88d6e10
      由 Artem Bityutskiy 提交于 
      Similar reason as in case of the previous patch: it causes
deadlocks if a filesystem with writeback support works on top
of UBI. So pre-allocate needed buffers when attaching MTD device.
We also need mutexes to protect the buffers, but they do not
cause much contantion because they are used in recovery, torture,
and WL copy routines, which are called seldom.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      e88d6e10
    • A
      UBI: allocate memory with GFP_NOFS · 33818bbb
      由 Artem Bityutskiy 提交于 
      Use GFP_NOFS flag when allocating memory on I/O path, because otherwise
we may deadlock the filesystem which works on top of us. We observed
the deadlocks with UBIFS. Example:

VFS->FS lock a lock->UBI->kmalloc()->VFS writeback->FS locks the same
lock again.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      33818bbb
  23. 18 7月, 2007 2 次提交