James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> writes: > OK, so what the Database people are currently fretting about is how the > Linux cache fights with the WAL. Pretty much all DBs sit on filesystems > these days, so the first question is are block operations even relevant Yes, they are relevant so long as there are users. Not all databases run on file systems. More to the point, I think the spec includes them for completeness. > and do the (rather scant) file operations fit their need. The basic > problem with the file mode is the granularity. What does a DB do with > transactions which go over the limits? s/transactions/atomic multiwrites? There are a couple of options, there. You could either emulate the multiwrite transparently to the application, or you could fail it. I think we'd have to support both, since some applications will not want the less performant fallback. > It also looks like the NVM file actions need to work over DIO, so the > question is how. DIO just means avoid using the page cache (or, I guess you could make it more generic by saying avoid double buffering). If the hardware supports atomic writes, then this is easy. If it doesn't, then we can still do the emulation. DIO already has fallback to buffered, so it's not like we always honor that flag. > (And the other problem is that only a few DBs seem to use DIO). This is the first time I have ever heard anyone state that not using DIO was a problem. :-) Also, I'm not sure what problem you are thinking of. Perhaps you are referring to the interactions of the WAL and the page cache (that you mentioned in the first paragraph). Cheers, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
