Re: missing /var/mail
On Fri, 1 Feb 2008 15:36:55 -0500
"Douglas A. Tutty" <firstname.lastname@example.org> wrote:
> On Fri, Feb 01, 2008 at 01:25:59PM -0600, Ron Johnson wrote:
> > Use a storage method that doesn't put all eggs in one basket.
> What filesystem doesn't put all the eggs in one basket? Sure I'm
> annoyed that I lost data. It could have been prevented with:
> 2 or 3 UPS (in case one fails at the same time as the power)
> setting up the fetchmail/exim4 so that retreived mail went to
> two boxes (on another pair if UPS) at the same time instead of
> Other convoluted ways of ensuring HA.
> Data that is _on_the_disk_, which has already survived reboots,
> Ordered (medium risk)
> shouldn't just vanish after a power failure. How would a different ext3
> journal option address that?
>From the ext3 Wikipedia article :
Ordered (medium risk)
Only metadata is journaled; file contents are not, but it's
guaranteed that file contents are written to disk before associated
metadata is marked as committed in the journal. This is the default on
many Linux distributions. If there is a power outage or kernel panic
while a file is being written or appended to, the journal will indicate
the new file or appended data has not been "committed", so it will be
purged by the cleanup process. (This appends and new files have the
same level of integrity protection as the "journaled" level.) However,
files being overwritten can be corrupted because the original version
of the file is not stored. Thus it's possible to end up with a file in
an intermediate state between new and old, without enough information
to restore either one or the other (the new data never made it to disk
completely, and the old data is not stored anywhere). Even worse, the
intermediate state might intersperse old and new data, because the
order of the write is left up to the disk's hardware. 
So data can apparently be lost if the file was being overwritten
during the power failure.
The 'Journal' mode is alleged to be safer than the default 'Ordered'
Journal (lowest risk)
Both metadata and file contents are written to the journal before
being committed to the main file system. Because the journal is
relatively continuous on disk, this can improve performance in some
circumstances. In other cases, performance gets worse because the data
must be written twice - once to the journal, and once to the main part
of the filesystem.
I'm actually somewhat confused about the issue; this page implies that
'Ordered' actually provides the same level of data security as
6. Ext3, protector of data
And now, we finally get to see how the ext3 filesystem effectively
provides both metadata and data journaling, avoiding the data
corruption problem I described earlier in this article. In fact, ext3
actually has two methods to ensure data and metadata integrity.
Originally, ext3 was designed to perform full data and metadata
journaling. In this mode (called "data=journal" mode), the JBD journals
all changes to the filesystem, whether they are made to data or
metadata. Because both data and metadata are journaled, JBD can use the
journal to bring both metadata and data back to a consistent state. The
drawback of full data journaling is that it can be slow, although you
can reduce the performance penalty by setting up a relatively large
Recently, a new journaling mode has been added to ext3 that provides
the benefits of full journaling but without introducing a severe
performance penalty. This new mode works by journaling metadata only.
However, the ext3 filesystem driver keeps track of the particular data
blocks that correspond with each metadata update, grouping them into a
single entity called a transaction. When a transaction is applied to
the filesystem proper, the data blocks are written to disk first. Once
they are written, the metadata changes are then written to the journal.
By using this technique (called "data=ordered" mode), ext3 can provide
data and metadata consistency, even though only metadata changes are
recorded in the journal. ext3 uses this mode by default.
The manpages of 'mount' and 'tune2fs' discuss ext's three
journaling modes, but they don't really explain the pros and cons.
I really don't know much about filesystems; if anyone can point me in
the right direction, it will be appreciated.
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator