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

From: Stefan Priebe
Date: Fri Nov 22 2013 - 15:01:42 EST


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

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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/