[Ksummit-2008-discuss] Suggested topic: possible

Chris Mason chris.mason at oracle.com
Tue Aug 5 09:04:43 PDT 2008


On Tue, 2008-08-05 at 16:16 +0100, David Woodhouse wrote:
> On Tue, 2008-08-05 at 07:04 +0300, Eyal Shani wrote:
> > 
> > For a second there I thought u meant SSD management should be left for
> > the SSDs themselves.
> > 
> > However, I then continued reading, and understood you feel the
> > opposite – you suggest writing FS for RAW flash..?!
> 
> Absolutely. I already wrote one: http://david.woodhou.se/jffs2.pdf
> 
> That's a few years old now, and its design target was something like
> 32MiB of NOR flash -- so it's fairly much due for replacement. We now
> have alternatives such as Nokia's UBIFS:
> http://www.linux-mtd.infradead.org/doc/ubifs_whitepaper.pdf
> and Jörn Engel's "logfs": http://logfs.org/logfs/
> 
> I'm also plotting to make btrfs work on raw flash too. Its wandering
> tree design should work quite nicely, and I think there'll be benefits
> from using a 'mainline' file system.
> 

[ raw access to the flash on ssd ]

I'm interested to see how well btrfs works here, but it is pretty far
from the top of my list of things btrfs needs.  My target is to tune for
the commodity SSDs, and I believe the raw flash is going to be a
different market.

Given how fast SSD is changing, the FTL is definitely my friend.  I do
agree the trim command should help.

-chris




More information about the Ksummit-2008-discuss mailing list