Hi, sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] > On 3 Mar 2014, at 3:41am, romtek <rom...@gmail.com> wrote: > [...] > > Here's a SQLite engineer writing about the same thing: section 3.1 of > > <https://www.sqlite.org/howtocorrupt.html> > > Your disk hardware, its firmware driver, the OS's storage driver, the OS's > file system and the OS file API all get a chance to pretend they're doing > 'sync()' but actually just return 'done it'. And if even one of them lies, > synchronisation appears to happen instantly and your software runs faster. A > virtualising system is another chance to do processing faster by lying about > synchronisation. And unless something crashes or you have a power failure > nobody will ever find out.
Another way to bust your data is to rely on RAID 5 or 6 or similar, at least if the software does not take special care. When those mechanisms, updating a block always results in at least 2 disk writes: The data block and the checksum block. There's a small time window where only one of those blocks physically reached the disk. Now, when the power fails during said time window, and the third disk fails, it's content will be restored using the new data block and the old checksum (or vice versa), leaving your data garbled. Best regards Markus Schaber CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com CODESYS forum: http://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
