Why? It's not as if the relational database will be sharing any of
its data areas with any other applications (if the dba is sane; I
won't try to predict the behavior of a DBA who's just realized that
the spiffy new database was a clever scan forced upon their foolish
company) so the locking isn't rocket science. And there's little
point of dropping the record management into kernel space unless
you also intend to move the rest of the database manager there to
avoid those annoying privilege gates.
And if you're paranoid about relational integrity, (a) memory is
cheap and (b) if you manage your own buffers, you can give a much
better guarantee that when you commit a transaction that transaction
will go to disk in the way that you want.
If you want a speedier database, it makes good sense to put it on
top of the OS'es buffer cache, because the OS will most likely know
how to do that better than you can. But that's an entirely different
kettle of fish -- one that you don't mind losing the catch of the
day when the thing splits open and dumps boiling water on the floor.
Sure, you could emulate the first behavior if Linux had a ordered
update filesystem with a suitable buffer cache interface that you
could exploit for your own write ordering, but does such a thing
exist now, and would it be even slightly portable?
____
david parsons \bi/ Too many years working for the idiots at Sybase.
\/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/