linux-kernel - Re: file system for solid state disks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 23 Aug 2007 13:45:39 +0100
From:	James Courtier-Dutton <James@...erbug.co.uk>
To:	Daniel J Blueman <daniel.blueman@...il.com>
CC:	Jan Engelhardt <jengelh@...putergmbh.de>,
	Richard Ballantyne <richardballantyne@...il.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: file system for solid state disks

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