On Feb 21, 2005, at 9:40 AM, Curtis King wrote:
I noticed this as well, so I profiled my call and found sync was taking forever. I removed the following fcntl call, rc = fcntl(fd, F_FULLFSYNC, 0);. Performance was back to normal.
Here are some comments about F_FULLFSYNC, off the darwin list just two days ago. They mention why it's there, but don't mention how slow the performance might be...
It is a trade off between guaranteed data integrity and performance. If there happen to be a bunch of other apps writing to the disk when you do a SQLite transaction, then all of that data has to be flushed to the disk. As Domnic said, fsync() does not guarantee that the bytes hit the platter on any system. Pull the plug after a COMMIT and you are very likely going to see only part of the pages written.
You can also use the 'synchronous' pragma to control the number of F_FULLSYNCs executed during any single transaction. By default, it will be three-- probably too excessive.
The best way to guarantee maximal performance is to bunch up your INSERT and UPDATE statements into transactions as much as possible. This is often true regardless of the presence of F_FULLSYNC.
Note that this situation only arises in the case of catastrophic system failure such as a power failure or kernel panic.
b.bum
