And you think Jim's timings are wrong because......???? I've already shown you can get speed just like he's showing.
That's what you get on a good write-cache-enabled drive. And if you want to talk about data reliability...BACK UP YOUR DATA. The likely failure points I can think of are: #1 Power supply (redundant supplies available) #2 Hard drive smoked (and your data is toast anyways -- RAID can help). #3 Blue screen (or kernel lockup on Unix) #4 CPU smoked. (usually leads to #3) #5 RAM smoked. (usually leads to #3) #6 Motherboard smoked (usually just dies or #3) The only way to increase your reliability is to replicate and/or backup. All the whining about acid-tested drives is a waste of time. #3 through #6 have no solution though they shouldn't cause the hard drive corruption you're worried about. And since #1 and #2 have solutions what's the problem? Linux systems have write-cache enabled by default and they are running on an awful lot of servers around the world with no data loss. Michael D. Black Senior Scientist NG Information Systems Advanced Analytics Directorate ________________________________________ From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of Max Vlasov [max.vla...@gmail.com] Sent: Monday, February 14, 2011 2:02 PM To: General Discussion of SQLite Database Subject: EXT :Re: [sqlite] UPDATE/INSERTing 1-2k rows slower than expected On Mon, Feb 14, 2011 at 8:42 PM, Jim Wilcoxson <pri...@gmail.com> wrote: > On Mon, Feb 14, 2011 at 10:56 AM, Pavel Ivanov <paiva...@gmail.com> wrote: > >> So my question is, does it maintain the other 3 parts of ACID, so that > >> the database will never be in a corrupted state after a power loss, > >> even though it may be missing some writes that were confirmed? > > > > Jim, I think the answer to your question is already in Max's tests: > > the USB drive is completely unreliable and can easily lead to database > > corruption. I'll explain. Max's tests showed that there were > > situations when database and journal were different not by one > > transaction but by several ones. So if one makes changes to several > > database pages (located in different disk sectors) and/or makes > > transactions touching several database pages (which makes multi-page > > journal files) then these pages can be way out of sync with each other > > (including pages inside journal). And this will easily lead to > > database corruption. > > You are right I think. I wrote my own test program and ran it on a > Macbook Pro with a Seagate USB drive. Here is the Python test > program: > > [jim@mb backup]$ time py t.py > 4999 records inserted in 17.7488458157 seconds; 281.652117097 recs/sec > > Jim, your tests also shows (this time on a different os) that either you have a fantastic hd with 18000 Rpm or just someone at Seagate _want_ you to think you have a fantastic hd :) Just wondering, I know this maybe sounds fantastic, but I'm thinking whether some "acid-passed harddrives" at sqlite.org can encourage manufacturers to hold the horses. The logic would be like this: if some model is present in either section then googling it will make this page very high in the google results (due to high pagerank of sqlite.org). So they probably very quickly notice that this page at least partly can affect their sales. Unfortunately the technical side is more complex, the developers just can't rely on e-mails from users, this should be some sqlite-originated tests performing on a known configuration and it'd better be an oss os with known tuning. Maybe some other, less fantastic form of such tests could be possible... Max _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
