> But yes maybe the boost won't be of the order of gdbm databases. Maybe
> dbms uses logging storage and so they never rewrite to the same region of
> disk two times (well I don't know DBMS internals). But if they rewrite to
> the same region of disk many times as gdbm does, the boost will be
> _impressive_ too (removing all possible fsync in the middle of two
> consecutive writes of course ;).
The areas used for logging are written to often. On one running system,
each 2K log block is written to an average of 5.24 times. I believe logs
are generally flushed out immediately (via async I/O on OS's that support
it) because recoverability is so important.
Another stat on the same machine: At one snapshot, it had written to the
trans log 23 times per second and allocated a new block 4.5 times per
second. Logs are written sequentially and periodically truncated, so this
fits the earlier stat that you're going to get about 5 writes per 2K block
(on this DB).
I've generally found that the "busy-ness" of the DB I'm working on is
directly dependent on the number of trans log writes.
> Anyway I think it worth to try. My code is at least not obvously buggy and
> I think that it worth to try it out on a real DBMS and doing some
> benchmark.
Does anybody have an idea of a good benchmark to run?
-
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/