Re: Re: reiserfsck --rebuild-tree all-in-one problem.
Hello, Fantastic, after one day of scan, reiserfsck-3.6.20 did it ! My lvm array is now back online. Many thanks for your help Vitold - Message d'origine - De: Vladimir V. Saveliev [EMAIL PROTECTED] Date: Tue, 28 Mar 2006 16:19:57 +0400 Sujet: Re: reiserfsck --rebuild-tree all-in-one problem. À: Vitold Kapshitzer [EMAIL PROTECTED] Cc: reiserfs-list@namesys.com Hello On Tue, 2006-03-28 at 13:48 +0200, Vitold Kapshitzer wrote: Hello, I'm trying to do a rebuild-tree for days now, it seams that I've got the same probleme above. The server didn't hang when the error accured. I've turned on the monitor on the morning and have seen that the disk got full (was about 120Go free, 650Go total), the root disk is also reiserfs but is ok, reiserfsck(3.6.19) told me that I need to run reiserfsck with the rebuild-tree option but it never ended. Only my LVM logical disk is now unmountable. I am using gentoo, and I've already tried to recompile reiserfsprogs, but unfortunatly, same result. I am told that this problem might be fixed already. Would you try ftp://ftp.namesys.com/pub/tmp/reiserfsprogs-3.6.20.tar.gz, please? Thanks Vitold on Sunday 02 February 2003 21:33, Brian Chu wrote: Hello. Last friday when I went to upgrade my server, I noticed that there had been a lot of kernel messages on my server that were saying that one partition was spewing this: Jan 5 13:48:14 simmy kernel: hde: dma_intr: status=0x51 { DriveReady SeekComplete Error } Jan 5 13:48:14 simmy kernel: hde: dma_intr: error=0x40 { UncorrectableError }, LBAsect=91887, high=0, low=91887, sector=91824 Jan 5 13:48:14 simmy kernel: end_request: I/O error, dev 21:01 (hde), sector 91824 Jan 5 13:48:14 simmy kernel: vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [7495 7710 0x0 SD] I gave up that night, because running dd once took 7 hours and reiserfsck twice took 2 hours each, so the whole day was wasted. I had read on the first time I ran --rebuild-tree that a dd_rescue was suggested, so I downloaded it, installed it, and ran it again (since I had used just plain dd the first time). I'm not sure if that made a difference or not. Right, dd seems to produce an output with just skipped bad blocks not writing anything into the output. Today I started again, assuming that with dd_rescue, I would have a greater chance of getting the filesystem recovered, but --check told me I had to run --rebuild-tree, and this time I just did --logfile /dev/null, because screen dumps during the run would make it impossible to see what's going on. But again, it stopped again at the same place- Pass 2. Since the logfiles spit so much STUFF out, I have none at the moment (I can remake them if needed). Screen dump: Pass 2: 0%20%40%.. left 36, 0 /sec And it stops there. top indicates reiserfsck is using all of the cpu cycles, even after it seemingly freezes. Looks like you built the reiserfsck on another mashine. Could you rebuild it on the same mashine you run it. It is possible to suppress the logfile with -n option, but I think the logfile was so big due to this endless loop.
Re: reiserfsck --rebuild-tree all-in-one problem.
Hello, I'm trying to do a rebuild-tree for days now, it seams that I've got the same probleme above. The server didn't hang when the error accured. I've turned on the monitor on the morning and have seen that the disk got full (was about 120Go free, 650Go total), the root disk is also reiserfs but is ok, reiserfsck(3.6.19) told me that I need to run reiserfsck with the rebuild-tree option but it never ended. Only my LVM logical disk is now unmountable. I am using gentoo, and I've already tried to recompile reiserfsprogs, but unfortunatly, same result. Thanks Vitold on Sunday 02 February 2003 21:33, Brian Chu wrote: Hello. Last friday when I went to upgrade my server, I noticed that there had been a lot of kernel messages on my server that were saying that one partition was spewing this: Jan 5 13:48:14 simmy kernel: hde: dma_intr: status=0x51 { DriveReady SeekComplete Error } Jan 5 13:48:14 simmy kernel: hde: dma_intr: error=0x40 { UncorrectableError }, LBAsect=91887, high=0, low=91887, sector=91824 Jan 5 13:48:14 simmy kernel: end_request: I/O error, dev 21:01 (hde), sector 91824 Jan 5 13:48:14 simmy kernel: vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [7495 7710 0x0 SD] I gave up that night, because running dd once took 7 hours and reiserfsck twice took 2 hours each, so the whole day was wasted. I had read on the first time I ran --rebuild-tree that a dd_rescue was suggested, so I downloaded it, installed it, and ran it again (since I had used just plain dd the first time). I'm not sure if that made a difference or not. Right, dd seems to produce an output with just skipped bad blocks not writing anything into the output. Today I started again, assuming that with dd_rescue, I would have a greater chance of getting the filesystem recovered, but --check told me I had to run --rebuild-tree, and this time I just did --logfile /dev/null, because screen dumps during the run would make it impossible to see what's going on. But again, it stopped again at the same place- Pass 2. Since the logfiles spit so much STUFF out, I have none at the moment (I can remake them if needed). Screen dump: Pass 2: 0%20%40%.. left 36, 0 /sec And it stops there. top indicates reiserfsck is using all of the cpu cycles, even after it seemingly freezes. Looks like you built the reiserfsck on another mashine. Could you rebuild it on the same mashine you run it. It is possible to suppress the logfile with -n option, but I think the logfile was so big due to this endless loop. -- Thanks, Vitaly Fertman
Re: reiserfsck --rebuild-tree all-in-one problem.
Hello On Tue, 2006-03-28 at 13:48 +0200, Vitold Kapshitzer wrote: Hello, I'm trying to do a rebuild-tree for days now, it seams that I've got the same probleme above. The server didn't hang when the error accured. I've turned on the monitor on the morning and have seen that the disk got full (was about 120Go free, 650Go total), the root disk is also reiserfs but is ok, reiserfsck(3.6.19) told me that I need to run reiserfsck with the rebuild-tree option but it never ended. Only my LVM logical disk is now unmountable. I am using gentoo, and I've already tried to recompile reiserfsprogs, but unfortunatly, same result. I am told that this problem might be fixed already. Would you try ftp://ftp.namesys.com/pub/tmp/reiserfsprogs-3.6.20.tar.gz, please? Thanks Vitold on Sunday 02 February 2003 21:33, Brian Chu wrote: Hello. Last friday when I went to upgrade my server, I noticed that there had been a lot of kernel messages on my server that were saying that one partition was spewing this: Jan 5 13:48:14 simmy kernel: hde: dma_intr: status=0x51 { DriveReady SeekComplete Error } Jan 5 13:48:14 simmy kernel: hde: dma_intr: error=0x40 { UncorrectableError }, LBAsect=91887, high=0, low=91887, sector=91824 Jan 5 13:48:14 simmy kernel: end_request: I/O error, dev 21:01 (hde), sector 91824 Jan 5 13:48:14 simmy kernel: vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [7495 7710 0x0 SD] I gave up that night, because running dd once took 7 hours and reiserfsck twice took 2 hours each, so the whole day was wasted. I had read on the first time I ran --rebuild-tree that a dd_rescue was suggested, so I downloaded it, installed it, and ran it again (since I had used just plain dd the first time). I'm not sure if that made a difference or not. Right, dd seems to produce an output with just skipped bad blocks not writing anything into the output. Today I started again, assuming that with dd_rescue, I would have a greater chance of getting the filesystem recovered, but --check told me I had to run --rebuild-tree, and this time I just did --logfile /dev/null, because screen dumps during the run would make it impossible to see what's going on. But again, it stopped again at the same place- Pass 2. Since the logfiles spit so much STUFF out, I have none at the moment (I can remake them if needed). Screen dump: Pass 2: 0%20%40%.. left 36, 0 /sec And it stops there. top indicates reiserfsck is using all of the cpu cycles, even after it seemingly freezes. Looks like you built the reiserfsck on another mashine. Could you rebuild it on the same mashine you run it. It is possible to suppress the logfile with -n option, but I think the logfile was so big due to this endless loop.
Re: reiserfsck --rebuild-tree all-in-one problem.
On Sunday 02 February 2003 21:33, Brian Chu wrote: Hello. Last friday when I went to upgrade my server, I noticed that there had been a lot of kernel messages on my server that were saying that one partition was spewing this: Jan 5 13:48:14 simmy kernel: hde: dma_intr: status=0x51 { DriveReady SeekComplete Error } Jan 5 13:48:14 simmy kernel: hde: dma_intr: error=0x40 { UncorrectableError }, LBAsect=91887, high=0, low=91887, sector=91824 Jan 5 13:48:14 simmy kernel: end_request: I/O error, dev 21:01 (hde), sector 91824 Jan 5 13:48:14 simmy kernel: vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [7495 7710 0x0 SD] I gave up that night, because running dd once took 7 hours and reiserfsck twice took 2 hours each, so the whole day was wasted. I had read on the first time I ran --rebuild-tree that a dd_rescue was suggested, so I downloaded it, installed it, and ran it again (since I had used just plain dd the first time). I'm not sure if that made a difference or not. Right, dd seems to produce an output with just skipped bad blocks not writing anything into the output. Today I started again, assuming that with dd_rescue, I would have a greater chance of getting the filesystem recovered, but --check told me I had to run --rebuild-tree, and this time I just did --logfile /dev/null, because screen dumps during the run would make it impossible to see what's going on. But again, it stopped again at the same place- Pass 2. Since the logfiles spit so much STUFF out, I have none at the moment (I can remake them if needed). Screen dump: Pass 2: 0%20%40%.. left 36, 0 /sec And it stops there. top indicates reiserfsck is using all of the cpu cycles, even after it seemingly freezes. Looks like you built the reiserfsck on another mashine. Could you rebuild it on the same mashine you run it. It is possible to suppress the logfile with -n option, but I think the logfile was so big due to this endless loop. -- Thanks, Vitaly Fertman
Re: reiserfsck --rebuild-tree all-in-one problem.
Brian Chu wrote (ao): Last friday when I went to upgrade my server, I noticed that there had been a lot of kernel messages on my server that were saying that one partition was spewing this: Jan 5 13:48:14 simmy kernel: hde: dma_intr: status=0x51 { DriveReady SeekComplete Error } Jan 5 13:48:14 simmy kernel: hde: dma_intr: error=0x40 { UncorrectableError }, LBAsect=91887, high=0, low=91887, sector=91824 Jan 5 13:48:14 simmy kernel: end_request: I/O error, dev 21:01 (hde), sector 91824 Jan 5 13:48:14 simmy kernel: vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [7495 7710 0x0 SD] I checked it for this email just now and discovered that this problem has been persisting for at least one month (logrotate deleted the rest), which is surprising because I never had any problems with the hard drive for all this time. But, it is a hardware problem. Either way, after I was done upgrading my server, I figured I could run reiserfsck since it was a new reboot with 'reiserfsck --check /dev/hde1' (version 3.6.3) which proved to be fatal. It is better if you (always) try the latest reiserfsck version, which is in 3.6.5-pre1 atm. ftp://ftp.namesys.com/pub/reiserfsprogs/pre/reiserfsprogs-3.6.5-pre1.tar.gz [cut] mount ... weird. mount gives a different message now. mount was giving the same mount: Not a directory that the first computer had given before this last run of reiserfsck. Can you do an ls -ld on /mnt ? simmy:~# mount -t reiserfs /dev/hdd1 /mnt Feb 2 13:41:00 simmy kernel: dev 16:41: Unfinished reiserfsck --rebuild-tree run detected. Please run Feb 2 13:41:00 simmy kernel: reiserfsck --rebuild-tree and wait for a completion. If that fails Feb 2 13:41:00 simmy kernel: get newer reiserfsprogs package Feb 2 13:41:00 simmy kernel: read_super_block: can't find a reiserfs filesystem on (dev 16:41, block 2, size 4096) mount: wrong fs type, bad option, bad superblock on /dev/hdd1, or too many mounted file systems Any (quick) help will be appreciated. If any information is missing, please ask. After you dd'ed the disk, you should see a lot of error messages in dmesg. dd can't make a good copy of the fs due to that, so that's why you need to use dd_rescue. dd_rescue will most likely not be able to retreive all your data, but most likely most of it. Of course you should not use the old disk anymore if you got your data back. In summary: try dd_rescue again, and fsck the target disk with the newest reiserfsprogs. I hope that works for you.