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

[Matthias Andree <matthias.andree@gmx.de>]

On Mon, 30 May 2005, Greg Stark wrote:

> Matthias Andree <matthias.andree@gmx.de> writes:
> 
> > On Sun, 29 May 2005, Greg Stark wrote:
> > 
> > > They meet this requirement just fine on SCSI drives (where write caching
> > > generally ships disabled) and on any OS where fsync issues a cache flush. If
> > 
> > I don't know what facts "generally ships disabled" is based on, all of
> > the more recent SCSI drives (non SCA type though) I acquired came with
> > write cache enabled and some also with queue algorithm modifier set to 1.
> 
> People routinely post "Why does this cheap IDE drive outperform my shiny new
> high end SCSI drive?" questions to the postgres mailing list. To which people
> point out the IDE numbers they've presented are physically impossible for a
> 7200 RPM drive and the SCSI numbers agree appropriately with an average
> rotational latency calculated from whatever speed their SCSI drives are.

This may be a different reason than the vendor default or the saved
setting being WCE = 0, Queue Algorithm Modifier = 0...

I would really appreciate if the kernel printed a warning for every
partition mounted that cannot both enforce write order and guarantee
synchronous completion for f(data)sync, based on the drive's write
cache, file system type, current write barrier support and all that.

> > It's a matter of enforcing write order. In how far such ordering
> > constraints are propagated by file systems, VFS layer, down to the
> > hardware, is the grand question.
> 
> Well guaranteeing write order will at least mean the database isn't complete
> garbage after a power event.
> 
> It still means lost transactions, something that isn't going to be acceptable
> for any real-life business where those transactions are actual dollars.

Right, synchronous completion is the other issue. I want the kernel to
tell me if it's capable of doing that on a particular partition (given
hardware settings WRT cache, drivers, file system, and all that). Either
in the docs or if it's too confusing via dmesg.

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/