June 6, 201115 yr Author I think we are checking the wrong disk now. I answered yes, then did what it said: Is this ok ? (y/n)[n]: y The fs may still be unconsistent. Run reiserfsck --check. root@Cooper:~# reiserfsck --check /dev/sda1 The HDD access light is on the wrong drive.
June 6, 201115 yr When I say no, it says "Super block was not written" and quits. I guess you need to answer "y" then. Have you been physically moving disks around since you posted the screen shot earlier in this thread? If not, then your motherboard is initializing the disks in different orders depending on when they spin up and are ready. From the "ls" command output, the /dev/sda disk is the one with the serial number that ends in XP9F. That old screen shot showed it as disk10. Until you figure out which disk is which, you'll be fighting to get things corrected. The device name can change from one boot to the next, it is a "feature" of linux. (nothing to do with unRAID, just on how they elected to speed the boot process by assigning device names as they initialize) Sorry to give you the news, but if you've been running the reiserfsck command on /dev/sda1, it is not the disk with the original issue, and not on the copy we made. Please make sure you are running the commands on the correct disk by verification by the size, model, and serial number.
June 6, 201115 yr Author Hmm... it seems you're right. All I've done is physically remove the bad drive from the array and rebooted after the copy completed, but I now realize this changed the disk order. Arg! The disk the contents were copied to is now at sdu / sdu1. This is what I've done on this disk thus far now: root@Cooper:~# reiserfsck --check /dev/sdu1 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 read-only check consistency of the filesystem on /dev/sdu1 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 --check started at Mon Jun 6 12:20:37 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 root@Cooper:~# reiserfsck --rebuild-sb /dev/sdu1 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 Did you use resizer(y/n)[n]: n rebuild-sb: wrong block count occured (366284624), fixed (488378624) rebuild-sb: wrong bitmap number occured (11179), fixed (14905) rebuild-sb: wrong tree height occured (65535), zeroed Reiserfs super block in block 16 on 0x4141 of format 3.6 with standard journal Count of blocks on the device: 488378624 Number of bitmaps: 14905 Blocksize: 4096 Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 366284624 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: 0x3: FATAL corruptions exist. 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 Is this ok ? (y/n)[n]: y The fs may still be unconsistent. Run reiserfsck --check. root@Cooper:~# reiserfsck --rebuild-sb /dev/sdu1 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 0x4141 of format 3.6 with standard journal Count of blocks on the device: 488378624 Number of bitmaps: 14905 Blocksize: 4096 Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 366284624 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: 0x3: FATAL corruptions exist. 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:~# reiserfsck --check /dev/sdu1 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 read-only check consistency of the filesystem on /dev/sdu1 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 --check started at Mon Jun 6 12:23:28 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
June 7, 201115 yr Author It corrected a bunch of stuff, then spat this out: Could not find a hash in use. Using "r5" Selected hash ("r5") does not match to the hash set in the super block (not set). "r5" hash is selected Flushing..finished Read blocks (but not data blocks) 434693323 Leaves among those 11 - leaves all contents of which could not be saved and deleted 11 Objectids found 2 Pass 1 (will try to insert 0 leaves): ####### Pass 1 ####### Looking for allocable blocks .. finished Flushing..finished 0 leaves read 0 inserted ####### Pass 2 ####### Flushing..finished No reiserfs metadata found. If you are sure that you had the reiserfs on this partition, then the start of the partition might be changed or all data were wiped out. The start of the partition may get changed by a partitioner if you have used one. Then you probably rebuilt the superblock as there was no one. Zero the block at 64K offset from the start of the partition (a new super block you have just built) and try to move the start of the partition a few cylinders aside and check if debugreiserfs /dev/xxx detects a reiserfs super block. If it does this is likely to be the right super block version. If this makes you nervous, try www.namesys.com/support.html, and for $25 the author of fsck, or a colleague if he is out, will step you through it all. Aborted I know for a fact the original (bad) drive was unaligned. The new drive that it was copied is 4k aligned. Would this matter?
June 7, 201115 yr I know for a fact the original (bad) drive was unaligned. The new drive that it was copied is 4k aligned. Would this matter? no, it would not matter. BUT, if the partition actually stars on sector 63 instead of 64, then you need to fix that before the reiserfsck can find the file system. (Otherwise, it will be looking in the wrong place) Are you sure the partition starts on sector 64? Type fdisk -lu /dev/sdX to find out.
June 7, 201115 yr Author WARNING: GPT (GUID Partition Table) detected on '/dev/sdt'! The util fdisk doesn't support GPT. Use GNU Parted. Disk /dev/sdt: 2000.4 GB, 2000398934016 bytes 1 heads, 63 sectors/track, 62016336 cylinders, total 3907029168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdt1 64 3907029167 1953514552 83 Linux Partition 1 does not end on cylinder boundary.
June 7, 201115 yr WARNING: GPT (GUID Partition Table) detected on '/dev/sdt'! The util fdisk doesn't support GPT. Use GNU Parted. Disk /dev/sdt: 2000.4 GB, 2000398934016 bytes 1 heads, 63 sectors/track, 62016336 cylinders, total 3907029168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdt1 64 3907029167 1953514552 83 Linux Partition 1 does not end on cylinder boundary. You can use the utility Tom included on the 5.0beta6 release to fix the partitioning to start on sector 63, or the shell script I wrote will do the same (I think it was named unraid_partition_disk.sh )
June 8, 201115 yr Author Awesome news. Another one of my drives completely died (complete hardware failure / click of death) during all of this, so I lost another 500 GB. I decided to cut my losses, pull the "new" dead drive, the dying drive, and the drive I copied the dying drive to. Replaced all 3 with new drives and let unraid do its thing. It appears to have done data rebuild, but all 3 new drives are empty so it didn't actually write anything to them. It says the parity is valid, but I'm not entirely sure if that's true. At any rate everything is green now, and I can browse my shares. Not sure what is missing yet, though. I will still try and see if I can recover what was lost on the dying 1.5 TB drive (which was copied to the new 2 TB drive) when I do a little research in that script you mentioned... But in the meantime I'm getting permission denied when trying to write / delete on some of my shares. God, this is such a mess...
June 8, 201115 yr Author I tried running the permission script under utils, but still being denied access to write / delete.
June 9, 201115 yr Author You can use the utility Tom included on the 5.0beta6 release to fix the partitioning to start on sector 63, or the shell script I wrote will do the same (I think it was named unraid_partition_disk.sh ) How can I use this if I have the drive attached via an external USB dock? All my slots are now full with replacements. Thanks!
Archived
This topic is now archived and is closed to further replies.