8:25 p.m.
Hi, Dave,
Dave Chinner <david(a)fromorbit.com> writes:
> You're missing the point. You can't take applications
that don't know
> how to deal with torn sectors and put them on a block device that does
> not provide power fail write atomicity of a single sector.
Very few applications actually care about atomic sector writes.
I agree that most applications do not care about power-fail write
atomicity of a single sector. However, of those applications that do
care about it, how many will/can run safely when atomic sector writes
are not provided? Thanu gave some examples of applications that require
atomic sector writes today, and I'm sure there are more. It sounds like
you are comfortable with running those applications on a file system
layered on top of a raw pmem device. (Again, I'm coming from the angle
that block storage already provides this guarantee, at least mostly.)
IOWs, you've just pointed to an application that demonstrates
pmem-safe behaviour - just configure the database files with
"file:somefile.db?psow=0" and it will assume that individual sector
writes can be torn, and it will always recover.
Hence I'm not sure exactly what point you are trying to make with
this example.
Sorry, what I meant to point out was that the sqlite developers changed
from assuming sectors could be torn to assuming they were not. So, *by
default*, the database assumes that sectors will not be torn.
Dave, on one hand you're arguing fervently for data integrity (over
pre-mature optimisation). But on the other hand you're willing to
ignore data integrity completely for a set of existing applications.
This is not internally consistent. :) Please explain.
Cheers,
Jeff