Peter, I have found rather strange things when I have played with O_SYNC, fsync, and fdatasync this weekend. On Linux-Compaq Alpha, opening the file with the O_SYNC option (which makes the OS to do the fsync after each write) speeded up autocommit inserts by a factor of 3. I was able to insert about 150 rows/second. I did not notice a difference between fsync and fdatasync. On a 2-CPU Linux Xeon with the O_SYNC I get 500 inserts/second. No disk rotates 500 rot/s, which means that the disk cache probably fools the OS to think that the flush to the disk has ended while it has not. With fsync I get 200 inserts/second, which also is too much since I do not believe the disk rotates 200 rot/s. In theory O_SYNC and fsync should be as fast, because during the disk rotation of some 10 milliseconds the OS has plenty of time to do what it likes. It may be necessary that I let the user decide in my.cnf which fsync mechanism to use. The goal is that the transaction is safe on disk when the control returns to the user, but it is not delayed unnecessarily. Regards, Heikki At 11:52 AM 5/13/01 +0400, you wrote: >Hello Heikki, > > I'we read in discussion you're playing with making files fsync() > after transaction commit. > I've recently had the same readings and fount, what at least in > linux it's recomended to use fdatasync() instead of fsync() in > several conditions, like probably yours: > > >SYNOPSIS > #include <unistd.h> > > #ifdef _POSIX_SYNCHRONIZED_IO > > int fdatasync(int fd); > > #endif > >DESCRIPTION > fdatasync flushes all data buffers of a file to disk > (before the system call returns). It resembles fsync but > is not required to update the metadata such as access > time. > > Applications that access databases or log files often > write a tiny data fragment (e.g., one line in a log file) > and then call fsync immediately in order to ensure that > the written data is physically stored on the harddisk. > Unfortunately, fsync will always initiate two write opera > tions: one for the newly written data and another one in > order to update the modification time stored in the inode. > If the modification time is not a part of the transaction > concept fdatasync can be used to avoid unnecessary inode > disk write operations. > > > >-- >Best regards, > Peter mailto:[EMAIL PROTECTED] > > > --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
