OLPC / Introduction / Gen 1.5

[John Watlington]

> From: David Woodhouse <dwmw2 at infradead.org>
> Subject: Re: OLPC / Introduction / Gen 1.5
>
> ...
> I'm mildly concerned about the reported plans re storage in Gen  
> 1.5. If
> you'll forgive me being lazy, I'll quote something I wrote elsewhere,
> not so long ago, rather than trying to restate it coherently:
(It is good to periodically resend this paragraph to devel...)

> "Imagine a world where every hard drive you buy is actually a more  
> like
> a NAS. You can only talk a high-level protocol like CIFS or NFS to it;
> you can't access the sectors directly. Each vendor has their own
> proprietary file system on it internally, implemented behind closed
> doors by the same kind of people who write BIOSes. You have no real
> information about what's inside, and can't make educated decisions on
> which products to buy. Having made your choice you can't debug it, you
> can't optimise it for your own use case, you can't try to recover your
> data when things go wrong, and you sure as hell can't use btrfs on it.
> All you can do is pray to the deity of your choice, then throw the  
> poxy
> thing out the window when it loses your data.
>
> "If the above paragraph leaves you in a cold sweat, it was intended  
> to.
> That's the kind of dystopia I see in my head, when we talk about SSDs
> without direct access to the flash."

What little testing I've done generally verifies that if this is  
healthy paranoia.

> (When I said 'the same kind of people who write BIOSes', I didn't mean
> Mitch -- I meant the crack-smoking hobos they drag in off the  
> street to
> do most PC BIOSes).
>
> As you may have inferred from the above, I'm very dubious about using
> SSD controllers -- I really I think we can do better in software.

What you mean to say is: "I really think we can do better software".
The trick is getting the right kind of hardware built in volume to
support said software.

> JFFS2 obviously isn't the answer -- it was designed to work on maybe
> 32MiB of NOR flash, and even NAND support was an afterthought.  
> Extending
> it to work with Gen 1's 1GiB of NAND was pushing it _much_ further  
> than
> I ever thought it would go.

It has done amazingly well.

> But ubifs should be fine, and it's stable enough now that Nokia are
> shipping it in their products. I'd suggest it's definitely worth  
> giving
> _serious_ consideration for Gen 1.5, and even more so for Gen 2.

I did, and still am.
I'm still running UbiFS on three test laptops, and it is holding up well
although not nearly as fast as the SSD solutions.
(See http://wiki.laptop.org/go/NAND_Testing )

> You may still decide you that for 4-8GiB of storage on Gen 1.5 you  
> want
> to go the SSD route -- a year ago that was basically the only option,
> and right now, ubifs is relatively new. If so, I'd suggest you
> definitely want a 'wipe and reformat flash' option... so that  
> _when_ the
> internal "translation layer" screws up, you can reset it and don't  
> have
> to replace the unit.

Agreed.
Some of the SSD controllers tested failed so hard they couldn't be  
wiped.

> We can do these 'translation layers' that pretend to be a block  
> device,
> and then run 'normal' file systems on top, all in software too. We  
> have
> a few older ones already in the kernel, and my employer is going to be
> releasing a modern one found in current SSD microcontrollers soon, as
> GPL'd kernel code (not public knowledge). "Soon" probably isn't good
> enough for Gen 1.5 though; I suspect it's ubifs or SSD -- and I still
> don't think the 'translation layer' thing is a good idea even if it's
> implemented purely in software.

We should talk about the ideal hardware assist for UbiFS --- I'm  
trying to
convince chip vendors to include the bare minimum to access the Flash
and accelerate the common operations like ECC.   It is a difficult sell,
given the low cost of standalone SSD controllers and how the demands
on the SSD controller performance vary with market segment (the SSD
vendors look at me funny when I say I only want one or two channels...)

> Either way, I'd suggest it's definitely worth making sure the  
> controller
> gives you a 'pass-through' mode where you _can_ directly access the
> flash, if do go for an SSD-type controller.

I don't know of a single controller on the market that provides this  
feature
(that doesn't mean that such features aren't provided, with closed  
APIs...)

> -- 
> dwmw2