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 200
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 Dela
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".
Douglas Gilbert wrote:
> 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:
First thank you and others with my clueless investigation about
the module loading under Debian GNU/Linux. (I
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-
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. If
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, "\216\