linux-kernel - Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD?

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: <528FC09E.5090004@redhat.com>
Date:	Fri, 22 Nov 2013 15:37:50 -0500
From:	Ric Wheeler <rwheeler@...hat.com>
To:	Stefan Priebe <s.priebe@...fihost.ag>,
	Christoph Hellwig <hch@...radead.org>,
	Chinmay V S <cvs268@...il.com>
CC:	"J. Bruce Fields" <bfields@...ldses.org>,
	"Theodore Ts'o" <tytso@....edu>, linux-fsdevel@...r.kernel.org,
	Al Viro <viro@...iv.linux.org.uk>,
	LKML <linux-kernel@...r.kernel.org>,
	Matthew Wilcox <matthew@....cx>
Subject: Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD?

On 11/22/2013 03:01 PM, Stefan Priebe wrote:
> Hi Christoph,
> Am 21.11.2013 11:11, schrieb Christoph Hellwig:
>>>
>>> 2. Some drives may implement CMD_FLUSH to return immediately i.e. no
>>> guarantee the data is actually on disk.
>>
>> In which case they aren't spec complicant.  While I've seen countless
>> data integrity bugs on lower end ATA SSDs I've not seen one that simpliy
>> ingnores flush.  If you'd want to cheat that bluntly you'd be better
>> of just claiming to not have a writeback cache.
>>
>> You solve your performance problem by completely disabling any chance
>> of having data integrity guarantees, and do so in a way that is not
>> detectable for applications or users.
>>
>> If you have a workload with lots of small synchronous writes disabling
>> the writeback cache on the disk does indeed often help, especially with
>> the non-queueable FLUSH on all but the most recent ATA devices.
>
> But this isn't correct for drives with capicitors like Crucial m500, Intel DC 
> S3500, DC S3700 isn't it? Shouldn't the linux kernel has an option to disable 
> this for drives like these?
> /sys/block/sdX/device/ignore_flush

If you know 100% for sure that your drive has a non-volatile write cache, you 
can run the file system without the flushing by mounting "-o nobarrier".  With 
most devices, this is not needed since they tend to simply ignore the flushes if 
they know they are power failure safe.

Block level, we did something similar for users who are not running through a 
file system for SCSI devices - James added support to echo "temporary" into the 
sd's device's cache_type field:

See:

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=2ee3e26c673e75c05ef8b914f54fadee3d7b9c88

Ric

>
>> Again, what your patch does is to explicitly ignore the data integrity
>> request from the application.  While this will usually be way faster,
>> it will also cause data loss.  Simply disabling the writeback cache
>> feature of the disk using hdparm will give you much better performance
>> than issueing all the FLUSH command, especially if they are non-queued,
>> but without breaking the gurantee to the application.
>>
>

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