Re: missing /var/mail
On Fri, 1 Feb 2008 15:36:55 -0500
"Douglas A. Tutty" <dtutty@porchlight.ca> 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
> one.
>
> Other convoluted ways of ensuring HA.
>
> Data that is _on_the_disk_, which has already survived reboots,
> shouldn't just vanish after a power failure. How would a different ext3
> journal option address that?
In my previous reply to your message, I forgot to include this link,
which also implies that 'Journal' might have helped in a case such as
yours [0]:
<Quote>
ordered mode
This is, by far, the most used default method by most linux flavours.
metadata and data blocks are bundled into "transactions" of either 1K,
2K, or 4K sizes. when it is time for the filesystem to write this
transaction onto the disk, the data blocks of the said transaction are
written first onto the filesystem. metadata is committed to journal
only after the data blocks are written out.
Generally, integrity provided by ordered mode writes are sufficient
enough. That being said, if you are sure that most of your continuous
writes to a certain filesystem is to overwrite existing files, rather
than appending them, this is certainly not the right journaling mode
for you. Here's why - ordered mode does not keep persistent information
about which blocks were written, and which blocks weren’t. Or, it does
not perform ordered transactions. It is left to your drive's write
cache to write to the list of blocks supplied whenever the cache can
get to do that. In other words, it does not ensure that the blocks are
actually written out into the drive in an orderly manner, as it uses
your drive's cache.
What does this mean? Well, if your system craps out while it was
overwriting a file, and your drive's cache did not finish updating all
the blocks cited by the JBD API, you may end up having blocks which
were not updated at all. Or, in short, theoretically, you may have some
old data in your file after a system crash.>
</Quote>
[0]
http://evuraan.blogspot.com/2007/01/speeding-up-ext3-filesystems.html
> Doug.
Celejar
--
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
Reply to: