Reiser4 corruption (fsck.reiser4 broken?)

Reiser4 corruption (fsck.reiser4 broken?)

[Roman I Khimov]

[-- Attachment #1: Type: text/plain, Size: 3031 bytes --]

Well, quite an interesting feeling when you lost 80G of music and 100G of 
other great stuff... Refreshing, I should say.

OK, let me explain in detail what's happening here. I have a 250Gb HDD in 
external IEEE1394 aka Firewire enclosure. It's encrypted via dm-crypt (no 
partitions, from block #0 to the end) and, you can guess it, I've placed a 
Reiser4 partition on it.

I'm using -mm tree kernels and right now I have two of them for my system - 
2.6.15-rc5-mm3 and 2.6.15-mm4. The first one worked just fine for me, but 
with second I've been experiencing some strange "Badness" from kernel block 
level, which at that moment I had no time to save/report/analyse. That was 
several times when using that external HDD. I have no logs for it, sorry 
(I'm a bad user, I know...)

So, despite of that "Badness" everything worked fine, I was using one or 
another kernel depending on my mood. Until today, when I thought "man, are 
you sure that everything is OK? Maybe it's time to make fsck on that drive, 
you know, there is something you don't want to lose there..."

So, I've ran fsck.reiser4 on dm-mapped drive (with kernel 2.6.15-rc5-mm3) 
and it said that there is 1 inconsistency found. Not that bad for kernel 
"Badness", it recommended to run itself with "--build-fs" parameter, I did 
so and... Lots of output on the screen, some ~38000 files found and ~36000 
files lost&found. Mounting my drive, what's here?

rik@pu-erh:/media/ext-250/lost+found> ls | wc -l
34799

And, of course, lots of files just disappeared. I see some of them in 
"lost+found" directory, but some of them are corrupted - I've tried to play 
one with "suspicious" size and mplayer just quit seconds later with lots of 
"[mpeg4 @ 0x84b4e88]marker does not match f_code" errors. That one was just 
fine week or so ago.

As I've said, I'm a bad user with no logs for any of that actions (didn't 
expected that one inconsistency can be source of such badness). I'm not 
asking for help with data restoring (although I would try anything to do 
that), it's all my fault, but the question is - how can I help debugging 
the situation (if there is something to debug at all), what info may I 
provide (I'm very useful without logs, I know...)?

Seems to me fsck.reiser4 is not that good at restoring file systems, because 
in those fragments in "lost+found" I clearly see parts of files that were 
just fine yesterday.

Reiser4progs version 1.0.4.

[ searching a bit... ]

Cool, newest version is 1.0.5. My fault... again. So, just tell me that it's 
fixed in this version - I'll laugh at myself a little... ;-)

-- 
                            Roman
 ,---------------------------. ,--------------------------.
/     http://www.3os.ru/      V    http://www.osrc.info/   \         .o.
\    mailto: rik@3os.ru       ^   mailto: rik@osrc.info    /         ..o
 `---------------------------' `--------------------------'          ooo
gpg --recv-keys 0xE5E055C3 --keyserver hkp://subkeys.pgp.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Reiser4 corruption (fsck.reiser4 broken?)

[Hans Reiser]

Our fsck guy (vitaly) is on vacation, I am really sorry to tell you
this.  Can you keep the drive around until he gets back?

Hans

Roman I Khimov wrote:

>Well, quite an interesting feeling when you lost 80G of music and 100G of 
>other great stuff... Refreshing, I should say.
>
>OK, let me explain in detail what's happening here. I have a 250Gb HDD in 
>external IEEE1394 aka Firewire enclosure. It's encrypted via dm-crypt (no 
>partitions, from block #0 to the end) and, you can guess it, I've placed a 
>Reiser4 partition on it.
>
>I'm using -mm tree kernels and right now I have two of them for my system - 
>2.6.15-rc5-mm3 and 2.6.15-mm4. The first one worked just fine for me, but 
>with second I've been experiencing some strange "Badness" from kernel block 
>level, which at that moment I had no time to save/report/analyse. That was 
>several times when using that external HDD. I have no logs for it, sorry 
>(I'm a bad user, I know...)
>
>So, despite of that "Badness" everything worked fine, I was using one or 
>another kernel depending on my mood. Until today, when I thought "man, are 
>you sure that everything is OK? Maybe it's time to make fsck on that drive, 
>you know, there is something you don't want to lose there..."
>
>So, I've ran fsck.reiser4 on dm-mapped drive (with kernel 2.6.15-rc5-mm3) 
>and it said that there is 1 inconsistency found. Not that bad for kernel 
>"Badness", it recommended to run itself with "--build-fs" parameter, I did 
>so and... Lots of output on the screen, some ~38000 files found and ~36000 
>files lost&found. Mounting my drive, what's here?
>
>rik@pu-erh:/media/ext-250/lost+found> ls | wc -l
>34799
>
>And, of course, lots of files just disappeared. I see some of them in 
>"lost+found" directory, but some of them are corrupted - I've tried to play 
>one with "suspicious" size and mplayer just quit seconds later with lots of 
>"[mpeg4 @ 0x84b4e88]marker does not match f_code" errors. That one was just 
>fine week or so ago.
>
>As I've said, I'm a bad user with no logs for any of that actions (didn't 
>expected that one inconsistency can be source of such badness). I'm not 
>asking for help with data restoring (although I would try anything to do 
>that), it's all my fault, but the question is - how can I help debugging 
>the situation (if there is something to debug at all), what info may I 
>provide (I'm very useful without logs, I know...)?
>
>Seems to me fsck.reiser4 is not that good at restoring file systems, because 
>in those fragments in "lost+found" I clearly see parts of files that were 
>just fine yesterday.
>
>Reiser4progs version 1.0.4.
>
>[ searching a bit... ]
>
>Cool, newest version is 1.0.5. My fault... again. So, just tell me that it's 
>fixed in this version - I'll laugh at myself a little... ;-)
>
>  
>

Re: Reiser4 corruption (fsck.reiser4 broken?)

[Roman I Khimov]

[-- Attachment #1: Type: text/plain, Size: 3429 bytes --]

24 января 2006 23:23 | Hans Reiser:
> Our fsck guy (vitaly) is on vacation, I am really sorry to tell you
> this.  Can you keep the drive around until he gets back?

OK, I've just turned it off, so I won't touch it until that.

> Roman I Khimov wrote:
>
>> Well, quite an interesting feeling when you lost 80G of music and 100G
>> of other great stuff... Refreshing, I should say.
>>
>> OK, let me explain in detail what's happening here. I have a 250Gb HDD
>> in external IEEE1394 aka Firewire enclosure. It's encrypted via
>> dm-crypt (no partitions, from block #0 to the end) and, you can guess
>> it, I've placed a Reiser4 partition on it.
>>
>> I'm using -mm tree kernels and right now I have two of them for my
>> system - 2.6.15-rc5-mm3 and 2.6.15-mm4. The first one worked just fine
>> for me, but with second I've been experiencing some strange "Badness"
>> from kernel block level, which at that moment I had no time to
>> save/report/analyse. That was several times when using that external
>> HDD. I have no logs for it, sorry (I'm a bad user, I know...)
>>
>> So, despite of that "Badness" everything worked fine, I was using one
>> or another kernel depending on my mood. Until today, when I thought
>> "man, are you sure that everything is OK? Maybe it's time to make fsck
>> on that drive, you know, there is something you don't want to lose
>> there..."
>>
>> So, I've ran fsck.reiser4 on dm-mapped drive (with kernel
>> 2.6.15-rc5-mm3) and it said that there is 1 inconsistency found. Not
>> that bad for kernel "Badness", it recommended to run itself with
>> "--build-fs" parameter, I did so and... Lots of output on the screen,
>> some ~38000 files found and ~36000 files lost&found. Mounting my
>> drive, what's here?
>>
>> rik@pu-erh:/media/ext-250/lost+found> ls | wc -l
>> 34799
>>
>> And, of course, lots of files just disappeared. I see some of them in
>> "lost+found" directory, but some of them are corrupted - I've tried to
>> play one with "suspicious" size and mplayer just quit seconds later
>> with lots of "[mpeg4 @ 0x84b4e88]marker does not match f_code" errors.
>> That one was just fine week or so ago.
>>
>> As I've said, I'm a bad user with no logs for any of that actions
>> (didn't expected that one inconsistency can be source of such
>> badness). I'm not asking for help with data restoring (although I
>> would try anything to do that), it's all my fault, but the question is
>> - how can I help debugging the situation (if there is something to
>> debug at all), what info may I provide (I'm very useful without logs,
>> I know...)?
>>
>> Seems to me fsck.reiser4 is not that good at restoring file systems,
>>  because in those fragments in "lost+found" I clearly see parts of
>> files that were just fine yesterday.
>>
>> Reiser4progs version 1.0.4.
>>
>> [ searching a bit... ]
>>
>> Cool, newest version is 1.0.5. My fault... again. So, just tell me that
>> it's fixed in this version - I'll laugh at myself a little... ;-)

-- 
                            Roman
 ,---------------------------. ,--------------------------.
/     http://www.3os.ru/      V    http://www.osrc.info/   \         .o.
\    mailto: rik@3os.ru       ^   mailto: rik@osrc.info    /         ..o
 `---------------------------' `--------------------------'          ooo
gpg --recv-keys 0xE5E055C3 --keyserver hkp://subkeys.pgp.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Reiser4 corruption (fsck.reiser4 broken?)

[Jake Maciejewski]

Someone correct me if I'm wrong, but kernels since 2.6.11-5 have the new
plugin set which isn't supported by reiser4progs 1.0.4, so fscking with
1.0.4 was probably a big mistake.

On Tue, 2006-01-24 at 22:57 +0300, Roman I Khimov wrote:
> Well, quite an interesting feeling when you lost 80G of music and 100G of 
> other great stuff... Refreshing, I should say.
> 
> OK, let me explain in detail what's happening here. I have a 250Gb HDD in 
> external IEEE1394 aka Firewire enclosure. It's encrypted via dm-crypt (no 
> partitions, from block #0 to the end) and, you can guess it, I've placed a 
> Reiser4 partition on it.
> 
> I'm using -mm tree kernels and right now I have two of them for my system - 
> 2.6.15-rc5-mm3 and 2.6.15-mm4. The first one worked just fine for me, but 
> with second I've been experiencing some strange "Badness" from kernel block 
> level, which at that moment I had no time to save/report/analyse. That was 
> several times when using that external HDD. I have no logs for it, sorry 
> (I'm a bad user, I know...)
> 
> So, despite of that "Badness" everything worked fine, I was using one or 
> another kernel depending on my mood. Until today, when I thought "man, are 
> you sure that everything is OK? Maybe it's time to make fsck on that drive, 
> you know, there is something you don't want to lose there..."
> 
> So, I've ran fsck.reiser4 on dm-mapped drive (with kernel 2.6.15-rc5-mm3) 
> and it said that there is 1 inconsistency found. Not that bad for kernel 
> "Badness", it recommended to run itself with "--build-fs" parameter, I did 
> so and... Lots of output on the screen, some ~38000 files found and ~36000 
> files lost&found. Mounting my drive, what's here?
> 
> rik@pu-erh:/media/ext-250/lost+found> ls | wc -l
> 34799
> 
> And, of course, lots of files just disappeared. I see some of them in 
> "lost+found" directory, but some of them are corrupted - I've tried to play 
> one with "suspicious" size and mplayer just quit seconds later with lots of 
> "[mpeg4 @ 0x84b4e88]marker does not match f_code" errors. That one was just 
> fine week or so ago.
> 
> As I've said, I'm a bad user with no logs for any of that actions (didn't 
> expected that one inconsistency can be source of such badness). I'm not 
> asking for help with data restoring (although I would try anything to do 
> that), it's all my fault, but the question is - how can I help debugging 
> the situation (if there is something to debug at all), what info may I 
> provide (I'm very useful without logs, I know...)?
> 
> Seems to me fsck.reiser4 is not that good at restoring file systems, because 
> in those fragments in "lost+found" I clearly see parts of files that were 
> just fine yesterday.
> 
> Reiser4progs version 1.0.4.
> 
> [ searching a bit... ]
> 
> Cool, newest version is 1.0.5. My fault... again. So, just tell me that it's 
> fixed in this version - I'll laugh at myself a little... ;-)
> 
-- 
Jake Maciejewski <maciejej@msoe.edu>

Re: Reiser4 corruption (fsck.reiser4 broken?)

[Hans Reiser]

That means we need to invent a mechanism for avoiding this.  I suggest
we put the version of the appropriate progs in the super block, and
change that version every time progs  is updated, and have progs refuse
to run unless forced if it is older than that version in the super block. 

Vitaly, if you have some more clever idea, let me know.

Hans

Jake Maciejewski wrote:

>Someone correct me if I'm wrong, but kernels since 2.6.11-5 have the new
>plugin set which isn't supported by reiser4progs 1.0.4, so fscking with
>1.0.4 was probably a big mistake.
>
>On Tue, 2006-01-24 at 22:57 +0300, Roman I Khimov wrote:
>  
>
>>Well, quite an interesting feeling when you lost 80G of music and 100G of 
>>other great stuff... Refreshing, I should say.
>>
>>OK, let me explain in detail what's happening here. I have a 250Gb HDD in 
>>external IEEE1394 aka Firewire enclosure. It's encrypted via dm-crypt (no 
>>partitions, from block #0 to the end) and, you can guess it, I've placed a 
>>Reiser4 partition on it.
>>
>>I'm using -mm tree kernels and right now I have two of them for my system - 
>>2.6.15-rc5-mm3 and 2.6.15-mm4. The first one worked just fine for me, but 
>>with second I've been experiencing some strange "Badness" from kernel block 
>>level, which at that moment I had no time to save/report/analyse. That was 
>>several times when using that external HDD. I have no logs for it, sorry 
>>(I'm a bad user, I know...)
>>
>>So, despite of that "Badness" everything worked fine, I was using one or 
>>another kernel depending on my mood. Until today, when I thought "man, are 
>>you sure that everything is OK? Maybe it's time to make fsck on that drive, 
>>you know, there is something you don't want to lose there..."
>>
>>So, I've ran fsck.reiser4 on dm-mapped drive (with kernel 2.6.15-rc5-mm3) 
>>and it said that there is 1 inconsistency found. Not that bad for kernel 
>>"Badness", it recommended to run itself with "--build-fs" parameter, I did 
>>so and... Lots of output on the screen, some ~38000 files found and ~36000 
>>files lost&found. Mounting my drive, what's here?
>>
>>rik@pu-erh:/media/ext-250/lost+found> ls | wc -l
>>34799
>>
>>And, of course, lots of files just disappeared. I see some of them in 
>>"lost+found" directory, but some of them are corrupted - I've tried to play 
>>one with "suspicious" size and mplayer just quit seconds later with lots of 
>>"[mpeg4 @ 0x84b4e88]marker does not match f_code" errors. That one was just 
>>fine week or so ago.
>>
>>As I've said, I'm a bad user with no logs for any of that actions (didn't 
>>expected that one inconsistency can be source of such badness). I'm not 
>>asking for help with data restoring (although I would try anything to do 
>>that), it's all my fault, but the question is - how can I help debugging 
>>the situation (if there is something to debug at all), what info may I 
>>provide (I'm very useful without logs, I know...)?
>>
>>Seems to me fsck.reiser4 is not that good at restoring file systems, because 
>>in those fragments in "lost+found" I clearly see parts of files that were 
>>just fine yesterday.
>>
>>Reiser4progs version 1.0.4.
>>
>>[ searching a bit... ]
>>
>>Cool, newest version is 1.0.5. My fault... again. So, just tell me that it's 
>>fixed in this version - I'll laugh at myself a little... ;-)
>>
>>    
>>

Re: Reiser4 corruption (fsck.reiser4 broken?)

[Roman I Khimov]

[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]

24 января 2006 23:50 | Jake Maciejewski:
> Someone correct me if I'm wrong, but kernels since 2.6.11-5 have the new
> plugin set which isn't supported by reiser4progs 1.0.4, so fscking with
> 1.0.4 was probably a big mistake.

I'm looking at Reiser4progs Changelog, this line:

	Handle new (crc related) fields in plugin set correctly.

from 2005-06-28 (post 1.0.4 changes) looks interesting. Seems that I'm not 
so good at following reiserfs-list, because I knew about changes, but 
somehow forgot to upgrade to 1.0.5 (and I can even remember why - at the 
time it was released I wasn't using Reiser4, only looking at it from safe 
Reiser3 /home, that was converted to Reiser4 in November). Cool... When 
will I finally learn to be careful? ;-)

Sorry for the noise...

-- 
                            Roman
 ,---------------------------. ,--------------------------.
/     http://www.3os.ru/      V    http://www.osrc.info/   \         .o.
\    mailto: rik@3os.ru       ^   mailto: rik@osrc.info    /         ..o
 `---------------------------' `--------------------------'          ooo
gpg --recv-keys 0xE5E055C3 --keyserver hkp://subkeys.pgp.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Reiser4 corruption (fsck.reiser4 broken?)

[Boyd Waters]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]


On Jan 24, 2006, at 2:28 PM, Roman I Khimov wrote:

> . Cool... When will I finally learn to be careful? ;-)
>
> Sorry for the noise...


Well, it wasn't noise for me --- I was just about to hurt myself on a  
use case identical to the one that you describe. (I lost all of my  
data from our "living room" mac mini, but now it's being backed up to  
a Reiser filesystem on a linux host via rsync.)

Thanks very much for sharing your (painful) experience!

~ boyd

Boyd Waters
Socorro, New Mexico


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2361 bytes --]

Re: Reiser4 corruption (fsck.reiser4 broken?)

[Barry K. Nathan]

On 1/24/06, Jake Maciejewski <maciejej@msoe.edu> wrote:
> Someone correct me if I'm wrong, but kernels since 2.6.11-5 have the new
> plugin set which isn't supported by reiser4progs 1.0.4, so fscking with
> 1.0.4 was probably a big mistake.

Uh... this is bad. reiser4progs 1.0.4 is what ships with the current
Debian release:
http://packages.debian.org/stable/admin/reiser4progs

(A couple of weeks ago, I had a reiser4 filesystem that needed
fscking, and reiser4progs 1.0.4's fsck would claim that it fixed the
filesystem with --build-fs, but running it again would show that the
corruption was still there -- I had to manually compile 1.0.5 and use
that in order to actually fix the filesystem.)

Maybe I should file a bug report with Debian about this (ideally with
the goal of getting a reiser4progs 1.0.5 update package for Debian
stable)...
--
-Barry K. Nathan <barryn@pobox.com>