May 30, 201115 yr Hey guys, I'm running beta6a and replaced a 400gb drive (which contained no data) with a 2TB drive. Everything seemed to be going fine, but one drive (1.5TB) cropped up with tons or errors during the rebuild. It still showed green, but was taking FOREVER. I figured there must have been some bad sectors on the drive so I tried spinrite (which crashed horribly at the same spot every time). I then ran hdd regenerator which found a bunch of bad sectors, and successfully recovered them. (This took almost 24 hours to complete). I now started the array back up, and the drive with the problems is showing up as unformatted. I ran a reiserfsck and it reported that the superblock was corrupt. Any ideas what I should do next? Thanks! Syslog is attached. syslog.txt
May 30, 201115 yr Author Also, when I start the array it starts doing a data rebuild. Why is it doing this when there are two reportedly unformatted drives present? Is it able to rebuild the data because the drive I replaced never actually had any data on it? (The one with bad sectors does, however)
May 30, 201115 yr Author 19, which is the new 2b replacing the old, empty 400gb. I stopped the rebuild, by the way. I figure I don't want to do that until the drive with bad sectors is brought back online (then replaced once the new drive is in place).
May 31, 201115 yr Author I decided to just let it rebuild and we'll see what happens. The array is online, but missing the files on the unformatted disk 9.
June 1, 201115 yr Author The WEB UI is now unresponsive, but the activity lights on the hard drives are still going. Interesting that it seems to still be accessing the problem drive that it reported as unformatted on initial boot. Very strange... I guess I'll just leave it alone.
June 1, 201115 yr Post some screen shots of the server. What your describing should not be possible. I think thats why you not getting more help because people have no idea what to advise.
June 1, 201115 yr Author I would but the web UI keeps timing out. The HDD activity light on the bad drive is solid. I assume it's still trying to rebuild the data on the new drive. No idea why it's accessing the bad drive, though. I could force reboot the server just the get the web UI up?
June 1, 201115 yr Author So I left the server alone overnight, and came back to no HDD activity lights. The web UI was still unresponsive, so I rebooted. Now it is it doing a parity check ( ) and still showing 2 unformatted disks. No idea what is going on here... Screenshot: Disk 9 is the problem drive. Disk 19 is the new drive.
June 2, 201115 yr Author There was no original one for disk 9. Just disk 19. The errors cropped up while rebuilding the data on the new disk 19.
June 2, 201115 yr Author I can. But when I do that it complains that the replacement disk is too small (of course). Should I run the new config script and re-assign the disks?
June 2, 201115 yr First you need to run reiserfsck --rebuild-sb on disk 9 if you want to try to recover its contents.
June 2, 201115 yr Author Okay, I did that. But I totally blew it and accidentally closed the putty window before grabbing the error it spat out. Now when I do a reiserfsck --check on the drive, I get this: ########### reiserfsck --check started at Thu Jun 2 04:44:34 2011 ########### Replaying journal: No transactions found Zero bit found in on-disk bitmap after the last valid bit. Checking internal tree.. Bad root block 0. (--rebuild-tree did not complete) Aborted Interestingly it is showing up as 4k aligned now when the array is stopped (it used to be unaligned). It still reports as unformatted however. Thank you again for the help.
June 2, 201115 yr Author I'm to the point now where I don't even need or care if the drive works in the array. If I can just get the data off I'd be happy.
June 2, 201115 yr I'm to the point now where I don't even need or care if the drive works in the array. If I can just get the data off I'd be happy. did you do the reiserfsck --check on /dev/md9 or did you do it on /dev/sda1 or, did you do it on /dev/sda ?? Joe L.
June 2, 201115 yr I did reiserfsck --check /dev/md9 To repair any damage, and recover whatever is recoverable you'll need to do the following on /dev/md9 reiserfsck --fix-fixable /dev/md9 If it complains about a missing superblock, then reiserfsck --rebuild-sb /dev/md9 Then, you can try the --fix-fixable once more. Apparently you had one occasion where a --rebuild-tree did not complete. The --fix-fixable may just suggest you run --rebuild-tree as the next step, assuming it can find a valid superblock. reiserfsck will probably not let you run if is the disk is currently mounted, so before you do anything you'll probably need to do umount /mnt/disk9 All this needs to be done with the array "started" so do not stop it before the reiserfsck commands are run. After they are run, and after reiserfsck repairs any damage, then you can stop the array and re-start it and the disk should then mount. When you run the reiserfsck --rebuild-sb /dev/md9 command there will be a series of prompts. Answer as follows: Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes reiserfs_open: the reiserfs superblock cannot be found on /dev/md9. what the version of ReiserFS do you use[1-4] (1) 3.6.x (2) >=3.5.9 (introduced in the middle of 1999) (if you use linux 2.2, choose this one) (3) < 3.5.9 converted to new format (don't choose if unsure) (4) < 3.5.9 (this is very old format, don't choose if unsure) (X) exit 1 Enter block size [4096]: 4096 No journal device was specified. (If journal is not available, re-run with --no- journal-available option specified). Is journal default? (y/n)[y]: y Did you use resizer(y/n)[n]: n rebuild-sb: no uuid found, a new uuid was generated (b0894fe9-3850-4d57-b70b-a41 9cbf3823e) rebuild-sb: You either have a corrupted journal or have just changed the start of the partition with some partition table editor. If you are sure that the start of the partition is ok, rebuild the journal header. Do you want to rebuild the journal header? (y/n)[n]: y Joe L.
June 2, 201115 yr Author Thanks Joe. When I try umount /mnt/disk9 it says the disk is not found. Is this the correct syntax? Should it be umount /dev/md9 like the wiki states? In any case, I am getting this: root@Cooper:~# reiserfsck --fix-fixable /dev/md9 reiserfsck 3.6.21 (2009 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will check consistency of the filesystem on /dev/md9 and will fix what can be fixed without --rebuild-tree Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ########### reiserfsck --fix-fixable started at Thu Jun 2 10:42:39 2011 ########### Replaying journal: No transactions found Zero bit found in on-disk bitmap after the last valid bit. Fixed. Checking internal tree.. Bad root block 0. (--rebuild-tree did not complete) Aborted root@Cooper:~#
June 2, 201115 yr Thanks Joe. When I try umount /mnt/disk9 it says the disk is not found. Is this the correct syntax? Should it be umount /dev/md9 like the wiki states? In any case, I am getting this: root@Cooper:~# reiserfsck --fix-fixable /dev/md9 reiserfsck 3.6.21 (2009 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will check consistency of the filesystem on /dev/md9 and will fix what can be fixed without --rebuild-tree Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ########### reiserfsck --fix-fixable started at Thu Jun 2 10:42:39 2011 ########### Replaying journal: No transactions found Zero bit found in on-disk bitmap after the last valid bit. Fixed. Checking internal tree.. Bad root block 0. (--rebuild-tree did not complete) Aborted root@Cooper:~# My oversight... It says that because the disk (disk9) is not currently mounted, therefore, you can skip that step. (if it had been mounted, either /mnt/disk9 or /dev/md9 would have worked)
June 2, 201115 yr Author Interesting, I didn't get those prompts when running reiserfsck --rebuild-sb /dev/md9: root@Cooper:~# reiserfsck --rebuild-sb /dev/md9 reiserfsck 3.6.21 (2009 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will check superblock and rebuild it if needed Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes Reiserfs super block in block 16 on 0x909 of format 3.6 with standard journal Count of blocks on the device: 366284624 Number of bitmaps: 11179 Blocksize: 4096 Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 0 Root block: 0 Filesystem is NOT clean Tree height: 0 Hash function used to sort names: not set Objectid map size 0, max 972 Journal parameters: Device [0x0] Magic [0x0] Size 8193 blocks (including 1 for journal header) (first block 18) Max transaction length 1024 blocks Max batch size 900 blocks Max commit age 30 Blocks reserved by journal: 0 Fs state field: 0x1: some corruptions exist. sb_version: 2 inode generation number: 0 UUID: 1514f794-9bb4-4a44-af63-4c4085fe960c LABEL: Set flags in SB: Mount count: 1 Maximum mount count: 30 Last fsck run: Wed Jun 1 16:35:29 2011 Check interval in days: 180 Super block seems to be correct root@Cooper:~#
Archived
This topic is now archived and is closed to further replies.