What happens if the disk or kernel lie. At both levels, I can see a potential performance enhancement by buffering changing while transparently acting as if they have actually been committed. My guess would be that hard-drives have explicit instruction(s) than ask for what actually happened; but I have never worked with this type of thing.
My understanding is that the kernel (for Windows and Linux values of "kernel") will never lie to you. They will accurately report what the storage drivers told it, and the lying occurs at that level.
Storage drivers seem to be a big source of corruption for MSSQL [1]:
> The most common cause of database corruption (more than 95% of all corruption cases) that we in PSS encounter turn out to be caused by a platform issue, which is a layer below the SQL Server. The most common individual cause is a 3rd party driver or firmware bug.
And as well
> My guess would be that hard-drives have explicit instruction(s)
They do, but the problem is that the storage drivers lie about what actually happened. E.g. Basically they implement write caching for the "flush the write cache" instruction.
It's same story with PostgreSQL aka Postgres.
"Almost all corruption issues are related to hardware problems, and most of the rest are due to documented-unsafe configurations like disabling fsync."
But of course doing that is up to the user. Using write-back caching with long sync interval and disabling fsync. It's really nice, gives better than SSD performance with regular HDD. Until you shut it down uncleanly, then you're screwed. But of course any sane person would use this only for temporary or other really non-important data which can be regenerated or lost without problems in such situation.
I'm using such configuration with ERP,BI/ETL (Extract, Transform, Load) tasks. When I start the task, I anyway drop and recreate any tables required for the task. SO I don't really mind if data gets corrupted. That's just life. Doing safe commits would make task very slow.
Only good question is how to balance smartly, in application data / caching, database engine caching and file system caching. In cases where database runs on same server as the processing application.
I'd say that this is a good task for tablespaces and intelligent disk partitioning. Set up a partition for the data you really don't care about with all the speedup options, and create a tablespace that points to it.
