Re: [LSF/MM TOPIC] atomic block device

[Jeff Moyer <jmoyer@redhat.com>]

James Bottomley <James.Bottomley@HansenPartnership.com> 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