public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: James Courtier-Dutton <James@superbug.co.uk>
To: Daniel J Blueman <daniel.blueman@gmail.com>
Cc: Jan Engelhardt <jengelh@computergmbh.de>,
	Richard Ballantyne <richardballantyne@gmail.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: file system for solid state disks
Date: Thu, 23 Aug 2007 13:45:39 +0100	[thread overview]
Message-ID: <46CD8173.1020606@superbug.co.uk> (raw)
In-Reply-To: <6278d2220708230155j18248f2cr3cc697a7acbaa930@mail.gmail.com>

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


  reply	other threads:[~2007-08-23 12:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-23  8:55 file system for solid state disks Daniel J Blueman
2007-08-23 12:45 ` James Courtier-Dutton [this message]
2007-08-23 12:56   ` Daniel J Blueman
     [not found]     ` <20070823134359.GB5576@mail.ustc.edu.cn>
2007-08-23 13:43       ` Fengguang Wu
2007-08-23 15:09         ` Daniel J Blueman
2007-09-05 12:34 ` Denys Vlasenko
2007-09-05 12:56   ` linux-os (Dick Johnson)
2007-09-05 13:04     ` Manu Abraham
  -- strict thread matches above, loose matches on Subject: below --
2007-08-25  8:41 Just Marc
2007-08-30 18:25 ` Jan Engelhardt
2007-08-30 18:26   ` Just Marc
2007-08-23  5:01 Richard Ballantyne
2007-08-23  5:52 ` Jan Engelhardt
2007-08-23 10:26   ` Theodore Tso
2007-08-23 11:25     ` Jens Axboe
2007-08-29 17:36       ` Bill Davidsen
2007-08-29 17:57         ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46CD8173.1020606@superbug.co.uk \
    --to=james@superbug.co.uk \
    --cc=daniel.blueman@gmail.com \
    --cc=jengelh@computergmbh.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richardballantyne@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox