mirror of
https://github.com/torvalds/linux.git
synced 2024-11-16 17:12:06 +00:00
e9eca4de95
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 |
||
|---|---|---|
| .. | ||
| chips | ||
| devices | ||
| lpddr | ||
| maps | ||
| nand | ||
| onenand | ||
| tests | ||
| ubi | ||
| afs.c | ||
| ar7part.c | ||
| bcm63xxpart.c | ||
| cmdlinepart.c | ||
| ftl.c | ||
| inftlcore.c | ||
| inftlmount.c | ||
| Kconfig | ||
| Makefile | ||
| mtd_blkdevs.c | ||
| mtdblock_ro.c | ||
| mtdblock.c | ||
| mtdchar.c | ||
| mtdconcat.c | ||
| mtdcore.c | ||
| mtdcore.h | ||
| mtdoops.c | ||
| mtdpart.c | ||
| mtdsuper.c | ||
| mtdswap.c | ||
| nftlcore.c | ||
| nftlmount.c | ||
| ofpart.c | ||
| redboot.c | ||
| rfd_ftl.c | ||
| sm_ftl.c | ||
| sm_ftl.h | ||
| ssfdc.c | ||