Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
| Comment: | Enhancements to the ext3 barrier problem description in lockingv3.html. |
|---|---|
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA1: |
a1de10679ba9247f6af639ea2424b080 |
| User & Date: | drh 2010-07-13 16:51:51 |
Context
|
2010-07-13
| ||
| 23:51 | Updates to the WAL documentation. check-in: 8cdaccbb90 user: drh tags: trunk | |
| 16:51 | Enhancements to the ext3 barrier problem description in lockingv3.html. check-in: a1de10679b user: drh tags: trunk | |
| 14:50 | Fix a typo on the temp_store_directory pragma documentation. check-in: 40fa307f4e user: drh tags: trunk | |
Changes
Changes to pages/lockingv3.in.
471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 |
reports that Windows sometimes chooses to ignore FlushFileBuffers() for
unspecified reasons. The author cannot verify any of these reports.
But if they are true, it means that database corruption is a possibility
following an unexpected power loss. These are hardware and/or operating
system bugs that SQLite is unable to defend against.
</p>
<p>In the Linux <a href="http://en.wikipedia.org/wiki/Ext3">ext3</a>
file system, if the filesystem is not mounted with the "barrier=1" option
in the <a href="http://en.wikipedia.org/wiki/fstab">/etc/fstab</a>
then filesystem corruption can occur following a power loss or OS crash.
We are told that most Linux distributions do not use barrier=1 and so most
Linux distributions are vulnerable to this problem. Note that this is an
operating system issue and that there is nothing that SQLite can do to
work around it.
<a href="http://ozlabs.org/~rusty/index.cgi/tech/2009-10-20.html">
Other database engines</a> have also run into this same problem.</p>
<p>
|
> > > > > | > |
471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 |
reports that Windows sometimes chooses to ignore FlushFileBuffers() for unspecified reasons. The author cannot verify any of these reports. But if they are true, it means that database corruption is a possibility following an unexpected power loss. These are hardware and/or operating system bugs that SQLite is unable to defend against. </p> <tcl>hd_fragment {ext3-barrier-problem} {the ext3 barrier problem}</tcl> <p>In the Linux <a href="http://en.wikipedia.org/wiki/Ext3">ext3</a> file system, if the filesystem is not mounted with the "barrier=1" option in the <a href="http://en.wikipedia.org/wiki/fstab">/etc/fstab</a> and the disk drive write cache is enabled then filesystem corruption can occur following a power loss or OS crash. Various ext3 experts <a href="http://www.redhat.com/archives/ext3-users/2010-July/msg00001.html"> confirm this behavior</a>. We are told that most Linux distributions do not use barrier=1 and and do not disable the write cache so most Linux distributions are vulnerable to this problem. Note that this is an operating system issue and that there is nothing that SQLite can do to work around it. <a href="http://ozlabs.org/~rusty/index.cgi/tech/2009-10-20.html"> Other database engines</a> have also run into this same problem.</p> <p> |