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 for Android: free password hash cracker in your pocket

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

Message-Id: <C838F22F-D7B1-4911-B6F6-214240A77859@mit.edu>
Date:	Tue, 1 Nov 2011 09:41:06 -0400
From:	Theodore Tso <tytso@....EDU>
To:	sclark46@...thlink.net
Cc:	Theodore Tso <tytso@....edu>,
	Vincent Pelletier <plr.vincent@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: ext4 bug ? "Intel 320 SSD write performance – contd."

On Nov 1, 2011, at 9:34 AM, Stephen Clark wrote:

>> 
>> 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
>> 
>>   
> <snip>
> 
> What about using discard in fstab like:
> LABEL=/ /                      ext4    defaults,discard,noatime,nodiratime        1 1

That does something different; this does continuous discards as you delete files.   This is probably the best thing to do if you are using thin-provisioning.   However, with SATA devices, a discard requires a queue flush, which can be a performance disaster.   (Also some cheaper SSD's also have real performance difficulties if there are frequent trims.)   There have also been reports that high frequency discards can trigger bugs that cause crappier SSD's to turn themselves into bricks.   The performance problems and the possibility of bricking crappier SSD's is why this isn't turned on by default.

Because of this, another method is to do FITRIM's periodically using cron.   This has less of a performance impact, so it's probably the better approach in many cases.

Basically, with SSD's and thin-provisioning systems, we are very much at the mercy at the competence of firmware authors.   As we know, sometimes firmware authors can be quite competent, or very, extremely incompetent.   So there will be a wide range of outcomes, which is one of the reasons why the best answer is to test to see what works best for you, preferably before you put use your systems in production.

-- Ted

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