Milan Babuskov wrote:

> Kjell Rilbe wrote:
> > Do you mean that some file systems (on Linux?) have a write cache but
> > ensure that writes are performed in the order they are queued?
>
> Yes, something like that.
>
> > In either case, I assume the disk still has to perform the same sequence
> > of seeks and writes to do its job, so with a constant commit rate the
> > performance will be the same as without this kind of cache. Same
> > "motorcycle effect". Right?
>
> Performance is nearly the same, but consistency is much higher. If you
> have a filesystem with ordered writes, metadata (directory structure,
> which bytes go into which file, etc.) is kept in place and data is
> written in such way that Firebird easily detects unwritten stuff as
> uncommitted transactions. Without ordered writes you can easily end up
> with part of some other file in Firebird database file after a power
> failure (for example, if database file grows and needs to grow the file
> on disk). Having a part of some other file in FB database is corruption.

I see. Interesting. That's actually how I though most/all filesystems
work. Anyone know how NTFS and newer Windows filsystems do it?

Anyway, as far as I can see, this isn't quite to the point regarding
commit throughput, which was my main concern in this thread.

I still wonder either 1) what's wrong with my config that makes it so
slow, or 2) is this really the best I can currently get with FB? And if
so, then 3) what's being done to make FB better?

Kjell
--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64