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]

Message-ID: <4EAFFB8E.20605@earthlink.net>
Date:	Tue, 01 Nov 2011 10:00:46 -0400
From:	Stephen Clark <sclark46@...thlink.net>
To:	Theodore Tso <tytso@....EDU>
CC:	Vincent Pelletier <plr.vincent@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: ext4 bug ? "Intel 320 SSD write performance – contd."

On 11/01/2011 09:41 AM, Theodore Tso wrote:
> 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
>    
So what I hear if that if you are using sata interface and not doing 
virtualization we should be using FITRIMS's from  a cron job. At what 
frequency should
we be doing this?

Thanks,
Steve

-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)



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