„Too many iterations“ and fsck.reiser4 failure

„Too many iterations“ and fsck.reiser4 failure

[Andrej Podzimek]

Hello,

my laptop system has been in use with Reiser v4 for half a year or so. There
may have been some unexpected restarts and system crashes during that
time... KDE refused to start today. This time it was not just a usual
problem with user permissions. This is what I found in kernel.log:

Jun  9 12:23:38 xandrej reiser4[kbuildsycoca(3104)]: traverse_tree
(fs/reiser4/search.c:689)[nikita-1481]:
Jun  9 12:23:38 xandrej WARNING: Too many iterations: 128
Jun  9 12:23:38 xandrej reiser4[kbuildsycoca(3104)]: traverse_tree
(fs/reiser4/search.c:689)[nikita-1481]:
Jun  9 12:23:38 xandrej WARNING: Too many iterations: 256
Jun  9 12:23:38 xandrej reiser4[kbuildsycoca(3104)]: traverse_tree
(fs/reiser4/search.c:689)[nikita-1481]:
Jun  9 12:23:38 xandrej WARNING: Too many iterations: 512
Jun  9 12:23:38 xandrej reiser4[kbuildsycoca(3104)]: traverse_tree
(fs/reiser4/search.c:689)[nikita-1481]:
Jun  9 12:23:38 xandrej WARNING: Too many iterations: 1024
Jun  9 12:23:38 xandrej reiser4[kbuildsycoca(3104)]: traverse_tree
(fs/reiser4/search.c:689)[nikita-1481]:
Jun  9 12:23:38 xandrej WARNING: Too many iterations: 2048
Jun  9 12:23:38 xandrej reiser4[kbuildsycoca(3104)]: traverse_tree
(fs/reiser4/search.c:689)[nikita-1481]:
Jun  9 12:23:38 xandrej WARNING: Too many iterations: 4096
Jun  9 12:23:38 xandrej reiser4[kbuildsycoca(3104)]: traverse_tree
(fs/reiser4/search.c:689)[nikita-1481]:
Jun  9 12:23:38 xandrej WARNING: Too many iterations: 8192
Jun  9 12:23:38 xandrej reiser4[kbuildsycoca(3104)]: traverse_tree
(fs/reiser4/search.c:689)[nikita-1481]:
Jun  9 12:23:38 xandrej WARNING: Too many iterations: 16384
Jun  9 12:23:38 xandrej reiser4[kbuildsycoca(3104)]: traverse_tree
(fs/reiser4/search.c:689)[nikita-1481]:
Jun  9 12:23:38 xandrej WARNING: Too many iterations: 32768
Jun  9 12:23:38 xandrej reiser4[kbuildsycoca(3104)]: traverse_tree
(fs/reiser4/search.c:689)[nikita-1481]:
Jun  9 12:23:38 xandrej WARNING: Too many iterations: 65536
Jun  9 12:23:39 xandrej reiser4[kbuildsycoca(3104)]: traverse_tree
(fs/reiser4/search.c:689)[nikita-1481]:
Jun  9 12:23:39 xandrej WARNING: Too many iterations: 131072
Jun  9 12:23:39 xandrej reiser4[kbuildsycoca(3104)]: traverse_tree
(fs/reiser4/search.c:689)[nikita-1481]:
Jun  9 12:23:39 xandrej WARNING: Too many iterations: 262144
Jun  9 12:23:40 xandrej reiser4[kbuildsycoca(3104)]: traverse_tree
(fs/reiser4/search.c:722)[nikita-373]:
Jun  9 12:23:40 xandrej WARNING: reiser-2018: Too many iterations. Tree
corrupted, or (less likely) starvation occurring.: level: 4, lock_level: 2,
stop_level: 1 lock_mode: read, bias: left-slant
Jun  9 12:23:40 xandrej reiser4[kbuildsycoca(3104)]: tail2extent
(fs/reiser4/plugin/file/tail_conversion.c:516)[nikita-2282]:
Jun  9 12:23:40 xandrej WARNING: Partial conversion of 2426179: -5

Running fsck.reiser4 revealed corruption on all of my Reiser4 volumes. All
of them could be fixed, except for /home. :-( I ran fsck.reiser4 --build-fs
--build-sb. Everything went just fine until the sematic tree scan. It got
stuck at 99% with intensive disk usage. After about 10 minutes, the program
ended with an error message („operational error“ or something of that kind).
(Just one line, no further details.)

The hard drive is a relatively recent Seagate Momentus 100 GB, 7200 RPM,
2,5", IDE, checked with smartctl regularly. The drive doesn't seem to be the
cause of this...

However, after the (probably unfinished) disk scan, I could still mount the
/home partition and KDE started just fine this time. The file system is
probably not in a consistent state right now. What could I do to stop
further corruption? What scan options should I use?

I am using ArchLinux and the reiser4progs package supplied with the distro.

Best regards,

Andrej Podzimek
-- 
View this message in context: http://www.nabble.com/%E2%80%9EToo-many-iterations%E2%80%9C-and-fsck.reiser4-failure-tp17734422p17734422.html
Sent from the ReiserFS - General mailing list archive at Nabble.com.

--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: „Too many iterations“ and fsck.reiser4 failure

[Edward Shishkin]

Andrej Podzimek wrote:
> Hello,
>   
Hello

> my laptop system has been in use with Reiser v4 for half a year or so.

Please, make sure that you are using the latest version of reiser4:
there was a bug which could cause data corruption:
http://marc.info/?l=reiserfs-devel&m=120914767218498&w=2

>  There
> may have been some unexpected restarts and system crashes during that
> time... KDE refused to start today. This time it was not just a usual
> problem with user permissions. This is what I found in kernel.log:
>
> Jun  9 12:23:38 xandrej reiser4[kbuildsycoca(3104)]: traverse_tree
> (fs/reiser4/search.c:689)[nikita-1481]:
> Jun  9 12:23:38 xandrej WARNING: Too many iterations: 128
>   
[...]
> (fs/reiser4/search.c:722)[nikita-373]:
> Jun  9 12:23:40 xandrej WARNING: reiser-2018: Too many iterations. Tree
> corrupted, or (less likely) starvation occurring.: level: 4, lock_level: 2,
> stop_level: 1 lock_mode: read, bias: left-slant
> Jun  9 12:23:40 xandrej reiser4[kbuildsycoca(3104)]: tail2extent
> (fs/reiser4/plugin/file/tail_conversion.c:516)[nikita-2282]:
> Jun  9 12:23:40 xandrej WARNING: Partial conversion of 2426179: -5
>
> Running fsck.reiser4 revealed corruption on all of my Reiser4 volumes. All
> of them could be fixed, except for /home. :-( I ran fsck.reiser4 --build-fs
> --build-sb. Everything went just fine until the sematic tree scan. It got
> stuck at 99% with intensive disk usage. After about 10 minutes, the program
> ended with an error message („operational error“ or something of that kind).
> (Just one line, no further details.)
>
>   

This is a problem in fsck, and I can not promise to fix it quickly.

Would you please pack the metadata of your /home by
debugfs.reiser4 -P /dev/xxx | gzip > meta.gz
and let me download the file meta.gz

Thanks,
Edward.

> The hard drive is a relatively recent Seagate Momentus 100 GB, 7200 RPM,
> 2,5", IDE, checked with smartctl regularly. The drive doesn't seem to be the
> cause of this...
>
> However, after the (probably unfinished) disk scan, I could still mount the
> /home partition and KDE started just fine this time. The file system is
> probably not in a consistent state right now. What could I do to stop
> further corruption? What scan options should I use?
>
> I am using ArchLinux and the reiser4progs package supplied with the distro.
>
> Best regards,
>
> Andrej Podzimek
>   

--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: „Too many iterations“ and fsck.reiser4 failure

[Andrej Podzimek]

> Please, make sure that you are using the latest version of reiser4:
> there was a bug which could cause data corruption:
> http://marc.info/?l=reiserfs-devel&m=120914767218498&w=2

I am using Vanilla 2.6.24.7 (with Reiser4 patchset, of course). Maybe I should upgrade to 2.6.25.x... The bug seems to be quite recent.

> Would you please pack the metadata of your /home by
> debugfs.reiser4 -P /dev/xxx | gzip > meta.gz
> and let me download the file meta.gz

Yes, here it is: http://andrej.podzimek.org/meta.gz

Regards,

Andrej

Re: „Too many iterations“ and fsck.reiser4 failure

[Edward Shishkin]

Andrej Podzimek wrote:
>> Please, make sure that you are using the latest version of reiser4:
>> there was a bug which could cause data corruption:
>> http://marc.info/?l=reiserfs-devel&m=120914767218498&w=2
>
> I am using Vanilla 2.6.24.7 (with Reiser4 patchset, of course). Maybe
> I should upgrade to 2.6.25.x... The bug seems to be quite recent.
>
>> Would you please pack the metadata of your /home by
>> debugfs.reiser4 -P /dev/xxx | gzip > meta.gz
>> and let me download the file meta.gz
>
> Yes, here it is: http://andrej.podzimek.org/meta.gz
>

Your fs looks consistent, just --build-fs produces false alarm.
I'll take a look..