On Sun, Feb 13, 2011 at 11:55 AM, Max Vlasov <max.vla...@gmail.com> wrote:
> On Sun, Feb 13, 2011 at 5:31 PM, Jim Wilcoxson <pri...@gmail.com> wrote: > > > On Sun, Feb 13, 2011 at 1:15 AM, Max Vlasov <max.vla...@gmail.com> > wrote: > > > So the final results: > > > - the db was always ok and contains the correct value (id=10001 for > > initial > > > 1). > > > - the speed was about 227 commits per second so very close to my system > > > flush test (253) > > > > > > So if the drive is 5400 rpm, 227 is much more than 5400/60=90 and even > if > > > it's 7200 (manufacturers sometimes upgrade drives inside portable hd > > > without > > > prior notice), it's still twice as much as 7200/60=120. > > > > > > > My hypothesis to explain the behavior you are seeing is that it takes 4ms > > (1/253) for your OS to flush its buffers to the hard drive cache, issue > the > > sync to the drive, and the hard drive to acknowledge the sync. When it > is > > convenient, the drive will write this data to the disk. The sync command > > may make this more urgent than usual, which would explain why I/O slows > > down > > if sync is used. Or, the drive could simply have a sync timer: the first > > sync command starts the timer, and when 4ms have passed, the drive dumps > > its > > cache to the platters. > > > > > Jim, I see your point, maybe really for removable media on Windows sync is > still lazy, but much less "lazy" then general cached operations. Another > version is that removable hds can report that they wrote some data while > actually work as your described postonning it a little. > > But I thought about how it would be possible to test this explanation . I'm > going to do some tests that works like this. The same id updating, but in > the middle of 10,000 operation I will unplug the cord, the sqlite will say > that it can't commit particular insert and I can see what is the value of > this insert. After replugging two variants possible: > - I will find the previous value in the base. If for several dozens tests > the result is the same, that would mean that the situation is still needed > to be explained. > - I will find some value less than previous to the one sqlite could not > commit at least in some of the tests (maybe -3, -4 to the failed one). In > this case the explanation will be confirmed. > > How about this? Does it sound reasonable? > > Sounds like a clever test to me! I also found this page, used to force a Linux system crash: http://evuraan.blogspot.com/2005/06/how-to-force-paniccrash-in-linux.html I seem to remember a post that SQLite commit/sync is tested with the kill command, but it seems like actually crashing the machine (which is done without a sync first) might be a better test. Jim -- HashBackup: easy onsite and offsite Unix backup http://www.hashbackup.com _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
