linux-kernel - Re: ext4 bug ? "Intel 320 SSD write performance

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:	Mon, 31 Oct 2011 17:09:51 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Vincent Pelletier <plr.vincent@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: ext4 bug ? "Intel 320 SSD write performance – contd."

On Mon, Oct 31, 2011 at 09:38:37PM +0100, Vincent Pelletier wrote:
> 
> Reading this blog post[1], I thought the "2nd iteration" results could be
> considered a bug in mkfs.ext4 (and possibly any mkfs implementation):
> shouldn't mkfs run [FI]TRIM on its target before creating filesystem
> structure ?

It's not enabled by default, because there are crappy SSD's out there
where use of the TRIM command will turn them into bricks.  (No, it's
not the Intel X-25 drives that I'm worried about.)

So I (and the distributions) don't want to make it the default, since
if you buy crap drives and then mke2fs turns them into bricks, who are
you likely to blame?  The crap SSD manufacturer?  Yourself for trying
to buy SSD's on the cheap?  Or the program that issued the TRIM
command?

You can enable the trim behaviour by default by adding to your
/etc/mke2fs.conf file:

[defaults]
	discard = true

But then it's on your head if anything bad happens.  :-/

        	      	      	      - Ted

P.S.  For a similar reason we don't enable TRIM commands in the
kernel, where we have three possible ways of issuing TRIM.  One is
continuously, as files get unlinked (and the file system transaction
is committed).  Another way is via a userspace progam run out of cron
which calls the FITRIM ioctl; and the third way is at e2fsck time,
after a full e2fsck run without any file system errors detected.
Depending how the SSD implemented TRIM, (and of course your workload),
some of these methods can be performance disasters, and have resulted
in SSD's getting bricked, which is again why none of these are turned
on by default.

--
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/