Hi, Dave, Dave Chinner <david@xxxxxxxxxxxxx> 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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>