FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 02-01-2008, 04:20 PM
"Douglas A. Tutty"
 
Default missing /var/mail

Hello all,

I know that this is pretty useless, but.

I was just reading my mail when the power went out. There were some
important mails there. At the time, they were in /var/mail/dtutty

On reboot, it said that it was replaying the journal (ext3) for /var
with no errors reported.

After reboot, /var/mail/dtutty is empty (another user's mail is still
there, the only differece being that they weren't using mutt at the
time).

There is nothing in lost+found.

Possibly unrelated: on boot, the POST said that there was a keyboard
error. I had to power down the PSU to get the box to boot.

Any idea what happend? I figure that there's no way to get the data
back.

Doug.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-01-2008, 05:14 PM
Ron Johnson
 
Default missing /var/mail

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/01/08 11:20, Douglas A. Tutty wrote:
> Hello all,
>
> I know that this is pretty useless, but.
>
> I was just reading my mail when the power went out.

No UPS?

> There were some
> important mails there. At the time, they were in /var/mail/dtutty
>
> On reboot, it said that it was replaying the journal (ext3) for /var
> with no errors reported.
>
> After reboot, /var/mail/dtutty is empty (another user's mail is still
> there, the only differece being that they weren't using mutt at the
> time).

If your email were in Maildir or mh format, you'd have only lost the
one mail you were reading.

Not that that does you any good now, but something to think about
for the future.

> There is nothing in lost+found.
>
> Possibly unrelated: on boot, the POST said that there was a keyboard
> error. I had to power down the PSU to get the box to boot.
>
> Any idea what happend? I figure that there's no way to get the data
> back.

Restore from tape? Of course that would only help if you baked it
up on a *very* regular basis. And you'd still lose everything since
the previous backup...

- --
Ron Johnson, Jr.
Jefferson LA USA

PETA - People Eating Tasty Animals
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHo2GaS9HxQb37XmcRArGYAJ9fT32xYW6nEtYIbV2HlI RNiZNQiQCgt4Y1
LjadPo45kbNC84U+W/V8qKc=
=dTp/
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-01-2008, 05:23 PM
"Douglas A. Tutty"
 
Default missing /var/mail

On Fri, Feb 01, 2008 at 12:14:50PM -0600, Ron Johnson wrote:
> On 02/01/08 11:20, Douglas A. Tutty wrote:
> > I was just reading my mail when the power went out.
> No UPS?
No

The question is, why did I lose the data? Isn't the journal in ext3
supposed to prevent this from happening?

Doug.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-01-2008, 05:42 PM
Ron Johnson
 
Default missing /var/mail

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/01/08 12:23, Douglas A. Tutty wrote:
> On Fri, Feb 01, 2008 at 12:14:50PM -0600, Ron Johnson wrote:
>> On 02/01/08 11:20, Douglas A. Tutty wrote:
>>> I was just reading my mail when the power went out.
>> No UPS?
> No
>
> The question is, why did I lose the data? Isn't the journal in ext3
> supposed to prevent this from happening?

In it's standard form, no. It only journals metadata. Still,
though, the filename still should have been there, even if it was
zero bytes in length.

Since mbox is a single file, and in order to delete an email it's
got to go thru partial-copies, copy-backs and what not, maybe the
power blinked just at the wrong moment.

That's why mbox/mbx is not a good "daily use" format.

- --
Ron Johnson, Jr.
Jefferson LA USA

PETA - People Eating Tasty Animals
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHo2giS9HxQb37XmcRAt3MAKCM5x2GrQ+vHlpjqXYNOW nHmyUmWQCgkIhF
NgFnvL43VQiKBumQLMPRWm8=
=bjnA
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-01-2008, 05:49 PM
Sven Joachim
 
Default missing /var/mail

On 2008-02-01 19:23 +0100, Douglas A. Tutty wrote:

> The question is, why did I lose the data? Isn't the journal in ext3
> supposed to prevent this from happening?

No. The purpose of a journal is to ensure data integrity, not to make
sure the disk is always in sync with the file data cache. If you want
that, you have to mount the filesystem with the `sync' option (which
will result in a big performance loss).

My hunch is that your mails never made it to the disk and are lost for
good. FWIW, I'd recommend to leave mails on the server, if you are
using POP3, to ensure they aren't lost in case of a power failure.

Sven


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-01-2008, 05:59 PM
"Douglas A. Tutty"
 
Default missing /var/mail

On Fri, Feb 01, 2008 at 07:49:22PM +0100, Sven Joachim wrote:
> On 2008-02-01 19:23 +0100, Douglas A. Tutty wrote:
>
> > The question is, why did I lose the data? Isn't the journal in ext3
> > supposed to prevent this from happening?
>
> No. The purpose of a journal is to ensure data integrity, not to make
> sure the disk is always in sync with the file data cache. If you want
> that, you have to mount the filesystem with the `sync' option (which
> will result in a big performance loss).
>
> My hunch is that your mails never made it to the disk and are lost for
> good. FWIW, I'd recommend to leave mails on the server, if you are
> using POP3, to ensure they aren't lost in case of a power failure.
>

They did make it to disk since it was an ongoing thread and some I left
there from last night.

Doug.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-01-2008, 06:00 PM
John Hasler
 
Default missing /var/mail

Sven writes:
> I'd recommend to leave mails on the server, if you are using POP3, to
> ensure they aren't lost in case of a power failure.

Because, as we all know, ISPs _never_ lose mail.
--
John Hasler


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-01-2008, 06:25 PM
Ron Johnson
 
Default missing /var/mail

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/01/08 12:49, Sven Joachim wrote:
> On 2008-02-01 19:23 +0100, Douglas A. Tutty wrote:
>
>> The question is, why did I lose the data? Isn't the journal in ext3
>> supposed to prevent this from happening?
>
> No. The purpose of a journal is to ensure data integrity, not to make
> sure the disk is always in sync with the file data cache. If you want
> that, you have to mount the filesystem with the `sync' option (which
> will result in a big performance loss).
>
> My hunch is that your mails never made it to the disk and are lost for
> good. FWIW, I'd recommend to leave mails on the server, if you are
> using POP3, to ensure they aren't lost in case of a power failure.

Use a storage method that doesn't put all eggs in one basket.

- --
Ron Johnson, Jr.
Jefferson LA USA

PETA - People Eating Tasty Animals
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHo3JHS9HxQb37XmcRApJ/AJ99SIz46CRlFpL0cq8YJyBYUqmtTQCfTeO0
RA5/k87fU8OlylOm4vHaBCM=
=lgrA
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-01-2008, 07:36 PM
"Douglas A. Tutty"
 
Default missing /var/mail

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?

I've got ext3 over LVM over raid1 for the first time. Over the years
I've had far more (10:1 ratio) ext2/3 errors than I've had hard drive
failures.


Doug.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-01-2008, 08:02 PM
Celejar
 
Default 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,
> 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 [0]:

<Quote>

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.[5] [6]

</Quote>

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'
mode:

<Quote>

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.

</Quote>

I'm actually somewhat confused about the issue; this page implies that
'Ordered' actually provides the same level of data security as
'Journal' [1]:

<Quote>

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
journal.

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.

</Quote>

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.

[0]
http://en.wikipedia.org/wiki/Ext3 [1]
http://www.gentoo.org/doc/en/articles/afig-ct-ext3-intro.xml

> Doug.

Celejar
--
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 02:58 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org