Data corrupted after crash

Data corrupted after crash

[Sebastian Kaps]

Hi!

I'm running Linux 2.4.18 with ReiserFS and no additional patches
applied.
Some minutes ago my machine was shut off due to a power failure. After
rebooting I've noticed that at least one file was corrupted.
I had gnus, opera and some other apps running before the crash and now
my opera bookmarks file "~/.opera/opera6.adr" looks like a mixture of
~/.newsrc.eld (used by gnus), the original bookmarks file and some other
stuff what seems to be Opera's history data.

Isn't journalling supposed to prevent such things?

"dmesg|grep -i reiser" after the reboot says:
,----
| reiserfs: checking transaction log (device 21:03) ...
| reiserfs: replayed 38 transactions in 2 seconds
| ReiserFS version 3.6.25
`----
-- 
Ciao, Sebastian

* HP:    http://www.sauerland.de/~toyland/          PGP-Key available

Re: Data corrupted after crash

[Oleg Drokin]

Hello!

On Thu, Jul 25, 2002 at 07:54:24PM +0200, Sebastian Kaps wrote:

> I had gnus, opera and some other apps running before the crash and now
> my opera bookmarks file "~/.opera/opera6.adr" looks like a mixture of
> ~/.newsrc.eld (used by gnus), the original bookmarks file and some other
> stuff what seems to be Opera's history data.
> Isn't journalling supposed to prevent such things?

No. Reiserfs provides only metadata journaling. So the data itself still may
be damaged (data still may be damaged even in case of full data journaling
just because there is no API for applications to control transactions
currently)

Bye,
    Oleg

Re: Data corrupted after crash

[Sebastian Kaps]

Hi Oleg!

Am Fri, 26 Jul 2002 13:19:43 +0400 schriebst Du:

> No. Reiserfs provides only metadata journaling. So the data itself still may
> be damaged (data still may be damaged even in case of full data journaling
> just because there is no API for applications to control transactions
> currently)

Okay, thanks to you and Kuba for pointing this out.

-- 
Ciao, Sebastian

* HP:    http://www.sauerland.de/~toyland/          PGP-Key available

Re: Data corrupted after crash

[Sam Vilain]

Oleg Drokin <green@namesys.com> wrote:

> No. Reiserfs provides only metadata journaling. So the data itself still
> may be damaged (data still may be damaged even in case of full data
> journaling just because there is no API for applications to control
> transactions currently)

Still, data journalling would be nice.  I must say that when reiserfs gets
the power taken out from under it, you don't half end up with your
recently worked on files containing pieces of each other.

With data journalling, this would not be a problem; although of course
files could end up in a half-updated state, which to a given application
may as well be corrupted.  It would be a bit slower, unless your journal is on a seperate device, but that can't be helped.
--
   Sam Vilain, sam@vilain.net     WWW:
http://sam.vilain.net/    7D74 2A09 B2D3 C30F F78E      GPG:
http://sam.vilain.net/sam.asc    278A A425 30A9 05B5 2F13

You've one mouth and two ears...use them in that proportion.
 - anon.

Re: Data corrupted after crash

[Oleg Drokin]

Hello!

On Fri, Jul 26, 2002 at 02:44:05PM +0100, Sam Vilain wrote:

> > No. Reiserfs provides only metadata journaling. So the data itself still
> > may be damaged (data still may be damaged even in case of full data
> > journaling just because there is no API for applications to control
> > transactions currently)
> Still, data journalling would be nice.  I must say that when reiserfs gets

We hope to get it in 2.4.20, thanks to great work by Chris.

Bye,
    Oleg

Re: Data corrupted after crash

[Chris Mason]

On Fri, 2002-07-26 at 09:44, Sam Vilain wrote:
> Oleg Drokin <green@namesys.com> wrote:
> 
> > No. Reiserfs provides only metadata journaling. So the data itself still
> > may be damaged (data still may be damaged even in case of full data
> > journaling just because there is no API for applications to control
> > transactions currently)
> 
> Still, data journalling would be nice.  I must say that when reiserfs gets
> the power taken out from under it, you don't half end up with your
> recently worked on files containing pieces of each other.
> 
> With data journalling, this would not be a problem; although of course
> files could end up in a half-updated state, which to a given application
> may as well be corrupted.  It would be a bit slower, unless your journal is on a seperate device, but that can't be helped.

Actually, data journaling doesn't give you much more protection than
ordered write mode.  This is because userspace has no way to influence
which data gets included into a given transaction.  So, if you write
16k, it might become 1 atomic unit or 4, you have no way of knowing.

Both ordered data mode and journaled data mode make sure that new blocks
added to a file are flushed before the transaction commits.  This makes
sure you don't get garbage in the file.

journaled data mode also make sure that a single block is written as an
atomic unit.  If your 4k block spans 8 512 byte sectors on the drive,
you know after a crash all 8 will either be updated or not changed at
all.

journaled data mode also gives you complete ordering of data writes with
respect to the metadata.  So, if a single process does this:

create(file1)
write(file1)
rename(file1, file2)
write(file2)

You know that each step along the chain will either include the previous
step or not be done at all.  In other words, you know the rename won't
happen without the data in file1 being updated.

Most people don't really need either feature, and data=ordered is faster
most of the time.  data journaled mode can be much faster for
synchronous data writes though.

You can try the current data logging patches at:

ftp.suse.com/pub/people/mason/patches/data-logging

I've just uploaded data-logging-20.diff, which should fix a bug where
some writes were not properly ordered if you crashed right after a
truncate or tail conversion (it might take the mirror a few minutes to
update).  

-chris