Documentation Source Text

Check-in [a1de10679b]
Login

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: a1de10679ba9247f6af639ea2424b080d2588fe9
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
Hide Diffs Unified Diffs Ignore Whitespace Patch

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>