On Mon, Feb 14, 2011 at 12:05 PM, Simon Slavin <slav...@bigfraud.org> wrote:
> > The second variation was just unplugging the cord but keeping the power > > intact, so if it's drive that caches, it would end its operations > > completely. This time the results were perfect, for example 4822 -> 4822, > > and even 5371 -> 5372 = +1 that actually would mean the process was > > interrupted after all data is written but before sqlite made winsync, os > > reported failure, but the data was already there. > > > > So the sad news about faulty hardware is probably true once again. > > Can you expand upon your conclusion ? I like your test, and am interested > to know precisely where you think the lag is happening. > > Simon, the conclusion came from the assumption that if the lag is at the OS level then unplugging usb cord from powered hd box should also lead to bad results, but it doesn't. I.e. only in case of keeping power for unplugged hd box, the last commit reported by sqlite as successful is actually written. So looks like windows takes very seriously the option "optimize for quick removal" for removable drives. But both examples show that the drive itself doesn't obey this option. On the other side SATA/PATA drives connected directly to the motherboard have option "enable writing cache" that is explained like hardware-only option, maybe in this case one can actually affect how the drive is responding, but in contrary to usb tests, these ones are harder to make. I also tried to find any jumper except Master/Slave/etc in the hd, but there are no other. There is a little circuit in the box itself, but it lacks any jumper. Max _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
