* Segfault in fsck.reiser4
@ 2010-03-23 17:30 Jonáš Vidra
2010-03-23 20:26 ` Edward Shishkin
0 siblings, 1 reply; 9+ messages in thread
From: Jonáš Vidra @ 2010-03-23 17:30 UTC (permalink / raw)
To: ReiserFS mailing list
Hello!
I found a bug in fsck.reiser4 from reiser4progs-1.0.7. It segfaults when I
try to check my storage partition.
The FS is currently mounted read-only, as I need the data and I don't have
a spare disk.
I haven't noticed any other problems so far, the fsck was just a weekly
check.
I recompiled reiser4progs with debug statements and made a backtrace,
but I'm not skilled in these things, so let me know if additional info is
needed.
I've also packed the filesystem metadata, I can post them somewhere if you
want.
By the way, how do I find a filename by node number or key? Debugfs allows
me to search for nodes when I type a filename, but not vice versa.
I'd like to know which file caused the corruption.
The output from GDB is below.
(gdb) run
Starting program: /sbin/fsck.reiser4 /dev/sda7
*******************************************************************
This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
*******************************************************************
Fscking the /dev/sda7 block device.
Will check the consistency of the Reiser4 SuperBlock.
Will check the consistency of the Reiser4 FileSystem.
Continue?
(Yes/No): y
***** fsck.reiser4 started at Tue Mar 23 16:32:33 2010
Reiser4 fs was detected on /dev/sda7.
Master super block (16):
magic: ReIsEr4
blksize: 4096
format: 0x0 (format40)
uuid: 7e3c26ff-e382-4f6f-9686-ca06ff31c615
label: data
Format super block (17):
plugin: format40
description: Disk-format plugin.
version: 0
magic: ReIsEr40FoRmAt
mkfs id: 0x7c89491a
flushes: 0
blocks: 47640736
free blocks: 9067517
root block: 36345512
tail policy: 0x2 (smart)
next oid: 0x64883
file count: 6842
tree height: 5
key policy: LARGE
CHECKING THE STORAGE TREE
Read nodes 3394397
Nodes left in the tree 3394397
Leaves of them 3354276, Twigs of them 39373
Time interval: Tue Mar 23 16:32:53 2010 - Tue Mar 23 16:46:58 2010
CHECKING EXTENT REGIONS.
FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), item
(31), unit (7), [64744:4(FB):4d4f563042422e:6487d:0]: points to the
already used blocks, region [38491215..38497535].
FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), item
(35), unit (0), [64744:4(FB):4d4f563042442e:64881:0]: points to the
already used blocks, region [32036064..32036064].
FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), item
(35), unit (1), [64744:4(FB):4d4f563042442e:64881:0]: points to the
already used blocks, region [36296457..36296457].
FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), item
(35), unit (2), [64744:4(FB):4d4f563042442e:64881:0]: points to the
already used blocks, region [36345512..36345512].
FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), item
(35), unit (3), [64744:4(FB):4d4f563042442e:64881:0]: points to the
already used blocks, region [36425556..36425556].
FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453), item
(35), unit (4), [64744:4(FB):4d4f563042442e:64881:0]: points to the
already used blocks, region [38293910..38293910].
Read twigs 39373
Invaid extent pointers 6
Time interval: Tue Mar 23 16:46:58 2010 - Tue Mar 23 16:50:25 2010
CHECKING THE SEMANTIC TREE
FSCK: ccreg40_repair.c: 77: ccreg40_check_item: The file
[64744:4d4f563042442e:64882] (ccreg40), node [38551031], item [0]: item of
the wrong cluster size (-2147483648) found, Should be (65536).
Program received signal SIGSEGV, Segmentation fault.
0xb7f6f7d2 in aux_adler32 (adler=<value optimized out>, buff=0xbffe22ca
"", n=4294839597) at aux.c:194
(gdb) bt
#0 0xb7f6f7d2 in aux_adler32 (adler=<value optimized out>,
buff=0xbffe22ca "", n=4294839597) at aux.c:194
#1 0xb7f9ceb2 in ccreg40_check_crc (cc=0x8edf5f0, func=0,
data=0xbfffeb1c, mode=1 '\001') at ccreg40_repair.c:130
#2 ccreg40_check_cluster (cc=0x8edf5f0, func=0, data=0xbfffeb1c, mode=1
'\001') at ccreg40_repair.c:174
#3 ccreg40_check_struct (cc=0x8edf5f0, func=0, data=0xbfffeb1c, mode=1
'\001') at ccreg40_repair.c:271
#4 0xb7f34a4a in repair_object_check_struct (object=0x8edf5f0,
place_func=0, mode=<value optimized out>, data=0xbfffeb1c) at object.c:19
#5 0xb7f391ab in repair_semantic_check_struct (sem=0xbfffeb1c,
object=0x8edf5f0) at semantic.c:68
#6 0xb7f3ae26 in cb_object_traverse (parent=0x8e5ef40, entry=0xbfff4410,
data=0xbfffeb1c) at semantic.c:352
#7 0xb7f6791d in reiser4_object_traverse (object=0x8e5ef40,
open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at object.c:723
#8 0xb7f67959 in reiser4_object_traverse (object=0x8e614a0,
open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at object.c:731
#9 0xb7f67959 in reiser4_object_traverse (object=0x8e5baf0,
open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at object.c:731
#10 0xb7f67959 in reiser4_object_traverse (object=0x8e479e0,
open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at object.c:731
#11 0xb7f67959 in reiser4_object_traverse (object=0x80628e0,
open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at object.c:731
#12 0xb7f3a202 in repair_semantic (sem=0xbfffeb1c) at semantic.c:845
#13 0xb7f3cee8 in repair_check (repair=0xbfffee04) at repair.c:799
#14 0x0804b242 in main (argc=2, argv=Cannot access memory at address 0x8608
) at fsck.c:566
--
Jonáš Vidra
--
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Segfault in fsck.reiser4
2010-03-23 17:30 Segfault in fsck.reiser4 Jonáš Vidra
@ 2010-03-23 20:26 ` Edward Shishkin
2010-03-23 20:31 ` Edward Shishkin
2010-03-23 21:43 ` Jonáš Vidra
0 siblings, 2 replies; 9+ messages in thread
From: Edward Shishkin @ 2010-03-23 20:26 UTC (permalink / raw)
To: Jonáš Vidra; +Cc: ReiserFS mailing list
Jonáš Vidra wrote:
> Hello!
Hello.
>
> I found a bug in fsck.reiser4 from reiser4progs-1.0.7. It segfaults
> when I try to check my storage partition.
> The FS is currently mounted read-only, as I need the data and I don't
> have a spare disk.
> I haven't noticed any other problems so far, the fsck was just a
> weekly check.
>
> I recompiled reiser4progs with debug statements and made a backtrace,
> but I'm not skilled in these things, so let me know if additional info
> is needed.
> I've also packed the filesystem metadata, I can post them somewhere if
> you want.
Packed metadata won't help in this case.
The most efficient way is to provide me with a root access to your machine.
You have encountered a rare case of corruption, and it is important to
fix this
fsck bug properly.
>
> By the way, how do I find a filename by node number or key?
find - inum 64881
> Debugfs allows me to search for nodes when I type a filename, but not
> vice versa.
> I'd like to know which file caused the corruption.
What do you want to do with this file?
Thanks,
Edward.
>
> The output from GDB is below.
>
>
> (gdb) run
> Starting program: /sbin/fsck.reiser4 /dev/sda7
> *******************************************************************
> This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
> *******************************************************************
>
> Fscking the /dev/sda7 block device.
> Will check the consistency of the Reiser4 SuperBlock.
> Will check the consistency of the Reiser4 FileSystem.
> Continue?
> (Yes/No): y
> ***** fsck.reiser4 started at Tue Mar 23 16:32:33 2010
> Reiser4 fs was detected on /dev/sda7.
> Master super block (16):
> magic: ReIsEr4
> blksize: 4096
> format: 0x0 (format40)
> uuid: 7e3c26ff-e382-4f6f-9686-ca06ff31c615
> label: data
>
> Format super block (17):
> plugin: format40
> description: Disk-format plugin.
> version: 0
> magic: ReIsEr40FoRmAt
> mkfs id: 0x7c89491a
> flushes: 0
> blocks: 47640736
> free blocks: 9067517
> root block: 36345512
> tail policy: 0x2 (smart)
> next oid: 0x64883
> file count: 6842
> tree height: 5
> key policy: LARGE
>
>
> CHECKING THE STORAGE TREE
> Read nodes 3394397
> Nodes left in the tree 3394397
> Leaves of them 3354276, Twigs of them 39373
> Time interval: Tue Mar 23 16:32:53 2010 - Tue Mar 23 16:46:58
> 2010
> CHECKING EXTENT REGIONS.
> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453),
> item (31), unit (7), [64744:4(FB):4d4f563042422e:6487d:0]: points to
> the already used blocks, region [38491215..38497535].
> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453),
> item (35), unit (0), [64744:4(FB):4d4f563042442e:64881:0]: points to
> the already used blocks, region [32036064..32036064].
> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453),
> item (35), unit (1), [64744:4(FB):4d4f563042442e:64881:0]: points to
> the already used blocks, region [36296457..36296457].
> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453),
> item (35), unit (2), [64744:4(FB):4d4f563042442e:64881:0]: points to
> the already used blocks, region [36345512..36345512].
> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453),
> item (35), unit (3), [64744:4(FB):4d4f563042442e:64881:0]: points to
> the already used blocks, region [36425556..36425556].
> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453),
> item (35), unit (4), [64744:4(FB):4d4f563042442e:64881:0]: points to
> the already used blocks, region [38293910..38293910].
> Read twigs 39373
> Invaid extent pointers 6
> Time interval: Tue Mar 23 16:46:58 2010 - Tue Mar 23 16:50:25
> 2010
> CHECKING THE SEMANTIC TREE
> FSCK: ccreg40_repair.c: 77: ccreg40_check_item: The file
> [64744:4d4f563042442e:64882] (ccreg40), node [38551031], item [0]:
> item of the wrong cluster size (-2147483648) found, Should be (65536).
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7f6f7d2 in aux_adler32 (adler=<value optimized out>,
> buff=0xbffe22ca "", n=4294839597) at aux.c:194
>
> (gdb) bt
> #0 0xb7f6f7d2 in aux_adler32 (adler=<value optimized out>,
> buff=0xbffe22ca "", n=4294839597) at aux.c:194
> #1 0xb7f9ceb2 in ccreg40_check_crc (cc=0x8edf5f0, func=0,
> data=0xbfffeb1c, mode=1 '\001') at ccreg40_repair.c:130
> #2 ccreg40_check_cluster (cc=0x8edf5f0, func=0, data=0xbfffeb1c,
> mode=1 '\001') at ccreg40_repair.c:174
> #3 ccreg40_check_struct (cc=0x8edf5f0, func=0, data=0xbfffeb1c,
> mode=1 '\001') at ccreg40_repair.c:271
> #4 0xb7f34a4a in repair_object_check_struct (object=0x8edf5f0,
> place_func=0, mode=<value optimized out>, data=0xbfffeb1c) at object.c:19
> #5 0xb7f391ab in repair_semantic_check_struct (sem=0xbfffeb1c,
> object=0x8edf5f0) at semantic.c:68
> #6 0xb7f3ae26 in cb_object_traverse (parent=0x8e5ef40,
> entry=0xbfff4410, data=0xbfffeb1c) at semantic.c:352
> #7 0xb7f6791d in reiser4_object_traverse (object=0x8e5ef40,
> open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at
> object.c:723
> #8 0xb7f67959 in reiser4_object_traverse (object=0x8e614a0,
> open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at
> object.c:731
> #9 0xb7f67959 in reiser4_object_traverse (object=0x8e5baf0,
> open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at
> object.c:731
> #10 0xb7f67959 in reiser4_object_traverse (object=0x8e479e0,
> open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at
> object.c:731
> #11 0xb7f67959 in reiser4_object_traverse (object=0x80628e0,
> open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at
> object.c:731
> #12 0xb7f3a202 in repair_semantic (sem=0xbfffeb1c) at semantic.c:845
> #13 0xb7f3cee8 in repair_check (repair=0xbfffee04) at repair.c:799
> #14 0x0804b242 in main (argc=2, argv=Cannot access memory at address
> 0x8608
> ) at fsck.c:566
>
>
--
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Segfault in fsck.reiser4
2010-03-23 20:26 ` Edward Shishkin
@ 2010-03-23 20:31 ` Edward Shishkin
2010-03-23 21:43 ` Jonáš Vidra
1 sibling, 0 replies; 9+ messages in thread
From: Edward Shishkin @ 2010-03-23 20:31 UTC (permalink / raw)
To: Jonáš Vidra; +Cc: ReiserFS mailing list
Edward Shishkin wrote:
> Jonáš Vidra wrote:
>> Hello!
>
> Hello.
>
>>
>> I found a bug in fsck.reiser4 from reiser4progs-1.0.7. It segfaults
>> when I try to check my storage partition.
>> The FS is currently mounted read-only, as I need the data and I don't
>> have a spare disk.
>> I haven't noticed any other problems so far, the fsck was just a
>> weekly check.
>>
>> I recompiled reiser4progs with debug statements and made a backtrace,
>> but I'm not skilled in these things, so let me know if additional
>> info is needed.
>> I've also packed the filesystem metadata, I can post them somewhere
>> if you want.
>
> Packed metadata won't help in this case.
>
> The most efficient way is to provide me with a root access to your
> machine.
> You have encountered a rare case of corruption, and it is important to
> fix this
> fsck bug properly.
>
>>
>> By the way, how do I find a filename by node number or key?
>
> find - inum 64881
oops, I was wrong: the inode number of the corrupted file is 64882
in accordance with this fsck message:
FSCK: ccreg40_repair.c: 77: ccreg40_check_item: The file
[64744:4d4f563042442e:64882] (ccreg40), node [38551031], item [0]: item
of the wrong cluster size (-2147483648) found, Should be (65536).
>
>
>> Debugfs allows me to search for nodes when I type a filename, but not
>> vice versa.
>> I'd like to know which file caused the corruption.
>
> What do you want to do with this file?
>
> Thanks,
> Edward.
>
>>
>> The output from GDB is below.
>>
>>
>> (gdb) run
>> Starting program: /sbin/fsck.reiser4 /dev/sda7
>> *******************************************************************
>> This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
>> *******************************************************************
>>
>> Fscking the /dev/sda7 block device.
>> Will check the consistency of the Reiser4 SuperBlock.
>> Will check the consistency of the Reiser4 FileSystem.
>> Continue?
>> (Yes/No): y
>> ***** fsck.reiser4 started at Tue Mar 23 16:32:33 2010
>> Reiser4 fs was detected on /dev/sda7.
>> Master super block (16):
>> magic: ReIsEr4
>> blksize: 4096
>> format: 0x0 (format40)
>> uuid: 7e3c26ff-e382-4f6f-9686-ca06ff31c615
>> label: data
>>
>> Format super block (17):
>> plugin: format40
>> description: Disk-format plugin.
>> version: 0
>> magic: ReIsEr40FoRmAt
>> mkfs id: 0x7c89491a
>> flushes: 0
>> blocks: 47640736
>> free blocks: 9067517
>> root block: 36345512
>> tail policy: 0x2 (smart)
>> next oid: 0x64883
>> file count: 6842
>> tree height: 5
>> key policy: LARGE
>>
>>
>> CHECKING THE STORAGE TREE
>> Read nodes 3394397
>> Nodes left in the tree 3394397
>> Leaves of them 3354276, Twigs of them 39373
>> Time interval: Tue Mar 23 16:32:53 2010 - Tue Mar 23 16:46:58
>> 2010
>> CHECKING EXTENT REGIONS.
>> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453),
>> item (31), unit (7), [64744:4(FB):4d4f563042422e:6487d:0]: points to
>> the already used blocks, region [38491215..38497535].
>> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453),
>> item (35), unit (0), [64744:4(FB):4d4f563042442e:64881:0]: points to
>> the already used blocks, region [32036064..32036064].
>> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453),
>> item (35), unit (1), [64744:4(FB):4d4f563042442e:64881:0]: points to
>> the already used blocks, region [36296457..36296457].
>> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453),
>> item (35), unit (2), [64744:4(FB):4d4f563042442e:64881:0]: points to
>> the already used blocks, region [36345512..36345512].
>> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453),
>> item (35), unit (3), [64744:4(FB):4d4f563042442e:64881:0]: points to
>> the already used blocks, region [36425556..36425556].
>> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (36296453),
>> item (35), unit (4), [64744:4(FB):4d4f563042442e:64881:0]: points to
>> the already used blocks, region [38293910..38293910].
>> Read twigs 39373
>> Invaid extent pointers 6
>> Time interval: Tue Mar 23 16:46:58 2010 - Tue Mar 23 16:50:25
>> 2010
>> CHECKING THE SEMANTIC TREE
>> FSCK: ccreg40_repair.c: 77: ccreg40_check_item: The file
>> [64744:4d4f563042442e:64882] (ccreg40), node [38551031], item [0]:
>> item of the wrong cluster size (-2147483648) found, Should be (65536).
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0xb7f6f7d2 in aux_adler32 (adler=<value optimized out>,
>> buff=0xbffe22ca "", n=4294839597) at aux.c:194
>>
>> (gdb) bt
>> #0 0xb7f6f7d2 in aux_adler32 (adler=<value optimized out>,
>> buff=0xbffe22ca "", n=4294839597) at aux.c:194
>> #1 0xb7f9ceb2 in ccreg40_check_crc (cc=0x8edf5f0, func=0,
>> data=0xbfffeb1c, mode=1 '\001') at ccreg40_repair.c:130
>> #2 ccreg40_check_cluster (cc=0x8edf5f0, func=0, data=0xbfffeb1c,
>> mode=1 '\001') at ccreg40_repair.c:174
>> #3 ccreg40_check_struct (cc=0x8edf5f0, func=0, data=0xbfffeb1c,
>> mode=1 '\001') at ccreg40_repair.c:271
>> #4 0xb7f34a4a in repair_object_check_struct (object=0x8edf5f0,
>> place_func=0, mode=<value optimized out>, data=0xbfffeb1c) at
>> object.c:19
>> #5 0xb7f391ab in repair_semantic_check_struct (sem=0xbfffeb1c,
>> object=0x8edf5f0) at semantic.c:68
>> #6 0xb7f3ae26 in cb_object_traverse (parent=0x8e5ef40,
>> entry=0xbfff4410, data=0xbfffeb1c) at semantic.c:352
>> #7 0xb7f6791d in reiser4_object_traverse (object=0x8e5ef40,
>> open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at
>> object.c:723
>> #8 0xb7f67959 in reiser4_object_traverse (object=0x8e614a0,
>> open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at
>> object.c:731
>> #9 0xb7f67959 in reiser4_object_traverse (object=0x8e5baf0,
>> open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at
>> object.c:731
>> #10 0xb7f67959 in reiser4_object_traverse (object=0x8e479e0,
>> open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at
>> object.c:731
>> #11 0xb7f67959 in reiser4_object_traverse (object=0x80628e0,
>> open_func=0xb7f3abb7 <cb_object_traverse>, data=0xbfffeb1c) at
>> object.c:731
>> #12 0xb7f3a202 in repair_semantic (sem=0xbfffeb1c) at semantic.c:845
>> #13 0xb7f3cee8 in repair_check (repair=0xbfffee04) at repair.c:799
>> #14 0x0804b242 in main (argc=2, argv=Cannot access memory at address
>> 0x8608
>> ) at fsck.c:566
>>
>>
>
>
--
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Segfault in fsck.reiser4
2010-03-23 20:26 ` Edward Shishkin
2010-03-23 20:31 ` Edward Shishkin
@ 2010-03-23 21:43 ` Jonáš Vidra
2010-03-23 22:31 ` Edward Shishkin
1 sibling, 1 reply; 9+ messages in thread
From: Jonáš Vidra @ 2010-03-23 21:43 UTC (permalink / raw)
To: Edward Shishkin; +Cc: ReiserFS mailing list
Dne Tue, 23 Mar 2010 21:26:53 +0100 Edward Shishkin
<edward.shishkin@gmail.com> napsal(a):
> The most efficient way is to provide me with a root access to your
> machine.
> You have encountered a rare case of corruption, and it is important to
> fix this fsck bug properly.
Well …
I don't think that would be possible, but I'll see what I can do.
Several users have accounts on the machine, so even though they are just
family members, not corporate customers, I can't allow everyone in.
I'd like to help, so I'll try to arrange it somehow.
>> By the way, how do I find a filename by node number or key?
>
> find - inum 64881
Thanks. That's straightforward, shame on me for asking stupid questions.
>> I'd like to know which file caused the corruption.
>
> What do you want to do with this file?
I'd like to know if it is backed up somewhere, unique
or downloaded from the Internet or whatever.
I know I can't really trust *any* data on this partition anymore,
but I'd still like to know which files are the most likely to be lost.
--
Jonáš Vidra
--
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Segfault in fsck.reiser4
2010-03-23 21:43 ` Jonáš Vidra
@ 2010-03-23 22:31 ` Edward Shishkin
2010-03-24 8:54 ` Vidra.Jonas
0 siblings, 1 reply; 9+ messages in thread
From: Edward Shishkin @ 2010-03-23 22:31 UTC (permalink / raw)
To: Jonáš Vidra; +Cc: ReiserFS mailing list
Jonáš Vidra wrote:
> Dne Tue, 23 Mar 2010 21:26:53 +0100 Edward Shishkin
> <edward.shishkin@gmail.com> napsal(a):
>
>> The most efficient way is to provide me with a root access to your
>> machine.
>> You have encountered a rare case of corruption, and it is important
>> to fix this fsck bug properly.
>
> Well …
> I don't think that would be possible, but I'll see what I can do.
Segfault is caused by aux_adler32: offset (4294839597) is out of bounds..
Could you print and show us the structure "hint"?
> Several users have accounts on the machine, so even though they are just
> family members, not corporate customers, I can't allow everyone in.
> I'd like to help, so I'll try to arrange it somehow.
>
>
>>> By the way, how do I find a filename by node number or key?
>>
>> find - inum 64881
>
> Thanks. That's straightforward, shame on me for asking stupid questions.
>
>
>>> I'd like to know which file caused the corruption.
>>
>> What do you want to do with this file?
>
> I'd like to know if it is backed up somewhere, unique
> or downloaded from the Internet or whatever.
> I know I can't really trust *any* data on this partition anymore,
> but I'd still like to know which files are the most likely to be lost.
--
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Segfault in fsck.reiser4
2010-03-23 22:31 ` Edward Shishkin
@ 2010-03-24 8:54 ` Vidra.Jonas
2010-03-24 13:10 ` Edward Shishkin
0 siblings, 1 reply; 9+ messages in thread
From: Vidra.Jonas @ 2010-03-24 8:54 UTC (permalink / raw)
To: reiserfs-devel; +Cc: edward.shishkin
Dne Tue, 23 Mar 2010 23:31:48 +0100 Edward Shishkin <edward.shishkin@gmail.com> napsal(a):
> Segfault is caused by aux_adler32: offset (4294839597) is out of bounds..
> Could you print and show us the structure "hint"?
(gdb) print hint
No symbol "hint" in current context.
Am I doing it right or should I set a breakpoint somewhere before the crash?
--
Joná¹ Vidra, vidra.jonas@seznam.cz
--
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Segfault in fsck.reiser4
2010-03-24 8:54 ` Vidra.Jonas
@ 2010-03-24 13:10 ` Edward Shishkin
2010-03-27 8:38 ` Jonáš Vidra
0 siblings, 1 reply; 9+ messages in thread
From: Edward Shishkin @ 2010-03-24 13:10 UTC (permalink / raw)
To: Vidra.Jonas; +Cc: reiserfs-devel
Vidra.Jonas@seznam.cz wrote:
> Dne Tue, 23 Mar 2010 23:31:48 +0100 Edward Shishkin
> <edward.shishkin@gmail.com> napsal(a):
>
>> Segfault is caused by aux_adler32: offset (4294839597) is out of
>> bounds..
>> Could you print and show us the structure "hint"?
>
> (gdb) print hint
> No symbol "hint" in current context.
try to jump several levels up: the function ccreg40_check_cluster
has an argument ccreg40_hint_t *hint, it shouldn't be optimized.
>
> Am I doing it right or should I set a breakpoint somewhere before the
> crash?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Segfault in fsck.reiser4
2010-03-24 13:10 ` Edward Shishkin
@ 2010-03-27 8:38 ` Jonáš Vidra
2010-03-30 0:59 ` Edward Shishkin
0 siblings, 1 reply; 9+ messages in thread
From: Jonáš Vidra @ 2010-03-27 8:38 UTC (permalink / raw)
To: ReiserFS mailing list
Dne Wed, 24 Mar 2010 14:10:26 +0100 Edward Shishkin
<edward.shishkin@gmail.com> napsal(a):
> try to jump several levels up: the function ccreg40_check_cluster
> has an argument ccreg40_hint_t *hint, it shouldn't be optimized.
I'm working on it, but gdb is so slow and it needs constant attention,
so it'll take a while.
I'm not very skilled at this and I don't have much time.
But I've got other news: I found a file that causes an oops when read.
I was just tarring up everything that might still be left on the FS
when it happened. The FS is still readonly, I haven't umounted it yet.
The oops is probably not very useful, but here you are anyway:
Mar 27 01:55:01 [kernel] Kernel BUG at c10e0681 [verbose debug info
unavailable]
Mar 27 01:55:01 [kernel] Modules linked in: af_packet sco rfcomm bnep
l2cap crc16 acpi_cpufreq cpufreq_conservative cpufreq_powersave
cpufreq_userspace snd_hda_codec_realtek btusb snd_hda_intel bluetooth
snd_hda_codec snd_hwdep psb ath9k snd_pcm drm_psb uvcvideo snd_timer
mac80211 agpgart snd videodev v4l1_compat video ath rtc_cmos processor
soundcore backlight thermal rtc_core cfg80211 ehci_hcd output evdev
battery button ac rtc_lib uhci_hcd i2c_isch i2c_algo_bit snd_page_alloc
thermal_sys usbcore rfkill i2c_core atl1c hwmon unix
Mar 27 01:55:01 [kernel] Pid: 10097, comm: tar Not tainted
(2.6.32-gentoo-r5 #1) 1101HA
Mar 27 01:55:01 [kernel] EIP: 0060:[<c10e0681>] EFLAGS: 00010246 CPU: 0
Mar 27 01:55:01 [kernel] EIP is at do_readpage_ctail+0x2a1/0x367
Mar 27 01:55:01 [kernel] EAX: 00000000 EBX: 00000002 ECX: c1906880 EDX:
c00122b4
Mar 27 01:55:01 [kernel] ESI: 00000000 EDI: e573fcf0 EBP: e573fc94 ESP:
e573fc74
Mar 27 01:55:01 [kernel] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Mar 27 01:55:01 [kernel] 00000000 c1906880 c00122b4 0000040f 00000000
00000000 e573fcf0 c1906880
Mar 27 01:55:01 [kernel] <0> e573fcbc c10e0890 00000001 c1906880 00000000
c00122b4 00000000 c1906880
Mar 27 01:55:01 [kernel] <0> e573fdb0 c0012360 e573fcd8 c105d02f e6febd90
c10e0747 00000010 c0012360
Mar 27 01:55:01 [kernel] [<c10e0890>] ? ctail_readpages_filler+0x149/0x195
Mar 27 01:55:01 [kernel] [<c105d02f>] ? read_cache_pages+0x6d/0xca
Mar 27 01:55:01 [kernel] [<c10e0747>] ? ctail_readpages_filler+0x0/0x195
Mar 27 01:55:01 [kernel] [<c10e03d7>] ? readpages_ctail+0x29f/0x2a8
Mar 27 01:55:01 [kernel] [<c10d4030>] ? readpages_cryptcompress+0x36/0x5b
Mar 27 01:55:01 [kernel] [<c10c82d3>] ? reiser4_readpages+0x26/0x2e
Mar 27 01:55:01 [kernel] [<c10c82ad>] ? reiser4_readpages+0x0/0x2e
Mar 27 01:55:01 [kernel] [<c105cc54>] ?
__do_page_cache_readahead+0xeb/0x160
Mar 27 01:55:01 [kernel] [<c105cce0>] ? ra_submit+0x17/0x1c
Mar 27 01:55:01 [kernel] [<c105cef6>] ? ondemand_readahead+0x161/0x16d
Mar 27 01:55:01 [kernel] [<c105cf7a>] ?
page_cache_sync_readahead+0x16/0x1b
Mar 27 01:55:01 [kernel] [<c10580c7>] ? generic_file_aio_read+0x1fe/0x550
Mar 27 01:55:01 [kernel] [<c107857b>] ? do_sync_read+0xab/0xe9
Mar 27 01:55:01 [kernel] [<c10385c3>] ? autoremove_wake_function+0x0/0x33
Mar 27 01:55:01 [kernel] [<c10d3d37>] ? read_cryptcompress+0x5f/0x7e
Mar 27 01:55:01 [kernel] [<c10d2335>] ? reiser4_read_careful+0xa9/0xf1
Mar 27 01:55:01 [kernel] [<c10d228c>] ? reiser4_read_careful+0x0/0xf1
Mar 27 01:55:01 [kernel] [<c1078fa7>] ? vfs_read+0x87/0x118
Mar 27 01:55:01 [kernel] [<c10790d1>] ? sys_read+0x3b/0x60
Mar 27 01:55:01 [kernel] [<c1002b0f>] ? sysenter_do_call+0x12/0x26
Mar 27 01:55:01 [kernel] ---[ end trace 26ea3afca4e81c3e ]---
--
Jonáš Vidra
--
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Segfault in fsck.reiser4
2010-03-27 8:38 ` Jonáš Vidra
@ 2010-03-30 0:59 ` Edward Shishkin
0 siblings, 0 replies; 9+ messages in thread
From: Edward Shishkin @ 2010-03-30 0:59 UTC (permalink / raw)
To: Jonáš Vidra; +Cc: reiserfs-devel
[-- Attachment #1: Type: text/plain, Size: 1871 bytes --]
Jonáš Vidra wrote:
[...]
>
>
> The oops is probably not very useful, but here you are anyway:
This is very useful. The attached patch should fix this oops.
However, your partition remains inconsistent. I'll fix up fsck
a bit later..
Thanks,
Edward.
>
> Mar 27 01:55:01 [kernel] Kernel BUG at c10e0681 [verbose debug info
> unavailable]
[..]
> Mar 27 01:55:01 [kernel] [<c10e0890>] ?
> ctail_readpages_filler+0x149/0x195
> Mar 27 01:55:01 [kernel] [<c105d02f>] ? read_cache_pages+0x6d/0xca
> Mar 27 01:55:01 [kernel] [<c10e0747>] ? ctail_readpages_filler+0x0/0x195
> Mar 27 01:55:01 [kernel] [<c10e03d7>] ? readpages_ctail+0x29f/0x2a8
> Mar 27 01:55:01 [kernel] [<c10d4030>] ?
> readpages_cryptcompress+0x36/0x5b
> Mar 27 01:55:01 [kernel] [<c10c82d3>] ? reiser4_readpages+0x26/0x2e
> Mar 27 01:55:01 [kernel] [<c10c82ad>] ? reiser4_readpages+0x0/0x2e
> Mar 27 01:55:01 [kernel] [<c105cc54>] ?
> __do_page_cache_readahead+0xeb/0x160
> Mar 27 01:55:01 [kernel] [<c105cce0>] ? ra_submit+0x17/0x1c
> Mar 27 01:55:01 [kernel] [<c105cef6>] ? ondemand_readahead+0x161/0x16d
> Mar 27 01:55:01 [kernel] [<c105cf7a>] ?
> page_cache_sync_readahead+0x16/0x1b
> Mar 27 01:55:01 [kernel] [<c10580c7>] ?
> generic_file_aio_read+0x1fe/0x550
> Mar 27 01:55:01 [kernel] [<c107857b>] ? do_sync_read+0xab/0xe9
> Mar 27 01:55:01 [kernel] [<c10385c3>] ?
> autoremove_wake_function+0x0/0x33
> Mar 27 01:55:01 [kernel] [<c10d3d37>] ? read_cryptcompress+0x5f/0x7e
> Mar 27 01:55:01 [kernel] [<c10d2335>] ? reiser4_read_careful+0xa9/0xf1
> Mar 27 01:55:01 [kernel] [<c10d228c>] ? reiser4_read_careful+0x0/0xf1
> Mar 27 01:55:01 [kernel] [<c1078fa7>] ? vfs_read+0x87/0x118
> Mar 27 01:55:01 [kernel] [<c10790d1>] ? sys_read+0x3b/0x60
> Mar 27 01:55:01 [kernel] [<c1002b0f>] ? sysenter_do_call+0x12/0x26
> Mar 27 01:55:01 [kernel] ---[ end trace 26ea3afca4e81c3e ]---
>
>
[-- Attachment #2: reiser4-do_readpage_ctail-fixup.patch --]
[-- Type: text/x-patch, Size: 1162 bytes --]
Hanle the case of orphan unprepped disk cluster:
return EIO and suggest fsck the partition instead of BUG_ON(1).
Signed-off-by: Edward Shishkin <edward.shishkin@gmail.com>
---
fs/reiser4/plugin/item/ctail.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
--- linux-2.6.33-reiser4.orig/fs/reiser4/plugin/item/ctail.c
+++ linux-2.6.33-reiser4/fs/reiser4/plugin/item/ctail.c
@@ -649,9 +649,11 @@ int do_readpage_ctail(struct inode * ino
ret = ctail_read_disk_cluster(clust, inode, page, mode);
assert("edward-212", PageLocked(page));
- if (ret)
+ if (ret) {
+ ClearPageUptodate(page);
+ SetPageError(page);
return ret;
-
+ }
/* refresh bytes */
to_page = pbytes(page_index(page), inode);
if (to_page == 0) {
@@ -669,7 +671,13 @@ int do_readpage_ctail(struct inode * ino
switch (clust->dstat) {
case UNPR_DISK_CLUSTER:
- BUG_ON(1);
+ warning("edward-1563",
+ "orphan unprepped cluster %lu (inode %lli). Fsck?",
+ clust->index,
+ (unsigned long long)get_inode_oid(inode));
+ ClearPageUptodate(page);
+ SetPageError(page);
+ return -EIO;
case TRNC_DISK_CLUSTER:
/*
* Race with truncate!
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2010-03-30 0:59 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-03-23 17:30 Segfault in fsck.reiser4 Jonáš Vidra
2010-03-23 20:26 ` Edward Shishkin
2010-03-23 20:31 ` Edward Shishkin
2010-03-23 21:43 ` Jonáš Vidra
2010-03-23 22:31 ` Edward Shishkin
2010-03-24 8:54 ` Vidra.Jonas
2010-03-24 13:10 ` Edward Shishkin
2010-03-27 8:38 ` Jonáš Vidra
2010-03-30 0:59 ` Edward Shishkin
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.