[PATCH] remove support for virtual blocks

Josh Boyer jdub at us.ibm.com
Mon Aug 29 14:42:52 EDT 2005


On Mon, 2005-08-29 at 12:07 +0200, Jörn Engel wrote:
> On Fri, 26 August 2005 15:12:29 -0500, Josh Boyer wrote:
> > On Fri, 2005-08-26 at 12:25 +0200, Jörn Engel wrote:
> > > Trivial patch.  Anyone complaining about this is free to write a
> > > better one.  Can I commit?
> > 
> > So now with this 1:1 mapping, a user is limited to using a 64 MiB chip
> > if the physical block size is 32 KiB?  I know there are NAND chips out
> > there that use such a block size and are larger than 64MiB.  Do we
> > really want to stop supporting all of these devices?  
> 
> No.
> 
> What we have right now is an ugly hack that causes random
> incompatibilities.  And it happens to be that both summary and erase
> count increase the chances of an incompatibility, so this hack
> effectively blocks both patches from inclusion.

Sure, not disagreeing with that.

> 
> What we need is a decent design that works without incompatibilities.
> And the design should define what's on the medium, _independently_ of
> whatever goes on in memory.  Changing the format on the medium because
> some struct now has an extra field is not an option.  Changing the
> format because the medium moved from a 32bit to a 64bit machine is not
> an option.

Yep.

> 
> Problem is that code for the decent design doesn't exist yet.  I
> personally prefer this patch to the current broken implementation, as
> it increases the pressure to write the correct code.  If such code
> doesn't show up in the near future, I'd be inclined to commit my
> patch.

Be realistic, this is JFFS2 not ext3 :).  If we break support for larger
devices, people aren't going to complain about it for months.  That
means this patch will sit here for months too.

I'd rather we switch to using vmalloc instead for now.  It's not an end
solution, but at least it doesn't prevent larger devices from being
used.

josh





More information about the linux-mtd mailing list