不完整的磁盘刷新-线性代数及其应用中文版下载

9.0 会导致完蛋的事情 SQLite 的原子提交机制已经被证明是健壮的。但它也可能被一些不完整的操作系统实现所陷害。本节描述一些会在 掉电或系统崩溃下会导致 SQLite 数据损坏的情形 9.1 缺乏文件锁实现 SQLite 通过文件系统的锁来实现在同一时刻只有一个进程及一个数据库联接能够修改数据库。文件锁机制由 VFS 层实现，不同的操作系统具有不同的实现方式。SQLite 依赖于这种实现的正确性。如果在某种情况下，二个或更多 进程能够在同一时间写同一个数据库文件，这将会没有什么好果子吃的。 我们已经接收到报告说 windows 的网络文件系统及 NFS 的锁存在一些微妙的缺陷。我们不能验证这些报告。但是 因为网络文件系统本身实现锁很困难，所以我们没有理由怀疑这些报告。首先，既然性能不足，建议你不要在网络 文件系统中使用 SQLite。但是如果你不得不使用一个网络文件来保存 SQLite 的数据文件，那们考虑采用其他的锁机 制来防止本身的文件锁机制出错时发生多个进程同时写一个数据文件的现象。 苹果MacOSX预装的 SQLite版本已经扩展拥有一种可供选择的锁策略可以工作在苹果支持的所有网络文件系统上。 这些苹果使用的扩展在多个进程在同时访问数据库文件时工作得很好。不幸的是，这些锁机制并不互相排斥，如果 一个进程使用 AFP 锁去访问文件，而另一个进程（或许是另一台机器）使用 dot-file 锁去访问这个文件，那么这二 个进程可能发生冲突，因为 AFP 锁并不排斥 dot-file 锁，反之亦然。 9.2 不完整的磁盘刷新 SQLite 在 unix 使 fsysnc,在 win32 下面使用 FlushFileBuffers,用来将文件内容同步到磁盘中（节 3.7 及节 3.10）。不幸 的是，我们也收到报告，在许多平台上，这二者都没有象广告中宣称的那样工作。我们听说 FlushFileBuffersc 在一 些 windows 版本中，可以通过修改注册表，能够完全禁止其工作。我们也被告之，Linux 的一些早先版本，他们的 一些文件系统中的 fsync 完全是一个空操作。即使是 FlushFileBuffers 及 fsync 被告之可以工作的系统中，IDE 硬盘 经常会撒谎说数据已经写入到盘片中，其实还只是存在状态可变的磁盘控制器缓存中。 在 Mac 你可设置下面项： PRAGMA fullfsync=ON;