Hi!
"Mike" == Mike Black [EMAIL PROTECTED] writes:
Mike Here's a strace -r on IDE:
Mike 0.001488 write(3, "\214\1\0\0Blah Blah Blah Blah Blah Bla"..., 56) = 56
Mike 0.000516 fdatasync(0x3)= 0
Mike 0.001530 write(3, "\215\1\0\0Blah Blah Blah Blah Blah Bla"..., 56) =
Hello,
Michael Widenius wrote on Monday, March 05, 2001:
I wonder from where the fdatasync() is comming; MySQL is not doing
those (if you are not running mysqld with --flush)
The call is either a fsync or an fdatasync that is done by Berkley DB on the
transaction log.
Regards,
Chris
There is definitely something strange going on here.
As the bonnie test below shows, the SCSI disk used
for my tests should vastly outperform the old IDE one:
---Sequential Output ---Sequential Input-- --Random--
Seagate -Per Char- --Block--- -Rewrite-- -Per Char-
Since the intention of fsync and fdatasync seems to be
to write dirty fs buffers to persistent storage (i.e.
the "oxide") then the best time is not necessarily
the objective. Given the IDE times that people have
been reporting, it is very unlikely that any of those
IDE disks were really doing
This is just a guess - I have significant experience of Scsi drives but none of Unix
internals. To
do a good sync, you have to force the data from the CPU to the disk, and from the disk
ram onto the
disk oxide. IDE disks are not very clever, and I do not think that they cache
unwritten data.
Here's a strace -r on IDE:
0.001488 write(3, "\214\1\0\0Blah Blah Blah Blah Blah Bla"..., 56) = 56
0.000516 fdatasync(0x3)= 0
0.001530 write(3, "\215\1\0\0Blah Blah Blah Blah Blah Bla"..., 56) = 56
0.000513 fdatasync(0x3)= 0
0.001555 write(3,
