CreamFilling512 said:
Bass said:
*snip*

That's bizarre, I mean usually database severs want to do their own caching, and control disk flushing since they know better than the OS.

I don't think most actually do, or if they do, they don't do a particularly good job of it. Really with DBs you expect that if you do an INSERT it will actually happen. So a lot of databases (at least Postgres and SQLite) call fsync after the completion of a simple write operation. Which on barriers enabled FS, tends to block until the data is actually written out to disk. Which is of course, slow.

 

Without barriers the kernel decides when it feels it is appropriate to actually write the data to disc.This means a lot of file operations (both read and write) are all happening entirely in RAM, and only when the disk is available and it doesn't hamper performence will the kernel persist the contents to disk. This can be as long as 60 seconds after the fsync request was made (or longer?).


You can fine tweak the performance vs data security, but the more data security you want, the less performance you are going to get (and vise-versa). Just a fact of life I guess. Smiley