2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-17 09:43:59 +08:00
linux-next/drivers/mtd/ubi
Linus Torvalds e9eca4de95 This pull request contains the UBI fastmap support implemented by Richard
Weinberger from Linutronix. Fastmap is designed to address UBI's slow scanning
 issues. Namely, it introduces a new on-flash data-structure called "fastmap",
 which stores the information about logical<->physical eraseblocks mappings.
 So now to get this information just read the fastmap, instead of doing full
 scan. More information here can be found in Richard's announcement in LKML
 (Subject: UBI: Fastmap request for inclusion (v19)):
 
 http://thread.gmane.org/gmane.linux.kernel/1364922/focus=1369109
 
 One thing I want to explicitly say is that fastmap did not have large
 enough linux-next exposure. It is partially my fault - I did not respond
 quickly enough. I _really_ apologize for this. But it had good testing and
 disabled by default, so I do not expect that we'll break anything.
 
 Fastmap is declared as experimental so far, and it is off by default. We
 did declare that the on-flash format may be changed. The reason for this is
 that no one used it in real production so far, so there is a high risk that
 something is missing. Besides, we do not have user-space tools supporting
 fastmap so far.
 
 Nevertheless, I suggest we merge this feature. Many people want UBI's scanning
 bottleneck to be fixed and merging fastmap now should accelerate its production
 use. The plan is to make it bullet-prove, somewhat clean-up, and make it the
 default for UBI. I do not know how many kernel releases will it take.
 
 Basically, I what I want to do for fastmap is something like Linus did for
 btrfs few years ago.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.12 (GNU/Linux)
 
 iQIcBAABAgAGBQJQcrPrAAoJECmIfjd9wqK0gjYQAJICGYdYBO2wXQKojN+c518j
 dhZxSFBmn6VAVaLoiRJudbzVLiJXtEOupldnmfFqcBbM2I3KujkiVAb8kH99NNxH
 orfbSXmi6fvLZd1FWKm6EETl1CwWeOvQHcewLtGEdlhMqjNxo9QwZSxDNEARwBK8
 rCchMnR7QgnmKZQActxg/PfdKHmFgZf9mj/IkcLXvYhV3MimBeRjA+gKwJHQ4R7g
 +LWm2wkqEFpDqbtRIrJGsXkaX4f4oVK+KqTvOudsSMc5VD6R+xVjFux7MFz9DOYZ
 copqR/3Ep0O+xeVgUm6it/rGubdU/ejr0T5kF/EEmDe2ktn8/7eGDh4VMx+4AyES
 Vf18rD9Wc8eEcImcm/yxVY6FQRQjKT2tRF2TEarrhLAxXREsiYzLghRUuspgIcJG
 hqQsNqJyDvV/YNBZIqVyA7sx0TDaP/8CwNYy7NiVYtxsVeo9QyzWer0aaHjmIeBL
 AyEn5/2m7FVPL3acoLN4jAwyMNuDnQ3iuNqIhm2drm2brrxAcYUmWg/mXORlZpKM
 Q8ts0h4++sTWgwuOEM/iCfoHagxJc3cQMsE6C1Z7LdLsNFHAPdnKSSkkjXK54jqx
 wq1yapCkNDqzwWU4xjWsr7QaMLb69KPltx4Iw4wBE+8lW4WjqRdFhBs/+f3zceBe
 SaSUuYkTFij+Ol+XWJnL
 =/Sqc
 -----END PGP SIGNATURE-----

Merge tag 'upstream-3.7-rc1-fastmap' of git://git.infradead.org/linux-ubi

Pull UBI fastmap changes from Artem Bityutskiy:
 "This pull request contains the UBI fastmap support implemented by
  Richard Weinberger from Linutronix.  Fastmap is designed to address
  UBI's slow scanning issues.  Namely, it introduces a new on-flash
  data-structure called "fastmap", which stores the information about
  logical<->physical eraseblocks mappings.  So now to get this
  information just read the fastmap, instead of doing full scan.  More
  information here can be found in Richard's announcement in LKML
  (Subject: UBI: Fastmap request for inclusion (v19)):

     http://thread.gmane.org/gmane.linux.kernel/1364922/focus=1369109

  One thing I want to explicitly say is that fastmap did not have large
  enough linux-next exposure.  It is partially my fault - I did not
  respond quickly enough.  I _really_ apologize for this.  But it had
  good testing and disabled by default, so I do not expect that we'll
  break anything.

  Fastmap is declared as experimental so far, and it is off by default.
  We did declare that the on-flash format may be changed.  The reason
  for this is that no one used it in real production so far, so there is
  a high risk that something is missing.  Besides, we do not have
  user-space tools supporting fastmap so far.

  Nevertheless, I suggest we merge this feature.  Many people want UBI's
  scanning bottleneck to be fixed and merging fastmap now should
  accelerate its production use.  The plan is to make it bullet-prove,
  somewhat clean-up, and make it the default for UBI.  I do not know how
  many kernel releases will it take.

  Basically, I what I want to do for fastmap is something like Linus did
  for btrfs few years ago."

* tag 'upstream-3.7-rc1-fastmap' of git://git.infradead.org/linux-ubi:
  UBI: Wire-up fastmap
  UBI: Add fastmap core
  UBI: Add fastmap support to the WL sub-system
  UBI: Add fastmap stuff to attach.c
  UBI: Wire-up ->fm_sem
  UBI: Add fastmap bits to build.c
  UBI: Add self_check_eba()
  UBI: Export next_sqnum()
  UBI: Add fastmap stuff to ubi.h
  UBI: Add fastmap on-flash data structures
2012-10-08 20:40:45 +09:00
..
attach.c UBI: Add fastmap stuff to attach.c 2012-10-03 12:29:38 +03:00
build.c UBI: Add fastmap stuff to attach.c 2012-10-03 12:29:38 +03:00
cdev.c UBI: print less 2012-09-04 09:39:02 +03:00
debug.c UBI: use pr_ helper instead of printk 2012-09-04 09:39:02 +03:00
debug.h UBI: print less 2012-09-04 09:39:02 +03:00
eba.c UBI: Wire-up ->fm_sem 2012-10-03 12:29:37 +03:00
fastmap.c UBI: Add fastmap core 2012-10-03 16:39:27 +03:00
gluebi.c UBI: use pr_ helper instead of printk 2012-09-04 09:39:02 +03:00
io.c UBI: print less 2012-09-04 09:39:02 +03:00
kapi.c UBI: modify ubi_wl_flush function to clear work queue for a lnum 2012-05-21 11:34:41 +03:00
Kconfig UBI: Wire-up fastmap 2012-10-03 16:39:37 +03:00
Makefile UBI: Wire-up fastmap 2012-10-03 16:39:37 +03:00
misc.c UBI: comply with coding style 2012-09-04 09:39:01 +03:00
ubi-media.h UBI: Add fastmap on-flash data structures 2012-10-03 12:29:37 +03:00
ubi.h UBI: Add fastmap stuff to attach.c 2012-10-03 12:29:38 +03:00
upd.c UBI: modify ubi_wl_flush function to clear work queue for a lnum 2012-05-21 11:34:41 +03:00
vmt.c UBI: harmonize the update of ubi->beb_rsvd_pebs 2012-07-18 14:30:34 +03:00
vtbl.c The main change is the way we reserve eraseblocks for bad blocks 2012-10-02 20:49:15 -07:00
wl.c UBI: Add fastmap support to the WL sub-system 2012-10-03 12:29:38 +03:00