Re: Reiser4 problems

Re: Reiser4 problems

[Nikita Danilov]

Hans Reiser writes:
 > Nick Piggin wrote:
 > 
 > > Hi Hans,
 > > Sorry to report this - I know you had said there were problems with the
 > > latest snapshot, and you almost certainly have hit this problem. I'll

Surprisingly not.

 > > report just in case:
 > >
 > > kernel 2.6.0-test7. ext3 system drive, Reiser4 SCSI test drive. I get a
 > > lot of SCSI I/O errors moments into untarring a test image onto the new
 > > Reiser4 filesystem. Created with default options. Mounted with noatime,
 > > nodiratime. Reiserfs soon panics.

Can you send us relevant parts of the system log: SCSI errors and panic?

 > >
 > > Badblocks shows the drive to be OK. ext2 fares alright. Let me know if
 > > you would like more info.
 > >
 > > Best regards,
 > > Nick
 > >

Nikita.

 > >
 > >
 > >
 > 
 > Nikita will respond to this on Monday, ok?  Thanks,
 > 
 > -- 
 > Hans
 > 
 > 

Re: Reiser4 problems

[Nick Piggin]

Nikita Danilov wrote:

>Hans Reiser writes:
> > Nick Piggin wrote:
> > 
> > > Hi Hans,
> > > Sorry to report this - I know you had said there were problems with the
> > > latest snapshot, and you almost certainly have hit this problem. I'll
>
>Surprisingly not.
>
> > > report just in case:
> > >
> > > kernel 2.6.0-test7. ext3 system drive, Reiser4 SCSI test drive. I get a
> > > lot of SCSI I/O errors moments into untarring a test image onto the new
> > > Reiser4 filesystem. Created with default options. Mounted with noatime,
> > > nodiratime. Reiserfs soon panics.
>
>Can you send us relevant parts of the system log: SCSI errors and panic?
>
>

loading reiser4 bitmap......done (117 jiffies)
SCSI error : <0 0 2 0> return code = 0x70000
end_request: I/O error, dev sda, sector 2311
SCSI error : <0 0 2 0> return code = 0x70000
end_request: I/O error, dev sda, sector 3335
SCSI error : <0 0 2 0> return code = 0x70000
end_request: I/O error, dev sda, sector 271
SCSI error : <0 0 2 0> return code = 0x70000
end_request: I/O error, dev sda, sector 1295

it continues like this for quite a while, then

SCSI error : <0 0 2 0> return code = 0x70000
end_request: I/O error, dev sda, sector 384496
SCSI error : <0 0 2 0> return code = 0x70000
end_request: I/O error, dev sda, sector 385520
SCSI error : <0 0 2 0> return code = 0x70000
end_request: I/O error, dev sda, sector 386544
SCSI error : <0 0 2 0> return code = 0x70000
end_request: I/O error, dev sda, sector 387568
SCSI error : <0 0 2 0> return code = 0x70000
end_request: I/O error, dev sda, sector 388592
reiser4[ktxnmgrd:run(510)]: reiser4_handle_error 
(fs/reiser4/vfs_ops.c:1446)[foo bar-42]:
reiser4 panicked cowardly: Filesystem error occured
 
------------[ cut here ]------------
kernel BUG at fs/reiser4/debug.c:73!
invalid operand: 0000 [#1]
CPU:    0
EIP:    0060:[<c0253f40>]    Not tainted
EFLAGS: 00010246
EIP is at reiser4_do_panic+0x1f0/0x2c0
eax: 00000000   ebx: d4a0bdf8   ecx: d467f7f8   edx: 00000001
esi: d477aefc   edi: 00000000   ebp: d49c3d40   esp: d49c3d20
ds: 007b   es: 007b   ss: 0068
Process ktxnmgrd:run (pid: 510, threadinfo=d49c2000 task=d49039b0)
Stack: d4a0bdf8 00000001 c040fc66 d49c3d4c c03fb32c c040f9d2 000005a6 
c040fc42
       d49c3d64 c028a9f4 c040fc4c 00000001 c040fc42 c03fb32c c040f9d2 
000005a6
       d686da78 d49c3d94 c02815d9 d686da78 d49c3db4 d686da78 00000000 
d49c3e58
Call Trace:
 [<c028a9f4>] .text.lock.vfs_ops+0x0/0x2c
 [<c02815d9>] finish_all_fq+0x169/0x170
 [<c0281613>] current_atom_finish_all_fq+0x33/0x150
 [<c010d616>] do_IRQ+0x1f6/0x460
 [<c0269c31>] current_atom_complete_writes+0x11/0x30
 [<c0269e28>] commit_current_atom+0x1d8/0x480
 [<c026bee7>] try_commit_txnh+0x1d7/0x310
 [<c0123fc8>] schedule+0x298/0x990
 [<c026c058>] commit_txnh+0x38/0x230
 [<c026768f>] txn_end+0x3f/0x50
 [<c026b055>] commit_some_atoms+0x695/0x880
 [<c026179b>] init_context+0xbb/0x100
 [<c01246c0>] default_wake_function+0x0/0x30
 [<c0283faf>] scan_mgr+0x2f/0x45
 [<c02c7f66>] snprintf+0x26/0x30
 [<c028345d>] ktxnmgrd+0x2dd/0x630
 [<c010a776>] ret_from_fork+0x6/0x14
 [<c0283180>] ktxnmgrd+0x0/0x630
 [<c010774d>] kernel_thread_helper+0x5/0x18
 
Code: 0f 0b 49 00 d8 f0 40 c0 c7 04 24 a9 af 42 c0 b8 40 99 50 c0


This happens very soon into the following command:
ropeable:/mnt/test# tar xvf /home/backup/backup.tar
1-ext2/
1-ext2/lost+found/
1-ext2/test1

1-ext2 is a reiser4 mount point, not actually ext2 of course.
test1 is a 256MB file of all zeros.

filesystem created with default options, mounted with noatime,nodiratime.
I'll try without the extra mount options now.

Re: Reiser4 problems

[Nick Piggin]

Nick Piggin wrote:

>
> filesystem created with default options, mounted with noatime,nodiratime.
> I'll try without the extra mount options now.
>

still no good

Re: Reiser4 problems

[Hans Reiser]

Nick Piggin wrote:

>
>
> Nick Piggin wrote:
>
>>
>> filesystem created with default options, mounted with 
>> noatime,nodiratime.
>> I'll try without the extra mount options now.
>>
>
> still no good
>
>
>
>
It is hardware error....

-- 
Hans

Re: Reiser4 problems

[Nick Piggin]

Hans Reiser wrote:

> Nick Piggin wrote:
>
>>
>>
>> Nick Piggin wrote:
>>
>>>
>>> filesystem created with default options, mounted with 
>>> noatime,nodiratime.
>>> I'll try without the extra mount options now.
>>>
>>
>> still no good
>>
>>
>>
>>
> It is hardware error....


Perhaps. However the same hardware can take heavy stressing with ext2,
reports no errors with "badblocks", has never had any data corruption or
any SCSI error reported unless using Reiser4, etc etc.

Re: Reiser4 problems

[Hans Reiser]

Nick Piggin wrote:

>
>
> Hans Reiser wrote:
>
>> Nick Piggin wrote:
>>
>>>
>>>
>>> Nick Piggin wrote:
>>>
>>>>
>>>> filesystem created with default options, mounted with 
>>>> noatime,nodiratime.
>>>> I'll try without the extra mount options now.
>>>>
>>>
>>> still no good
>>>
>>>
>>>
>>>
>> It is hardware error....
>
>
>
> Perhaps. However the same hardware can take heavy stressing with ext2,
> reports no errors with "badblocks", has never had any data corruption or
> any SCSI error reported unless using Reiser4, etc etc.
>
>
>
>
did you use the badblocks program?

-- 
Hans

Re: Reiser4 problems

[Nick Piggin]

Hans Reiser wrote:

> Nick Piggin wrote:
>
>>
>>
>> Hans Reiser wrote:
>>
>>> Nick Piggin wrote:
>>>
>>>>
>>>>
>>>> Nick Piggin wrote:
>>>>
>>>>>
>>>>> filesystem created with default options, mounted with 
>>>>> noatime,nodiratime.
>>>>> I'll try without the extra mount options now.
>>>>>
>>>>
>>>> still no good
>>>>
>>>>
>>>>
>>>>
>>> It is hardware error....
>>
>>
>>
>>
>> Perhaps. However the same hardware can take heavy stressing with ext2,
>> reports no errors with "badblocks", has never had any data corruption or
>> any SCSI error reported unless using Reiser4, etc etc.
>>
>>
>>
>>
> did you use the badblocks program?


Yep. No bad blocks found. No SCSI error messages.

reiser4 problems

[Sergey Ivanov]

Hi,
I am sorry to report problems I had this night at my e-mail server.
Grepped reiser4 messages from /var/log/messages are at
http://parkheights.dyndns.org/r4log.bz2
I have 2 processor system (athlon) with raid5 software array with 5x62.1
GB, giving me 248.4GB for use. I have created lvm2 volumes for imap
folders there, and also have /usr, /var, /home and other resides on the
same raid5, everything formatted reiser4.
Yesterday the server stops working, but answer pings. I've rebooted it
with magic SysRQ key combinations after forced unmounting and syncing
all partitions. But in the night the problems reappear on some of
virtual volumes. In the morning I did remount -o ro and fsck.reiser4,
all but one volume was O.K, but one required rebuild-fs. Excuse me, I
have not saved the first fsck.reiser4 output. After rebuilding fs and
then rebooting the system, I've got immediately problems, the filesystem
was not accessible, all attempts to get ls of it finished with i/o error
messagees. (I have errors in /etc/fstab, the reiser4 volumes has lines
ending with 1 1, not 1 2 as it should be. I'm not sure it attributed to
the these  problems).
The second fsck.reiser4 once more founded some problems, it's the log:
---
[root@parkheights ~]# fsck.reiser4 -y --build-fs /dev/evms/imap-seriv
*******************************************************************
This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
*******************************************************************

Fscking the /dev/evms/imap-seriv block device.
Will check the consistency of the Reiser4 SuperBlock.
Will build the Reiser4 FileSystem.
***** fsck.reiser4 started at Tue Mar 21 08:34:40 2006
Reiser4 fs was detected on /dev/evms/imap-seriv.
Master super block (16):
magic:          ReIsEr4
blksize:        4096
format:         0x0 (format40)
uuid:           c2bc9aae-fc5c-43b4-b527-9ff6fcde5b55
label:          <none>

Format super block (17):
plugin:         format40
description:    Disk-format for reiser4.
magic:          ReIsEr40FoRmAt
flushes:        0
mkfs id:        0xbd3e802
blocks:         1834992
free blocks:    1059587
root block:     740782
tail policy:    0x2 (smart)
next oid:       0x77c5f
file count:     395956
tree height:    4
key policy:     LARGE

CHECKING STORAGE TREE
FSCK: Node (740803): The left delimiting key [29:1(SD):0:2a:0] in the
parent node (740782), pos (0/4294967295) does not match the first key
[0:0(NAME):0:0:
0] in the node. Fixed.
FSCK: The tree height 4 found in the format is wrong. Fixed to 5.
        Read nodes 440830
        Nodes left in the tree 440830
                Leaves of them 435415, Twigs of them 5323
        Time interval: Tue Mar 21 08:34:41 2006 - Tue Mar 21 08:44:54 2006
CHECKING EXTENT REGIONS.
        Read twigs 5323
        Time interval: Tue Mar 21 08:44:54 2006 - Tue Mar 21 08:46:14 2006
LOOKING FOR UNCONNECTED NODES
        Read nodes 0
        Good nodes 0
                Leaves of them 0, Twigs of them 0
        Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 08:46:14 2006
CHECKING EXTENT REGIONS.
        Read twigs 0
        Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 08:46:14 2006
INSERTING UNCONNECTED NODES
1. Twigs: done
2. Twigs by item: done
3. Leaves: done
4. Leaves by item: done
        Twigs: read 0, inserted 0, by item 0, empty 0
        Leaves: read 0, inserted 0, by item 0
        Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 08:46:14 2006
CHECKING SEMANTIC TREE
FSCK: Node (762207), item (5), [6f6e9:6e657700000000:6f6eb] (stat40):
wrong size (20), Fixed to (21).
FSCK: Node (762207), item (5), [6f6e9:6e657700000000:6f6eb] (stat40):
wrong bytes (2473), Fixed to (2605).
FSCK: Node (773635), item (5), [6f62a:6e657700000000:6f62c] (stat40):
wrong size (6), Fixed to (7).
FSCK: Node (773635), item (5), [6f62a:6e657700000000:6f62c] (stat40):
wrong bytes (628), Fixed to (760).
FSCK: Node (773635), item (6), [6f62a:746d7000000000:6f62b] (stat40):
wrong size (4), Fixed to (3).
FSCK: Node (773635), item (6), [6f62a:746d7000000000:6f62b] (stat40):
wrong bytes (312), Fixed to (206).
        Found 395956 objects.
        Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 09:28:41 2006
CLEANUPING STORAGE TREE
...
--- (once more, excuse me, I have copied it from xterm while it was
'cleanuping storage tree', so it's not the full log).

After second fsck, I have unmounted and mounted it read only to save
data on ext3 partition and to wait answers and suggestions before using
reiser4 once more.
-- 
	With best regards,
		Sergey Ivanov.

Re: reiser4 problems

[Hans Reiser]

Unless Vitaly is still around, you will probably have to wait until
tomorrow for a response.  Thanks for your patience.

Hans

Sergey Ivanov wrote:

>Hi,
>I am sorry to report problems I had this night at my e-mail server.
>Grepped reiser4 messages from /var/log/messages are at
>http://parkheights.dyndns.org/r4log.bz2
>I have 2 processor system (athlon) with raid5 software array with 5x62.1
>GB, giving me 248.4GB for use. I have created lvm2 volumes for imap
>folders there, and also have /usr, /var, /home and other resides on the
>same raid5, everything formatted reiser4.
>Yesterday the server stops working, but answer pings. I've rebooted it
>with magic SysRQ key combinations after forced unmounting and syncing
>all partitions. But in the night the problems reappear on some of
>virtual volumes. In the morning I did remount -o ro and fsck.reiser4,
>all but one volume was O.K, but one required rebuild-fs. Excuse me, I
>have not saved the first fsck.reiser4 output. After rebuilding fs and
>then rebooting the system, I've got immediately problems, the filesystem
>was not accessible, all attempts to get ls of it finished with i/o error
>messagees. (I have errors in /etc/fstab, the reiser4 volumes has lines
>ending with 1 1, not 1 2 as it should be. I'm not sure it attributed to
>the these  problems).
>The second fsck.reiser4 once more founded some problems, it's the log:
>---
>[root@parkheights ~]# fsck.reiser4 -y --build-fs /dev/evms/imap-seriv
>*******************************************************************
>This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
>*******************************************************************
>
>Fscking the /dev/evms/imap-seriv block device.
>Will check the consistency of the Reiser4 SuperBlock.
>Will build the Reiser4 FileSystem.
>***** fsck.reiser4 started at Tue Mar 21 08:34:40 2006
>Reiser4 fs was detected on /dev/evms/imap-seriv.
>Master super block (16):
>magic:          ReIsEr4
>blksize:        4096
>format:         0x0 (format40)
>uuid:           c2bc9aae-fc5c-43b4-b527-9ff6fcde5b55
>label:          <none>
>
>Format super block (17):
>plugin:         format40
>description:    Disk-format for reiser4.
>magic:          ReIsEr40FoRmAt
>flushes:        0
>mkfs id:        0xbd3e802
>blocks:         1834992
>free blocks:    1059587
>root block:     740782
>tail policy:    0x2 (smart)
>next oid:       0x77c5f
>file count:     395956
>tree height:    4
>key policy:     LARGE
>
>CHECKING STORAGE TREE
>FSCK: Node (740803): The left delimiting key [29:1(SD):0:2a:0] in the
>parent node (740782), pos (0/4294967295) does not match the first key
>[0:0(NAME):0:0:
>0] in the node. Fixed.
>FSCK: The tree height 4 found in the format is wrong. Fixed to 5.
>        Read nodes 440830
>        Nodes left in the tree 440830
>                Leaves of them 435415, Twigs of them 5323
>        Time interval: Tue Mar 21 08:34:41 2006 - Tue Mar 21 08:44:54 2006
>CHECKING EXTENT REGIONS.
>        Read twigs 5323
>        Time interval: Tue Mar 21 08:44:54 2006 - Tue Mar 21 08:46:14 2006
>LOOKING FOR UNCONNECTED NODES
>        Read nodes 0
>        Good nodes 0
>                Leaves of them 0, Twigs of them 0
>        Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 08:46:14 2006
>CHECKING EXTENT REGIONS.
>        Read twigs 0
>        Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 08:46:14 2006
>INSERTING UNCONNECTED NODES
>1. Twigs: done
>2. Twigs by item: done
>3. Leaves: done
>4. Leaves by item: done
>        Twigs: read 0, inserted 0, by item 0, empty 0
>        Leaves: read 0, inserted 0, by item 0
>        Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 08:46:14 2006
>CHECKING SEMANTIC TREE
>FSCK: Node (762207), item (5), [6f6e9:6e657700000000:6f6eb] (stat40):
>wrong size (20), Fixed to (21).
>FSCK: Node (762207), item (5), [6f6e9:6e657700000000:6f6eb] (stat40):
>wrong bytes (2473), Fixed to (2605).
>FSCK: Node (773635), item (5), [6f62a:6e657700000000:6f62c] (stat40):
>wrong size (6), Fixed to (7).
>FSCK: Node (773635), item (5), [6f62a:6e657700000000:6f62c] (stat40):
>wrong bytes (628), Fixed to (760).
>FSCK: Node (773635), item (6), [6f62a:746d7000000000:6f62b] (stat40):
>wrong size (4), Fixed to (3).
>FSCK: Node (773635), item (6), [6f62a:746d7000000000:6f62b] (stat40):
>wrong bytes (312), Fixed to (206).
>        Found 395956 objects.
>        Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 09:28:41 2006
>CLEANUPING STORAGE TREE
>...
>--- (once more, excuse me, I have copied it from xterm while it was
>'cleanuping storage tree', so it's not the full log).
>
>After second fsck, I have unmounted and mounted it read only to save
>data on ext3 partition and to wait answers and suggestions before using
>reiser4 once more.
>  
>

Re: reiser4 problems

[Sergey Ivanov]

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

Thank you, Hans.
One additional bit, may be it's about different problem.
While copying from reiser4 volumes to newly created ext3 ones, I decided
to remount read-only the with "mount -o remount,ro" command the source
of copying.
And it results in kernel panics I'm attaching to this mail.
Then the cp process become unkillable, and the system did not reboot
down remotely, I'll see at which point it hanged when I'll be there.
-- 
	Sergey.

Hans Reiser wrote:
> Unless Vitaly is still around, you will probably have to wait until
> tomorrow for a response.  Thanks for your patience.
> 
> Hans
> 
> Sergey Ivanov wrote:
> 
>> Hi,
>> I am sorry to report problems I had this night at my e-mail server.
[skip]
> 





[-- Attachment #2: r4.log --]
[-- Type: text/x-log, Size: 12350 bytes --]

Mar 21 14:01:08 parkheights crond[21683]: (root) CMD (run-parts /etc/cron.hourly)
Mar 21 14:13:12 parkheights kernel: <4>reiser4[ent:dm-6!(1146)]: disable_write_barrier (fs/reiser4/wander.c:233)[zam-1055]:
Mar 21 14:13:13 parkheights kernel: WARNING: disabling write barrier
Mar 21 14:13:13 parkheights kernel: 
Mar 21 14:25:29 parkheights -- MARK --
Mar 21 14:42:26 parkheights kernel: ------------[ cut here ]------------
Mar 21 14:42:27 parkheights kernel: kernel BUG at fs/reiser4/block_alloc.c:149!
Mar 21 14:42:33 parkheights kernel: invalid operand: 0000 [#1]
Mar 21 14:42:42 parkheights kernel: SMP 
Mar 21 14:42:42 parkheights kernel: Modules linked in: dm_mirror vfat fat nls_base lp ac thermal processor button ide_cd cdrom af_packet pdc202xx_new eepro100 mii hw_random amd_k7_agp agpgart analog ns558 gameport psmouse parport_pc parport usbhid floppy pcspkr ohci_hcd usbcore i810_audio ac97_codec soundcore reiser4 raid5 xor dm_mod rtc ext3 jbd mbcache sata_sil libata sd_mod scsi_mod ide_disk ide_generic amd74xx generic ide_core
Mar 21 14:42:42 parkheights kernel: CPU:    1
Mar 21 14:42:42 parkheights kernel: EIP:    0060:[pg0+550729131/1069798400]    Not tainted VLI
Mar 21 14:42:42 parkheights kernel: EIP:    0060:[<e10f85ab>]    Not tainted VLI
Mar 21 14:42:42 parkheights kernel: EFLAGS: 00210297   (2.6.14-vsr4-smp-alt5) 
Mar 21 14:42:42 parkheights kernel: EIP is at sub_from_ctx_grabbed+0x2b/0x40 [reiser4]
Mar 21 14:42:42 parkheights kernel: eax: 00000000   ebx: 00000000   ecx: 00000001   edx: 00000000
Mar 21 14:42:42 parkheights kernel: esi: de4f3ea4   edi: df51f400   ebp: 00000001   esp: de4f3c8c
Mar 21 14:42:42 parkheights kernel: ds: 007b   es: 007b   ss: 0068
Mar 21 14:42:42 parkheights kernel: Process ent:dm-8! (pid: 1128, threadinfo=de4f2000 task=df5aba90)
Mar 21 14:42:42 parkheights kernel: Stack: 00000001 00000000 e10f8dbb de4f3ea4 00000001 00000000 00000000 de4f3ea4 
Mar 21 14:42:42 parkheights kernel:        df51f400 e10f9119 de4f3ea4 df51f400 00000001 00000000 df51f400 de4f3cf8 
Mar 21 14:42:42 parkheights kernel:        00000001 de4f3d2c de4f3d70 e1100e58 de4f3cf8 de4f3d2c de4f3cf0 00000044 
Mar 21 14:42:42 parkheights kernel: Call Trace:
Mar 21 14:42:42 parkheights kernel:  [pg0+550731195/1069798400] grabbed2used+0x1b/0x60 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [<e10f8dbb>] grabbed2used+0x1b/0x60 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [pg0+550732057/1069798400] reiser4_alloc_blocks+0x149/0x1a0 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [<e10f9119>] reiser4_alloc_blocks+0x149/0x1a0 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [pg0+550764120/1069798400] get_more_wandered_blocks+0x38/0x50 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [<e1100e58>] get_more_wandered_blocks+0x38/0x50 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [pg0+550766523/1069798400] alloc_wandered_blocks+0x5b/0x90 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [<e11017bb>] alloc_wandered_blocks+0x5b/0x90 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [pg0+550766476/1069798400] alloc_wandered_blocks+0x2c/0x90 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [<e110178c>] alloc_wandered_blocks+0x2c/0x90 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [pg0+550767226/1069798400] commit_tx+0x4a/0xe0 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [<e1101a7a>] commit_tx+0x4a/0xe0 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [pg0+550767875/1069798400] reiser4_write_logs+0x123/0x1b0 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [<e1101d03>] reiser4_write_logs+0x123/0x1b0 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [pg0+550783854/1069798400] current_atom_finish_all_fq+0x1e/0x70 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [<e1105b6e>] current_atom_finish_all_fq+0x1e/0x70 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [pg0+550737328/1069798400] commit_current_atom+0x150/0x270 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [<e10fa5b0>] commit_current_atom+0x150/0x270 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [pg0+550740451/1069798400] try_commit_txnh+0x133/0x1d0 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [<e10fb1e3>] try_commit_txnh+0x133/0x1d0 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [pg0+550740656/1069798400] commit_txnh+0x30/0xc0 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [<e10fb2b0>] commit_txnh+0x30/0xc0 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [pg0+550734558/1069798400] txn_end+0x3e/0x50 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [<e10f9ade>] txn_end+0x3e/0x50 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [pg0+550734587/1069798400] txn_restart+0xb/0x20 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [<e10f9afb>] txn_restart+0xb/0x20 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [pg0+550739421/1069798400] flush_some_atom+0x25d/0x3c0 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [<e10faddd>] flush_some_atom+0x25d/0x3c0 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [pg0+550804062/1069798400] writeout+0xee/0x1a0 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [<e110aa5e>] writeout+0xee/0x1a0 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [pg0+550810931/1069798400] entd_flush+0xb3/0xe0 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [<e110c533>] entd_flush+0xb3/0xe0 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [pg0+550810167/1069798400] entd+0xb7/0x240 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [<e110c237>] entd+0xb7/0x240 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [autoremove_wake_function+0/64] autoremove_wake_function+0x0/0x40
Mar 21 14:42:42 parkheights kernel:  [<c0131500>] autoremove_wake_function+0x0/0x40
Mar 21 14:42:42 parkheights kernel:  [autoremove_wake_function+0/64] autoremove_wake_function+0x0/0x40
Mar 21 14:42:42 parkheights kernel:  [<c0131500>] autoremove_wake_function+0x0/0x40
Mar 21 14:42:42 parkheights kernel:  [pg0+550809984/1069798400] entd+0x0/0x240 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [<e110c180>] entd+0x0/0x240 [reiser4]
Mar 21 14:42:42 parkheights kernel:  [kthread+147/192] kthread+0x93/0xc0
Mar 21 14:42:42 parkheights kernel:  [<c01310e3>] kthread+0x93/0xc0
Mar 21 14:42:42 parkheights kernel:  [kthread+0/192] kthread+0x0/0xc0
Mar 21 14:42:42 parkheights kernel:  [<c0131050>] kthread+0x0/0xc0
Mar 21 14:42:42 parkheights kernel:  [kernel_thread_helper+5/24] kernel_thread_helper+0x5/0x18
Mar 21 14:42:42 parkheights kernel:  [<c010106d>] kernel_thread_helper+0x5/0x18
Mar 21 14:42:42 parkheights kernel: Code: 56 53 8b 74 24 0c 8b 5c 24 14 8b 4c 24 10 8b 56 70 8b 46 6c 39 da 76 0d 29 c8 19 da 89 46 6c 89 56 70 5b 5e c3 72 04 39 c8 73 ed <0f> 0b 95 00 8a 51 13 e1 eb e3 8d 74 26 00 8d bc 27 00 00 00 00 
Mar 21 14:42:55 parkheights kernel:  ------------[ cut here ]------------
Mar 21 14:42:55 parkheights kernel: kernel BUG at fs/reiser4/block_alloc.c:149!
Mar 21 14:43:05 parkheights kernel: invalid operand: 0000 [#2]
Mar 21 14:43:12 parkheights kernel: SMP 
Mar 21 14:43:12 parkheights kernel: Modules linked in: dm_mirror vfat fat nls_base lp ac thermal processor button ide_cd cdrom af_packet pdc202xx_new eepro100 mii hw_random amd_k7_agp agpgart analog ns558 gameport psmouse parport_pc parport usbhid floppy pcspkr ohci_hcd usbcore i810_audio ac97_codec soundcore reiser4 raid5 xor dm_mod rtc ext3 jbd mbcache sata_sil libata sd_mod scsi_mod ide_disk ide_generic amd74xx generic ide_core
Mar 21 14:43:12 parkheights kernel: CPU:    1
Mar 21 14:43:12 parkheights kernel: EIP:    0060:[pg0+550729131/1069798400]    Not tainted VLI
Mar 21 14:43:12 parkheights kernel: EIP:    0060:[<e10f85ab>]    Not tainted VLI
Mar 21 14:43:12 parkheights kernel: EFLAGS: 00210297   (2.6.14-vsr4-smp-alt5) 
Mar 21 14:43:12 parkheights kernel: EIP is at sub_from_ctx_grabbed+0x2b/0x40 [reiser4]
Mar 21 14:43:12 parkheights kernel: eax: 00000000   ebx: 00000000   ecx: 00000001   edx: 00000000
Mar 21 14:43:12 parkheights kernel: esi: d9b07860   edi: deeb7000   ebp: 00000001   esp: cd3f5ce0
Mar 21 14:43:12 parkheights kernel: ds: 007b   es: 007b   ss: 0068
Mar 21 14:43:12 parkheights kernel: Process pdflush (pid: 20540, threadinfo=cd3f4000 task=dc85e050)
Mar 21 14:43:12 parkheights kernel: Stack: 00000001 00000000 e10f8dbb d9b07860 00000001 00000000 00000000 d9b07860 
Mar 21 14:43:13 parkheights kernel:        deeb7000 e10f9119 d9b07860 deeb7000 00000001 00000000 deeb7000 00000000 
Mar 21 14:43:13 parkheights kernel:        de539ce8 cb073ca0 cd3f5d5c e10ff9df de539d24 cd3f5d5c cd3f5d54 00000014 
Mar 21 14:43:13 parkheights kernel: Call Trace:
Mar 21 14:43:13 parkheights kernel:  [pg0+550731195/1069798400] grabbed2used+0x1b/0x60 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [<e10f8dbb>] grabbed2used+0x1b/0x60 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [pg0+550732057/1069798400] reiser4_alloc_blocks+0x149/0x1a0 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [<e10f9119>] reiser4_alloc_blocks+0x149/0x1a0 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [pg0+550758879/1069798400] allocate_znode_update+0x7f/0x260 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [<e10ff9df>] allocate_znode_update+0x7f/0x260 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [pg0+550689766/1069798400] jload_gfp+0x76/0x1c0 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [<e10eebe6>] jload_gfp+0x76/0x1c0 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [pg0+550758235/1069798400] allocate_znode_loaded+0x5b/0x220 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [<e10ff75b>] allocate_znode_loaded+0x5b/0x220 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [pg0+550758728/1069798400] allocate_znode+0x28/0x40 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [<e10ff948>] allocate_znode+0x28/0x40 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [pg0+550752819/1069798400] alloc_pos_and_ancestors+0xd3/0x120 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [<e10fe233>] alloc_pos_and_ancestors+0xd3/0x120 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [pg0+550750767/1069798400] jnode_flush+0x20f/0x360 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [<e10fda2f>] jnode_flush+0x20f/0x360 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [pg0+550751722/1069798400] flush_current_atom+0x14a/0x290 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [<e10fddea>] flush_current_atom+0x14a/0x290 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [pg0+550739305/1069798400] flush_some_atom+0x1e9/0x3c0 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [<e10fad69>] flush_some_atom+0x1e9/0x3c0 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [pg0+550804062/1069798400] writeout+0xee/0x1a0 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [<e110aa5e>] writeout+0xee/0x1a0 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [pg0+550790268/1069798400] reiser4_sync_inodes+0x3c/0xa0 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [<e110747c>] reiser4_sync_inodes+0x3c/0xa0 [reiser4]
Mar 21 14:43:13 parkheights kernel:  [writeback_inodes+189/208] writeback_inodes+0xbd/0xd0
Mar 21 14:43:13 parkheights kernel:  [<c01881dd>] writeback_inodes+0xbd/0xd0
Mar 21 14:43:13 parkheights kernel:  [background_writeout+132/192] background_writeout+0x84/0xc0
Mar 21 14:43:13 parkheights kernel:  [<c014bc34>] background_writeout+0x84/0xc0
Mar 21 14:43:13 parkheights kernel:  [pdflush+0/48] pdflush+0x0/0x30
Mar 21 14:43:13 parkheights kernel:  [<c014c6b0>] pdflush+0x0/0x30
Mar 21 14:43:13 parkheights kernel:  [__pdflush+192/432] __pdflush+0xc0/0x1b0
Mar 21 14:43:13 parkheights kernel:  [<c014c5c0>] __pdflush+0xc0/0x1b0
Mar 21 14:43:13 parkheights kernel:  [pdflush+30/48] pdflush+0x1e/0x30
Mar 21 14:43:13 parkheights kernel:  [<c014c6ce>] pdflush+0x1e/0x30
Mar 21 14:43:13 parkheights kernel:  [background_writeout+0/192] background_writeout+0x0/0xc0
Mar 21 14:43:13 parkheights kernel:  [<c014bbb0>] background_writeout+0x0/0xc0
Mar 21 14:43:13 parkheights kernel:  [kthread+147/192] kthread+0x93/0xc0
Mar 21 14:43:13 parkheights kernel:  [<c01310e3>] kthread+0x93/0xc0
Mar 21 14:43:13 parkheights kernel:  [kthread+0/192] kthread+0x0/0xc0
Mar 21 14:43:13 parkheights kernel:  [<c0131050>] kthread+0x0/0xc0
Mar 21 14:43:13 parkheights kernel:  [kernel_thread_helper+5/24] kernel_thread_helper+0x5/0x18
Mar 21 14:43:13 parkheights kernel:  [<c010106d>] kernel_thread_helper+0x5/0x18
Mar 21 14:43:13 parkheights kernel: Code: 56 53 8b 74 24 0c 8b 5c 24 14 8b 4c 24 10 8b 56 70 8b 46 6c 39 da 76 0d 29 c8 19 da 89 46 6c 89 56 70 5b 5e c3 72 04 39 c8 73 ed <0f> 0b 95 00 8a 51 13 e1 eb e3 8d 74 26 00 8d bc 27 00 00 00 00 

Re: reiser4 problems

[Vitaly Fertman]

Hello,

On Tuesday 21 March 2006 21:07, Sergey Ivanov wrote:
> Hi,
> I am sorry to report problems I had this night at my e-mail server.
> Grepped reiser4 messages from /var/log/messages are at
> http://parkheights.dyndns.org/r4log.bz2
> I have 2 processor system (athlon) with raid5 software array with 5x62.1
> GB, giving me 248.4GB for use. I have created lvm2 volumes for imap
> folders there, and also have /usr, /var, /home and other resides on the
> same raid5, everything formatted reiser4.
> Yesterday the server stops working, but answer pings. I've rebooted it
> with magic SysRQ key combinations after forced unmounting and syncing
> all partitions. But in the night the problems reappear on some of
> virtual volumes. In the morning I did remount -o ro and fsck.reiser4,
> all but one volume was O.K, but one required rebuild-fs. Excuse me, I
> have not saved the first fsck.reiser4 output. After rebuilding fs and
> then rebooting the system, I've got immediately problems, the filesystem
> was not accessible, all attempts to get ls of it finished with i/o error
> messagees. (I have errors in /etc/fstab, the reiser4 volumes has lines 
> ending with 1 1, not 1 2 as it should be. I'm not sure it attributed to
> the these  problems).
> The second fsck.reiser4 once more founded some problems, it's the log:
> ---
> [root@parkheights ~]# fsck.reiser4 -y --build-fs /dev/evms/imap-seriv
> *******************************************************************
> This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
> *******************************************************************
> 
> Fscking the /dev/evms/imap-seriv block device.
> Will check the consistency of the Reiser4 SuperBlock.
> Will build the Reiser4 FileSystem.
> ***** fsck.reiser4 started at Tue Mar 21 08:34:40 2006
> Reiser4 fs was detected on /dev/evms/imap-seriv.
> 
> CHECKING STORAGE TREE
> FSCK: Node (740803): The left delimiting key [29:1(SD):0:2a:0] in the
> parent node (740782), pos (0/4294967295) does not match the first key
> [0:0(NAME):0:0:
> 0] in the node. Fixed.
> FSCK: The tree height 4 found in the format is wrong. Fixed to 5.
>         Read nodes 440830
>         Nodes left in the tree 440830
>                 Leaves of them 435415, Twigs of them 5323
>         Time interval: Tue Mar 21 08:34:41 2006 - Tue Mar 21 08:44:54 2006
> CHECKING EXTENT REGIONS.
>         Read twigs 5323
>         Time interval: Tue Mar 21 08:44:54 2006 - Tue Mar 21 08:46:14 2006
> LOOKING FOR UNCONNECTED NODES
>         Read nodes 0
>         Good nodes 0
>                 Leaves of them 0, Twigs of them 0
>         Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 08:46:14 2006
> CHECKING EXTENT REGIONS.
>         Read twigs 0
>         Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 08:46:14 2006
> INSERTING UNCONNECTED NODES
> 1. Twigs: done
> 2. Twigs by item: done
> 3. Leaves: done
> 4. Leaves by item: done
>         Twigs: read 0, inserted 0, by item 0, empty 0
>         Leaves: read 0, inserted 0, by item 0
>         Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 08:46:14 2006
> CHECKING SEMANTIC TREE
> FSCK: Node (762207), item (5), [6f6e9:6e657700000000:6f6eb] (stat40):
> wrong size (20), Fixed to (21).
> FSCK: Node (762207), item (5), [6f6e9:6e657700000000:6f6eb] (stat40):
> wrong bytes (2473), Fixed to (2605).
> FSCK: Node (773635), item (5), [6f62a:6e657700000000:6f62c] (stat40):
> wrong size (6), Fixed to (7).
> FSCK: Node (773635), item (5), [6f62a:6e657700000000:6f62c] (stat40):
> wrong bytes (628), Fixed to (760).
> FSCK: Node (773635), item (6), [6f62a:746d7000000000:6f62b] (stat40):
> wrong size (4), Fixed to (3).
> FSCK: Node (773635), item (6), [6f62a:746d7000000000:6f62b] (stat40):
> wrong bytes (312), Fixed to (206).
>         Found 395956 objects.
>         Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 09:28:41 2006
> CLEANUPING STORAGE TREE
> ...
> --- (once more, excuse me, I have copied it from xterm while it was
> 'cleanuping storage tree', so it's not the full log).

wrong bytes is not a big problem, reiser4 indeed counted them wrongly some 
time ago, although it seems to be fixed already. the only serious problem 
here is at the beginning of the 'CHECKING STORAGE TREE' pass -- there must 
not be a key [0:0(NAME):0:0:0].
 
> After second fsck, I have unmounted and mounted it read only to save
> data on ext3 partition and to wait answers and suggestions before using
> reiser4 once more.

which reiser4progs version do you use?

it is already difficult to say why this strange key appeared -- you have
already run several build-fs runs -- although it may be related to remount 
(I remember we used to have some problems before) or to fsck --build-fs.

unmount you fs please and run 'fsck --check' on the unmounted fs -- check 
that all is right there now.

which kernel version do you use?

-- 
Vitaly

Re: reiser4 problems

[sergey ivanov]

Vitaly Fertman wrote:
> Hello,
>
> On Tuesday 21 March 2006 21:07, Sergey Ivanov wrote:
>   
>> Hi,
>>
>>     
> wrong bytes is not a big problem, reiser4 indeed counted them wrongly some 
> time ago, although it seems to be fixed already. the only serious problem 
> here is at the beginning of the 'CHECKING STORAGE TREE' pass -- there must 
> not be a key [0:0(NAME):0:0:0].
>  
>   
>> After second fsck, I have unmounted and mounted it read only to save
>> data on ext3 partition and to wait answers and suggestions before using
>> reiser4 once more.
>>     
>
> which reiser4progs version do you use?
>   
1.0.5
> it is already difficult to say why this strange key appeared -- you have
> already run several build-fs runs -- although it may be related to remount 
> (I remember we used to have some problems before) or to fsck --build-fs.
>   
But I was not able to use filesystem after first fsck --build-fs. Even
ls <mountpoint> was failing with io error message.
> unmount you fs please and run 'fsck --check' on the unmounted fs -- check 
> that all is right there now.
>   
FS is consistent
> which kernel version do you use?
>   
It's 2.4.16, ALTLinux vserver's kernel (see
http://www.sisyphus.ru/srpm/kernel-image-vs26-smp) with applied patch
based on namesys' for 2.6.14, you can see it's spec, changelog and
download it from http://www.sisyphus.ru/srpm/kernel-feat-fs-reiser4.

As I can see now, all data were intact, everything restored O.K after
these 2 fsck --build-fs.
-- 
    With best regards,
       Sergey Ivanov

Re: reiser4 problems

[Jake Maciejewski]

On Wed, 2006-03-22 at 10:33 +0300, Vitaly Fertman wrote:
> Hello,
> 
> On Tuesday 21 March 2006 21:07, Sergey Ivanov wrote:
> > Hi,
> > I am sorry to report problems I had this night at my e-mail server.
> > Grepped reiser4 messages from /var/log/messages are at
> > http://parkheights.dyndns.org/r4log.bz2
> > I have 2 processor system (athlon) with raid5 software array with 5x62.1
> > GB, giving me 248.4GB for use. I have created lvm2 volumes for imap
> > folders there, and also have /usr, /var, /home and other resides on the
> > same raid5, everything formatted reiser4.
> > Yesterday the server stops working, but answer pings. I've rebooted it
> > with magic SysRQ key combinations after forced unmounting and syncing
> > all partitions. But in the night the problems reappear on some of
> > virtual volumes. In the morning I did remount -o ro and fsck.reiser4,
> > all but one volume was O.K, but one required rebuild-fs. Excuse me, I
> > have not saved the first fsck.reiser4 output. After rebuilding fs and
> > then rebooting the system, I've got immediately problems, the filesystem
> > was not accessible, all attempts to get ls of it finished with i/o error
> > messagees. (I have errors in /etc/fstab, the reiser4 volumes has lines 
> > ending with 1 1, not 1 2 as it should be. I'm not sure it attributed to
> > the these  problems).
> > The second fsck.reiser4 once more founded some problems, it's the log:
> > ---
> > [root@parkheights ~]# fsck.reiser4 -y --build-fs /dev/evms/imap-seriv
> > *******************************************************************
> > This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
> > *******************************************************************
> > 
> > Fscking the /dev/evms/imap-seriv block device.
> > Will check the consistency of the Reiser4 SuperBlock.
> > Will build the Reiser4 FileSystem.
> > ***** fsck.reiser4 started at Tue Mar 21 08:34:40 2006
> > Reiser4 fs was detected on /dev/evms/imap-seriv.
> > 
> > CHECKING STORAGE TREE
> > FSCK: Node (740803): The left delimiting key [29:1(SD):0:2a:0] in the
> > parent node (740782), pos (0/4294967295) does not match the first key
> > [0:0(NAME):0:0:
> > 0] in the node. Fixed.
> > FSCK: The tree height 4 found in the format is wrong. Fixed to 5.
> >         Read nodes 440830
> >         Nodes left in the tree 440830
> >                 Leaves of them 435415, Twigs of them 5323
> >         Time interval: Tue Mar 21 08:34:41 2006 - Tue Mar 21 08:44:54 2006
> > CHECKING EXTENT REGIONS.
> >         Read twigs 5323
> >         Time interval: Tue Mar 21 08:44:54 2006 - Tue Mar 21 08:46:14 2006
> > LOOKING FOR UNCONNECTED NODES
> >         Read nodes 0
> >         Good nodes 0
> >                 Leaves of them 0, Twigs of them 0
> >         Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 08:46:14 2006
> > CHECKING EXTENT REGIONS.
> >         Read twigs 0
> >         Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 08:46:14 2006
> > INSERTING UNCONNECTED NODES
> > 1. Twigs: done
> > 2. Twigs by item: done
> > 3. Leaves: done
> > 4. Leaves by item: done
> >         Twigs: read 0, inserted 0, by item 0, empty 0
> >         Leaves: read 0, inserted 0, by item 0
> >         Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 08:46:14 2006
> > CHECKING SEMANTIC TREE
> > FSCK: Node (762207), item (5), [6f6e9:6e657700000000:6f6eb] (stat40):
> > wrong size (20), Fixed to (21).
> > FSCK: Node (762207), item (5), [6f6e9:6e657700000000:6f6eb] (stat40):
> > wrong bytes (2473), Fixed to (2605).
> > FSCK: Node (773635), item (5), [6f62a:6e657700000000:6f62c] (stat40):
> > wrong size (6), Fixed to (7).
> > FSCK: Node (773635), item (5), [6f62a:6e657700000000:6f62c] (stat40):
> > wrong bytes (628), Fixed to (760).
> > FSCK: Node (773635), item (6), [6f62a:746d7000000000:6f62b] (stat40):
> > wrong size (4), Fixed to (3).
> > FSCK: Node (773635), item (6), [6f62a:746d7000000000:6f62b] (stat40):
> > wrong bytes (312), Fixed to (206).
> >         Found 395956 objects.
> >         Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 09:28:41 2006
> > CLEANUPING STORAGE TREE
> > ...
> > --- (once more, excuse me, I have copied it from xterm while it was
> > 'cleanuping storage tree', so it's not the full log).
> 
> wrong bytes is not a big problem, reiser4 indeed counted them wrongly some 
> time ago, although it seems to be fixed already. 

I recently encountered a wrong bytes issue on 2.6.15.1 with the 2.6.15-1
patch. After a lot of compiling (emerge -eD world in Gentoo), I ended up
with a directory that I couldn't delete.

fsck.reiser4 --check log:

FSCK: Node (21121314), item (10), [10467f6:6c6f63616c6500:10467f7] (stat40):
wrong size (3), Should be (2).
FSCK: Node (21121314), item (10), [10467f6:6c6f63616c6500:10467f7] (stat40):
wrong bytes (182), Should be (100).

fsck.reiser4 --fix log:

FSCK: Node (19374202), item (0): 1 mergable units were found in the extent40
unit. Merged.
FSCK: Node (21121314), item (10), [10467f6:6c6f63616c6500:10467f7] (stat40):
wrong size (3), Fixed to (2).
FSCK: Node (21121314), item (10), [10467f6:6c6f63616c6500:10467f7] (stat40):
wrong bytes (182), Fixed to (100).

After fixing, --check came up clean. It's good to know the bug is
relatively harmless and has been fixed, but is there any way to take
advantage of improvements and bugfixes made in the last two months
without running 2.6.14 or the -mm patchset?

> the only serious problem 
> here is at the beginning of the 'CHECKING STORAGE TREE' pass -- there must 
> not be a key [0:0(NAME):0:0:0].
>  
> > After second fsck, I have unmounted and mounted it read only to save
> > data on ext3 partition and to wait answers and suggestions before using
> > reiser4 once more.
> 
> which reiser4progs version do you use?
> 
> it is already difficult to say why this strange key appeared -- you have
> already run several build-fs runs -- although it may be related to remount 
> (I remember we used to have some problems before) or to fsck --build-fs.
> 
> unmount you fs please and run 'fsck --check' on the unmounted fs -- check 
> that all is right there now.
> 
> which kernel version do you use?
> 
-- 
Jake Maciejewski <maciejej@msoe.edu>

Re: reiser4 problems

[Vladimir V. Saveliev]

Hello

On Wed, 2006-03-22 at 16:36 -0600, Jake Maciejewski wrote:
> On Wed, 2006-03-22 at 10:33 +0300, Vitaly Fertman wrote:
> > Hello,
> > 
> > On Tuesday 21 March 2006 21:07, Sergey Ivanov wrote:
> > > Hi,
> > > I am sorry to report problems I had this night at my e-mail server.
> > > Grepped reiser4 messages from /var/log/messages are at
> > > http://parkheights.dyndns.org/r4log.bz2
> > > I have 2 processor system (athlon) with raid5 software array with 5x62.1
> > > GB, giving me 248.4GB for use. I have created lvm2 volumes for imap
> > > folders there, and also have /usr, /var, /home and other resides on the
> > > same raid5, everything formatted reiser4.
> > > Yesterday the server stops working, but answer pings. I've rebooted it
> > > with magic SysRQ key combinations after forced unmounting and syncing
> > > all partitions. But in the night the problems reappear on some of
> > > virtual volumes. In the morning I did remount -o ro and fsck.reiser4,
> > > all but one volume was O.K, but one required rebuild-fs. Excuse me, I
> > > have not saved the first fsck.reiser4 output. After rebuilding fs and
> > > then rebooting the system, I've got immediately problems, the filesystem
> > > was not accessible, all attempts to get ls of it finished with i/o error
> > > messagees. (I have errors in /etc/fstab, the reiser4 volumes has lines 
> > > ending with 1 1, not 1 2 as it should be. I'm not sure it attributed to
> > > the these  problems).
> > > The second fsck.reiser4 once more founded some problems, it's the log:
> > > ---
> > > [root@parkheights ~]# fsck.reiser4 -y --build-fs /dev/evms/imap-seriv
> > > *******************************************************************
> > > This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
> > > *******************************************************************
> > > 
> > > Fscking the /dev/evms/imap-seriv block device.
> > > Will check the consistency of the Reiser4 SuperBlock.
> > > Will build the Reiser4 FileSystem.
> > > ***** fsck.reiser4 started at Tue Mar 21 08:34:40 2006
> > > Reiser4 fs was detected on /dev/evms/imap-seriv.
> > > 
> > > CHECKING STORAGE TREE
> > > FSCK: Node (740803): The left delimiting key [29:1(SD):0:2a:0] in the
> > > parent node (740782), pos (0/4294967295) does not match the first key
> > > [0:0(NAME):0:0:
> > > 0] in the node. Fixed.
> > > FSCK: The tree height 4 found in the format is wrong. Fixed to 5.
> > >         Read nodes 440830
> > >         Nodes left in the tree 440830
> > >                 Leaves of them 435415, Twigs of them 5323
> > >         Time interval: Tue Mar 21 08:34:41 2006 - Tue Mar 21 08:44:54 2006
> > > CHECKING EXTENT REGIONS.
> > >         Read twigs 5323
> > >         Time interval: Tue Mar 21 08:44:54 2006 - Tue Mar 21 08:46:14 2006
> > > LOOKING FOR UNCONNECTED NODES
> > >         Read nodes 0
> > >         Good nodes 0
> > >                 Leaves of them 0, Twigs of them 0
> > >         Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 08:46:14 2006
> > > CHECKING EXTENT REGIONS.
> > >         Read twigs 0
> > >         Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 08:46:14 2006
> > > INSERTING UNCONNECTED NODES
> > > 1. Twigs: done
> > > 2. Twigs by item: done
> > > 3. Leaves: done
> > > 4. Leaves by item: done
> > >         Twigs: read 0, inserted 0, by item 0, empty 0
> > >         Leaves: read 0, inserted 0, by item 0
> > >         Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 08:46:14 2006
> > > CHECKING SEMANTIC TREE
> > > FSCK: Node (762207), item (5), [6f6e9:6e657700000000:6f6eb] (stat40):
> > > wrong size (20), Fixed to (21).
> > > FSCK: Node (762207), item (5), [6f6e9:6e657700000000:6f6eb] (stat40):
> > > wrong bytes (2473), Fixed to (2605).
> > > FSCK: Node (773635), item (5), [6f62a:6e657700000000:6f62c] (stat40):
> > > wrong size (6), Fixed to (7).
> > > FSCK: Node (773635), item (5), [6f62a:6e657700000000:6f62c] (stat40):
> > > wrong bytes (628), Fixed to (760).
> > > FSCK: Node (773635), item (6), [6f62a:746d7000000000:6f62b] (stat40):
> > > wrong size (4), Fixed to (3).
> > > FSCK: Node (773635), item (6), [6f62a:746d7000000000:6f62b] (stat40):
> > > wrong bytes (312), Fixed to (206).
> > >         Found 395956 objects.
> > >         Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 09:28:41 2006
> > > CLEANUPING STORAGE TREE
> > > ...
> > > --- (once more, excuse me, I have copied it from xterm while it was
> > > 'cleanuping storage tree', so it's not the full log).
> > 
> > wrong bytes is not a big problem, reiser4 indeed counted them wrongly some 
> > time ago, although it seems to be fixed already. 
> 
> I recently encountered a wrong bytes issue on 2.6.15.1 with the 2.6.15-1
> patch. After a lot of compiling (emerge -eD world in Gentoo), I ended up
> with a directory that I couldn't delete.
> 
> fsck.reiser4 --check log:
> 
> FSCK: Node (21121314), item (10), [10467f6:6c6f63616c6500:10467f7] (stat40):
> wrong size (3), Should be (2).
> FSCK: Node (21121314), item (10), [10467f6:6c6f63616c6500:10467f7] (stat40):
> wrong bytes (182), Should be (100).
> 
> fsck.reiser4 --fix log:
> 
> FSCK: Node (19374202), item (0): 1 mergable units were found in the extent40
> unit. Merged.
> FSCK: Node (21121314), item (10), [10467f6:6c6f63616c6500:10467f7] (stat40):
> wrong size (3), Fixed to (2).
> FSCK: Node (21121314), item (10), [10467f6:6c6f63616c6500:10467f7] (stat40):
> wrong bytes (182), Fixed to (100).
> 
> After fixing, --check came up clean. It's good to know the bug is
> relatively harmless and has been fixed, but is there any way to take
> advantage of improvements and bugfixes made in the last two months
> without running 2.6.14 or the -mm patchset?
> 

yes, I will try to make a patch for 2.6.16 today