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
next prev parent 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
2007-08-23 13:43 ` Fengguang Wu
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.