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-next>] [day] [month] [year] [list]

Date:	Thu, 23 Aug 2007 09:55:36 +0100
From:	"Daniel J Blueman" <daniel.blueman@...il.com>
To:	"Jan Engelhardt" <jengelh@...putergmbh.de>,
	"Richard Ballantyne" <richardballantyne@...il.com>
Cc:	"Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: file system for solid state disks

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
-- 
Daniel J Blueman
-
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/