Linux does not care for data integrity (was: Disk write cache)

[Matthias Andree]

On Sun, 15 May 2005, Jeff Garzik wrote:

> The ability of a filesystem or fsync(2) to cause a [FLUSH|SYNC] CACHE 
> command to be generated has only been present in the most recent 2.6.x 
> kernels.  See the "write barrier" stuff that people have been discussing.

To make this explicit and unmistakable, Linux should be ashamed of
having put its users' data at risk for as long as it has existed, and
looking at how often I still get "barrier synch failed", it still does
with the kernel SUSE Linux 9.3 shipped with.

This came up several times, from database and mailserver authors, but
found no reasonable solution to date.

The documentation which file systems request cache flush for fsync, and
which device drivers (SCSI as ATA) as well as chipset adaptors pass this
down properly, is still missing. I've asked for help with such a list
several times over the recent years, I've offered my help in setting up
and maintaining the list when sent the raw information, but no-one cared
to provide this kind of information.

I will not try again, it's no good, kernel hackers with a handful of
exceptions, don't care.

If they think they do in spite of my statement, they'll have to prove
their point by growing up and documenting which combinations of
(file system, mount options, block dev driver, hardware/chip driver)
barrier synch is 100% reliable, which file systems, chipset drivers,
block drivers, hardware drivers, are missing links in the chain -- and
request that the kernel switches off the drive's write cache in all
drives unless the whole fsync() stuff works (unless defeated by a
"benchmark" kernel boot parameter).

Until then, my applications will have to recommend that users switch off
drive caches for consistency.

P. S.: Yes, the subject and this mail are provoking and exaggerated a
       tiny bit. I feel that's needed to raise the necessary motivation
       to finally address this issue after a decade or so.

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