On Sun, May 20, 2012 at 12:04:33PM +0000, Black, Michael (IS) scratched on the wall:
> Another more indirect way to test is this utility: > > http://kerneltrap.org/mailarchive/linux-ext4/2009/3/22/5215824 > > Which...if your fsync doesn't work at all will return something really > close to zero. > > On my RedHat system I get this which indicates fsync actually takes a > little of time...therefore it must be doing something....although it > doesn't prove that it's actually on the disk yet. > > fsync time: 0.0022 > fsync time: 0.0019 > fsync time: 0.0019 > fsync time: 0.0022 > fsync time: 0.0019 > fsync time: 0.0019 > fsync time: 0.0020 > fsync time: 0.0020 Assuming this is spinning disk, that takes a *very* little amount of time... A 10K RPM disk takes about 6 ms to spin around once. A more conventional 7600 RPM drive takes 7.9 ms. Ignoring seek times, device I/O times, and all the rest, it should still take, on average, about half those times just for the right sector to come around underneath the heads. But that's just an average-- it should vary from write to write. I doubt sleep() is accurate enough to keep the program in sync with the spindle rotation over a full second. That doesn't seem to match the consistent, 2 ms times you're seeing. Both the low time, and the consistency of them, make me suspect of these numbers-- unless it is an SSD device. > And I do believe if you take the sleep() out of the loop that you should > see constant times. I would suspect that loop is faster than a disk rotation, so assuming there isn't much other I/O going on in the system, I would also expect to see somewhat more consistent times without the sleep(). > Otherwise you'll see a much bigger time once in a > while when you overrun the buffers and it has to pause to really flush. > > Again...on my system I see this...one value 3 times as large as the > others...suspicious. Yes... but not so much that one number is larger, as the fact that all the other numbers are consistently small. Of course, you can also see large changes in fsync() times if anything else on the system needs to do I/O. Again, assuming we're talking about spinning disk, if you have random I/O from other processes, you're going to see seeks and random rotation delays that should be even larger than this. -j > sort fsync.dat | tail -n 5 > fsync time: 0.0025 > fsync time: 0.0025 > fsync time: 0.0026 > fsync time: 0.0027 > fsync time: 0.0059 > -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
