Should flash hardware look like UBI?

Thomas Gleixner tglx at linutronix.de
Tue Oct 6 08:56:40 EDT 2009


David,

On Tue, 6 Oct 2009, David Woodhouse wrote:
> On Tue, 2009-10-06 at 13:21 +0200, Thomas Gleixner wrote:
> > On Mon, 5 Oct 2009, David Woodhouse wrote:
> > >  
> > > We don't _necessarily_ mind if the device hides bad blocks for us, and
> > > if it maintains a logical<->physical mapping of eraseblocks. That kind
> > > of thing has been done by hard drives for years, and it's simple enough
> > > that they _ought_ to be able to get it right. Although the reliability
> > > testing on Toshiba LBA-NAND shows that it's obviously possible to screw
> > > it up too :)
> > 
> > Hmm, we have seen in the past how poorly implemented the logical <->
> > physical mappings have been and how naive the wear levelling approach
> > was in such devices. I'm not too confident that the manufacturers
> > actually have improved that in a significant way.
> 
> True, but if we keep it _simple_ then maybe they're less likely to screw
> it up so comprehensively. I think that practically speaking, we're going
> to have to let them do _something_. We can't just revoke their licence
> to write code, much as we'd like to.

I guess the bad block hiding might work, but I'm concerned about the
wear levelling aspect. That's what they usually fail to do in a
sensible way. When the resulting carefully hidden and obscured
algorithm is just contrary to what the filesystem expects you are
again digging holes in your device within no time.
 
> > > It occurs to me that the interface that UBI presents to the higher
> > > layers is actually a fairly close fit to what we want from hardware.
> > >
> > > And where it _isn't_, there's something to be said for changing UBI to
> > > match what we want. With notifications for 'block recycle needed', for
> > > reading blocks without actually returning the data, just to check if the
> > > ECC shows any bitflips, etc.)
> > 
> > Which makes me wonder whether we could have access to the CPU which
> > runs inside of SSDs and just implement UBI on it. :) 
> >
> > Open Source Firmware for SSDs would allow us to optimize the
> > filesystem <-> storage device interaction even better.
> 
> Yeah, but they have a fit if you even hint at that. It's stupid, but
> they think there's something special in the code that we're all swearing
> about and trying to get _out_ of the way.

Gah, they should concentrate on implementing useful and functional
hardware. I'm not convinced that companies who fail to implement a
working timer for more than 10 years might write code which is not a
complete desaster.

> But getting _them_ to implement something UBI-like might be possible.
> It's much simpler than pretending to be a disk, so it's more likely that
> they'll be able to get it right. And it gives us the capability to do
> decent file systems which don't share the disadvantages of the SSD
> model.



More information about the linux-mtd mailing list