Re: file system for solid state disks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Daniel J Blueman wrote:
On 23 Aug, 07:00, Jan Engelhardt <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux