Hi Ric,
Am 22.11.2013 21:37, schrieb Ric Wheeler:
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.
Thanks - but i have raw block devices the data goes to .
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
So i have to switch to write through but i'm still using the wb cache of
the device?
echo temporary write through > /sys/class/scsi_disk/<disk>/cache_type
Thanks!
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
