Messages in this thread | | | Date | Thu, 23 Aug 2007 13:45:39 +0100 | From | James Courtier-Dutton <> | Subject | Re: file system for solid state disks |
| |
Daniel J Blueman wrote: > On 23 Aug, 07:00, Jan Engelhardt <jengelh@computergmbh.de> wrote: > >> On Aug 23 2007 01:01, Richard Ballantyne wrote: >> >>> What file system that is already in the linux kernel do people recommend >>> I use for my laptop that now contains a solid state disk? >>> >> If I had to choose, the list of options seems to be: >> >> - logfs >> [unmerged] >> >> - UBI layer with any fs you like >> [just a guess] >> >> - UDF in Spared Flavor (mkudffs --media-type=cdrw --utf8) >> [does not support ACLs/quotas] >> > > Isn't it that with modern rotational wear-levelling, re-writing hot > blocks many times is not an issue, as they are internally moved around > anyway? So, using a journalled filesystem such as ext3 is still good > (robustness and maturity in mind). Due to lack of write buffering, > perhaps a wandering log (journal) filesystem would be more suitable > though? I use ext3 on my >35MB/s compact flash filesystem. > > I can see there being advantage in selecting a filesystem which is > lower complexity due to no additional spatial optimisation complexity, > but those advantages do buy other efficiency (eg the Orlov allocator > reducing fragmentation, thus less overhead), right? > > Also, it would be natural to employ 'elevator=none', but perhaps there > is a small advantage in holding a group of flash blocks 'ready' (like > SDRAM pages being selected on-chip for lower bus access latency) - > however this no longer holds when logical->physical remapping is > performed, so perhaps it's better without an elevator. > > Clearly, benchmarks speak...but perhaps it would make sense to have > libata disable the elevator for the (compact) flash block device? > > Daniel >
Also, sector read ahead will actually have a performance impact on Flash, instead of speed things up with a spinning disc. For example, a request might read 128 sectors instead of the one requested at little or no extra performance impact for a spinning disc. For flash, reading 128 sectors instead of the one requested will have a noticeable performance impact. Spinning discs have high seek latency, low serial sector read latency and equal latency for read/write Flash has low seek latency, high serial sector read latency and longer write than read times.
James
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |