[RFC/PATCH v2] ubi: Add ubiblock read-write driver

Mike Frysinger vapier at gentoo.org
Wed Apr 24 12:27:46 EDT 2013


On Friday 19 April 2013 08:55:31 Matthieu CASTET wrote:
> Mike Frysinger a écrit :
> > On Friday 19 April 2013 08:31:13 Artem Bityutskiy wrote:
> >> On Fri, 2013-04-19 at 07:57 -0400, Mike Frysinger wrote:
> >>> the reason we're talking about not allowing write support at the
> >>> *block* layer
> >>> is because it's questionable how many people actually want this, the
> >>> performance isn't good (compared to native flash filesystems), and
> >>> because the
> >>> write/wear characteristics are unknown.
> >> 
> >> My opinion that unless people demonstrate that they need this, e.g. in a
> >> product, etc, we should not merge this stuff.
> >> 
> >> We recently merged fastmap, which is a big chunk of code, and it looks
> >> like no one really needs it. There was a problem report, and Richard
> >> promised to look, but did not. I do not blame him, he is a busy guy. But
> >> this shoes that this feature is not really needed, while adds
> >> maintenance burden.
> >> 
> >> To put it differently, I do recommend to merge more UBI-related code
> >> without a solid user-base.
> > 
> > also to be clear, i plan on using UBI block in read-only mode, so i'd
> > like to see an ubiblock driver merged
> 
> Why can't you use gluebi + mtdblock ?
> 
> Too much overhead ?

a poor man's read-only test on this one system shows ubiblock & mtdblock 
provide about the same read speeds.  but this was just reading the raw block 
device directly.

the mtd faq suggests that gluebi is meant only for devices that actually want 
mtd behavior (read/write/erase/etc...) like jffs2 rather than for flash unaware 
filesystems.  i'm not sure if gluebi will work if you want to run in read/write 
mode w/a fs like ext2.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20130424/26779b55/attachment.sig>


More information about the linux-mtd mailing list