Bug#562090: fsck.reiser4 dies with segfault on buggy fs
Package: reiser4progs Version: 1.0.7-5 I have my /home on reiser4 with compression. I use zen project kernels, which have reiser4 support. The current is 2.6.32-zen2 I have problems with this partition, so I've run fsck.reiser4. Here is the output: valentine-pc:/home/valentine# fsck.reiser4 /dev/mapper/isw_jfcfihbei_RAID08 *** This is an EXPERIMENTAL version of fsck.reiser4. Read README first. *** Fscking the /dev/mapper/isw_jfcfihbei_RAID08 block device. Will check the consistency of the Reiser4 SuperBlock. Will check the consistency of the Reiser4 FileSystem. Continue? (Yes/No): Yes * fsck.reiser4 started at Tue Dec 22 16:58:57 2009 Reiser4 fs was detected on /dev/mapper/isw_jfcfihbei_RAID08. Master super block (16): magic: ReIsEr4 blksize:4096 format: 0x0 (format40) uuid: none label: none Format super block (17): plugin: format40 description:Disk-format plugin. version:0 magic: ReIsEr40FoRmAt mkfs id:0x5ef41903 flushes:0 blocks: 7323616 free blocks:4932387 root block: 7235172 tail policy:0x2 (smart) next oid: 0x6564fc file count: 294497 tree height:5 key policy: LARGE CHECKING THE STORAGE TREE Read nodes 918358 Nodes left in the tree 918358 Leaves of them 906695, Twigs of them 11479 Time interval: Tue Dec 22 16:59:00 2009 - Tue Dec 22 17:00:48 2009 CHECKING EXTENT REGIONS. Read twigs 11479 Time interval: Tue Dec 22 17:00:48 2009 - Tue Dec 22 17:01:16 2009 CHECKING THE SEMANTIC TREE FSCK: /tmp/buildd/reiser4progs-1.0.7/plugin/object/ccreg40/ccreg40_repair.c: 77: ccreg40_check_item: The file [52cf8a:62756874753465:5ce9cc] (ccreg40), node [7252143], item [1]: item of the wrong cluster size (-2147483648) found, Should be (65536). Segmentation fault The visible problem in fs is that there are files that cause processes reading them to hang (they can be killed only by magic SysRqs). I had similar problems before, and the segfaults stopped when I removed failing files. But now I don't know where the buggy files are. -- Best regards, Valentin Pavlyuchenko -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562090: fsck.reiser4 dies with segfault on buggy fs
Am Dienstag, den 22.12.2009, 17:13 +0200 schrieb Valentin Pavlyuchenko: Package: reiser4progs Version: 1.0.7-5 I have my /home on reiser4 with compression. I use zen project kernels, which have reiser4 support. The current is 2.6.32-zen2 I have problems with this partition, so I've run fsck.reiser4. Here is the output: valentine-pc:/home/valentine# fsck.reiser4 /tmp/buildd/reiser4progs-1.0.7/plugin/object/ccreg40/ccreg40_repair.c: 77: ccreg40_check_item: The file [52cf8a:62756874753465:5ce9cc] (ccreg40), node [7252143], item [1]: item of the wrong cluster size (-2147483648) found, Should be (65536). Segmentation fault The visible problem in fs is that there are files that cause processes reading them to hang (they can be killed only by magic SysRqs). I had similar problems before, and the segfaults stopped when I removed failing files. But now I don't know where the buggy files are. It would be nice if you could compile reiser4progs with debugging symbols and then run it in gdb to get a backtrace: $ apt-get source reiser4progs $ sudo apt-get build-dep reiser4progs $ cd reiser4progs-1.0.7 $ DEB_BUILD_OPTIONS=nostrip noopt debug dpkg-buildpackage -b $ sudo dpkg -i ../reiser4progs*.deb $ sudo gdb fsck.reiser4 (gdb) r /dev/mapper/isw_jfcfihbei_RAID08 (gdb) bt (gdb) quit Even nicer would be if you would directly send it (and your other comments above) to upstream at reiserfs-de...@vger.kernel.org, else I do it for you. List isn't subscriber only but you should state that you want to be CCed if that's true. This month there was a small thread that cryptocompress seems to be stable but someone noted that it would be better to use tea hashing instead of r5: http://marc.info/?l=reiserfs-develm=125982022705316w=2 -- Best regards, Valentin Pavlyuchenko -- Felix Zielcke Proud Debian Maintainer and GNU GRUB developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562090: fsck.reiser4 dies with segfault on buggy fs
At some moment everything started working again (I don't know why - I was just copying files from that partition). So its not reproducible now. A great sorry. Lets close the bug. If I have it again I'll inform you. I'll do what you've said and will try to debug it. -- Best regards, Valentin Pavlyuchenko 2009/12/22 Felix Zielcke fziel...@z-51.de: Am Dienstag, den 22.12.2009, 17:13 +0200 schrieb Valentin Pavlyuchenko: Package: reiser4progs Version: 1.0.7-5 I have my /home on reiser4 with compression. I use zen project kernels, which have reiser4 support. The current is 2.6.32-zen2 I have problems with this partition, so I've run fsck.reiser4. Here is the output: valentine-pc:/home/valentine# fsck.reiser4 /tmp/buildd/reiser4progs-1.0.7/plugin/object/ccreg40/ccreg40_repair.c: 77: ccreg40_check_item: The file [52cf8a:62756874753465:5ce9cc] (ccreg40), node [7252143], item [1]: item of the wrong cluster size (-2147483648) found, Should be (65536). Segmentation fault The visible problem in fs is that there are files that cause processes reading them to hang (they can be killed only by magic SysRqs). I had similar problems before, and the segfaults stopped when I removed failing files. But now I don't know where the buggy files are. It would be nice if you could compile reiser4progs with debugging symbols and then run it in gdb to get a backtrace: $ apt-get source reiser4progs $ sudo apt-get build-dep reiser4progs $ cd reiser4progs-1.0.7 $ DEB_BUILD_OPTIONS=nostrip noopt debug dpkg-buildpackage -b $ sudo dpkg -i ../reiser4progs*.deb $ sudo gdb fsck.reiser4 (gdb) r /dev/mapper/isw_jfcfihbei_RAID08 (gdb) bt (gdb) quit Even nicer would be if you would directly send it (and your other comments above) to upstream at reiserfs-de...@vger.kernel.org, else I do it for you. List isn't subscriber only but you should state that you want to be CCed if that's true. This month there was a small thread that cryptocompress seems to be stable but someone noted that it would be better to use tea hashing instead of r5: http://marc.info/?l=reiserfs-develm=125982022705316w=2 -- Best regards, Valentin Pavlyuchenko -- Felix Zielcke Proud Debian Maintainer and GNU GRUB developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
