Messages in this thread | | | Date | Thu, 23 Aug 2007 13:56:17 +0100 | From | "Daniel J Blueman" <> | Subject | Re: file system for solid state disks |
| |
Hi Fengguang,
On 23/08/07, James Courtier-Dutton <James@superbug.co.uk> wrote: > 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.
I was having problem invoking the readahead logic on my compact flash rootfs (ext3) with tweaking the RA with 'hdparm -a' from 8 to 1024 blocks and some benchmarks (I forget which).
Fengguang, what is your favourite benchmark for finding differences in readahead values (running on eg ext3 on a flashdisk), with the current RA semantics in mainline kernels (eg 2.6.23-rc3)?
Thanks, Daniel -- Daniel J Blueman - 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/
| |