Database failure despite filesystem recovery

[Ben Finney]

On 16-Feb-2005, Matthias Andree wrote:
> OK. My scoop of this is:
> 
> 1. Berkeley DB uses database pages that are larger than hard disk drive
>    blocks.
> 
> 2. No Linux file system and device driver in production quality and
>    default settings guarantees atomic writes of Berkeley DB pages.
> 
> 3. ext3fs with data=journal mount option SHOULD be able to write memory
>    page size (4k) atomically AFAIR.
> 
> 4. The power losses you reported on 2005-02-05 caused partial writes to
>    database pages that a subsequent regular recovery did not
>    detect. (Below more.)
> 
> 5. The message contains a particular token, here "Prozac", that is on
>    a broken database page.

On 16-Feb-2005, Matthias Andree wrote:
> I must honestly say that this is supposed to be a rare event, and it
> appears you've fallen prey to the "enable write cache by default"
> behavior of disk drives.

I believe you that this is supposed to be rare; ideally, impossible.
How can we make it closer to that ideal?

Should bogofilter not continue to operate even in the presence of write
caching, especially if filesystem-level recovery is successful?

-- 
 \          "I used to be an airline pilot. I got fired because I kept |
  `\       locking the keys in the plane. They caught me on an 80 foot |
_o__)                 stepladder with a coathanger."  -- Steven Wright |
Ben Finney <ben at benfinney.id.au>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://www.bogofilter.org/pipermail/bogofilter/attachments/20050217/1d07512a/attachment.sig>