February 24, 201214 yr Hi Guys, I restarted last night so I could take a disk out of the array, but now my cache drive shows up as unformatted... I tried "reiserfsck --check" and it said no valid superblock, so I then ran "reiserfsck --rebuild-sb", which also didn't work, ending with the error "Bad root block 0". So according to this site: http://www.cyberciti.biz/tips/repairing-reiserfs-file-system-with-reiserfsck.html I needed to run "reiserfsck --scan-whole-partition --rebuild-tree /dev/sdb" The output of which was: ** 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 rebuild the filesystem (/dev/sdb) 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 Replaying journal: No transactions found Zero bit found in on-disk bitmap after the last valid bit. Fixed. ########### reiserfsck --rebuild-tree started at Thu Feb 23 23:56:58 2012 ########### Pass 0: ####### Pass 0 ####### The whole partition (244190640 blocks) is to be scanned Skipping 15663 blocks (super block, journal, bitmaps) 244174977 blocks will be read 0%block 2760791: The number of items (3) is incorrect, should be (0) - corrected block 2760791: The free space (0) is incorrect, should be (4072) - corrected ....block 151773754: The number of items (1) is incorrect, should be (0) - corrected block 151773754: The free space (17) is incorrect, should be (4072) - corrected block 151972582: The number of items (2560) is incorrect, should be (1) - corrected block 151972582: The free space (2048) is incorrect, should be (1488) - corrected pass0: vpf-10110: block 151972582, item (0): Unknown item type found [100663041 117444096 0x1e000d00 (15)] - deleted block 153132888: The number of items (1) is incorrect, should be (0) - corrected block 153132888: The free space (65487) is incorrect, should be (4072) - corrected block 242765888: The number of items (2048) is incorrect, should be (1) - corrected block 242765888: The free space (512) is incorrect, should be (1488) - corrected pass0: vpf-10110: block 242765888, item (0): Unknown item type found [100663550 218104576 0x4c000800 (15)] - deleted left 0, 22262 /secc 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) 244174977 Leaves among those 5 - leaves all contents of which could not be saved and deleted 5 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 Which.. didn't work. Now I'm stuck. The disk is ok (No smart errors) and I *haven't* formatted it. There was some data on there that was due to be moved to the array once the disks had been swapped round (no space...) It was data, as sods law states, that *isn't* somewhere else, which is irritating given all 7.5 TB of data in the array is actually duplicated somewhere else. Edit: output of --check now: 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) 244174977 Leaves among those 5 - leaves all contents of which could not be saved and deleted 5 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 root@Tower:~# reiserfsck --check /dev/sdb 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/sdb 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 Fri Feb 24 07:41:26 2012 ########### Replaying journal: No transactions found Checking internal tree.. Bad root block 0. (--rebuild-tree did not complete) Aborted Ideas? Edit 2: HDParm output HDParm Info for /dev/sdb /dev/sdb: ATA device, with non-removable media Model Number: Hitachi HDT721010SLA360 Serial Number: STF607MH1PGY1W Firmware Revision: ST6OA31B Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6; Revision: ATA8-AST T13 Project D1697 Revision 0b Standards: Used: unknown (minor revision code 0x0029) Supported: 8 7 6 5 Likely used: 8 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBA user addressable sectors: 268435455 LBA48 user addressable sectors: 1953525168 Logical/Physical Sector size: 512 bytes device size with M = 1024*1024: 953869 MBytes device size with M = 1000*1000: 1000204 MBytes (1000 GB) cache/buffer size = 15001 KBytes (type=DualPortCache) Nominal Media Rotation Rate: 7200 Capabilities: LBA, IORDY(can be disabled) Queue depth: 32 Standby timer values: spec'd by Standard, no device specific minimum R/W multiple sector transfer: Max = 16 Current = 16 Advanced power management level: disabled Recommended acoustic management value: 128, current value: 254 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 udma6 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: * SMART feature set Security Mode feature set * Power Management feature set * Write cache * Look-ahead * Host Protected Area feature set * WRITE_BUFFER command * READ_BUFFER command * DOWNLOAD_MICROCODE Advanced Power Management feature set Power-Up In Standby feature set SET_FEATURES required to spinup after power up Address Offset Reserved Area Boot SET_MAX security extension * Automatic Acoustic Management feature set * 48-bit Address feature set * Device Configuration Overlay feature set * Mandatory FLUSH_CACHE * FLUSH_CACHE_EXT * SMART error logging * SMART self-test Media Card Pass-Through * General Purpose Logging feature set * WRITE_{DMA|MULTIPLE}_FUA_EXT * 64-bit World wide name * URG for READ_STREAM[_DMA]_EXT * URG for WRITE_STREAM[_DMA]_EXT * WRITE_UNCORRECTABLE_EXT command * Segmented DOWNLOAD_MICROCODE * Gen1 signaling speed (1.5Gb/s) * Gen2 signaling speed (3.0Gb/s) * Native Command Queueing (NCQ) * Host-initiated interface power management * Phy event counters * NCQ priority information Non-Zero buffer offsets in DMA Setup FIS DMA Setup Auto-Activate optimization Device-initiated interface power management In-order data delivery * Software settings preservation * SMART Command Transport (SCT) feature set * SCT LBA Segment Access (AC2) * SCT Error Recovery Control (AC3) * SCT Features Control (AC4) * SCT Data Tables (AC5) Security: Master password revision code = 65534 supported not enabled not locked not frozen not expired: security count not supported: enhanced erase 324min for SECURITY ERASE UNIT. Logical Unit WWN Device Identifier: 5000cca349d7db5e NAA : 5 IEEE OUI : 000cca Unique ID : 349d7db5e Checksum: correct
February 24, 201214 yr Author root@Tower:~# debugreiserfs /dev/sdb debugreiserfs 3.6.21 (2009 www.namesys.com) Filesystem state: consistency is not checked after last mounting Reiserfs super block in block 16 on 0x810 of format 3.6 with standard journal Count of blocks on the device: 244190640 Number of bitmaps: 7453 Blocksize: 4096 Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 244190640 Root block: 0 Filesystem is NOT clean Tree height: 65535 Hash function used to sort names: "r5" Objectid map size 2, 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: 0xfa02: FATAL corruptions exist. sb_version: 2 inode generation number: 0 UUID: 96a4bd08-0788-416d-af37-429263759ef3 LABEL: Set flags in SB: Mount count: 1 Maximum mount count: 30 Last fsck run: Thu Feb 23 23:10:10 2012 Check interval in days: 180 Edit 4: I think I know what I ****ed up, I did /dev/sdb not sdb1, because sdb1 didn't exist. Time to get the recovery software out!!
February 24, 201214 yr Author Right, My data is still all there (photorec - part of test disk) can recover it. I however, don't have a partition table it seems. fdisk -l /dev/sdb lists no partitions. So, how do I give it a partition table without loosing the files? The disk was pre cleared and then formatted using the UnRAID GUI, so all the settings should be default as per 5b6.
February 24, 201214 yr hopefully one of the guru's can give you the specific command, but I believe the program you need to use (or at least do some research on to see if it can do what you need) is 'sfdisk'
February 24, 201214 yr Hi Guys, I restarted last night so I could take a disk out of the array, but now my cache drive shows up as unformatted... I tried "reiserfsck --check" and it said no valid superblock, so I then ran "reiserfsck --rebuild-sb", which also didn't work, ending with the error "Bad root block 0". So according to this site: http://www.cyberciti.biz/tips/repairing-reiserfs-file-system-with-reiserfsck.html I needed to run "reiserfsck --scan-whole-partition --rebuild-tree /dev/sdb" Forcing this on /dev/sdb will overwrite the MBR and partition table, if it runs at all. The file system is on the first partition ( /dev/sdb1) Joe L.
February 24, 201214 yr Right, My data is still all there (photorec - part of test disk) can recover it. I however, don't have a partition table it seems. fdisk -l /dev/sdb lists no partitions. So, how do I give it a partition table without loosing the files? The disk was pre cleared and then formatted using the UnRAID GUI, so all the settings should be default as per 5b6. You can use the "mkmbr" program to restore the partitioning without affecting the data. You just need to know if your partition started on sector 64, or sector 63?
February 24, 201214 yr Author Right, My data is still all there (photorec - part of test disk) can recover it. I however, don't have a partition table it seems. fdisk -l /dev/sdb lists no partitions. So, how do I give it a partition table without loosing the files? The disk was pre cleared and then formatted using the UnRAID GUI, so all the settings should be default as per 5b6. You can use the "mkmbr" program to restore the partitioning without affecting the data. You just need to know if your partition started on sector 64, or sector 63? Given it's not a AF drive, sector 63. Sod's law states that it would have been sector 64. Let's try sector 63 anyway. What would the command be if its /dev/sdb? Thanks. Edit: Did some reading here: http://lime-technology.com/forum/index.php?topic=11540.0 Then did "mkmbr /dev/sdb 63 0x83" Now I have a partition table band I am running "reiserfsck --check /dev/sdb1"
February 24, 201214 yr Right, My data is still all there (photorec - part of test disk) can recover it. I however, don't have a partition table it seems. fdisk -l /dev/sdb lists no partitions. So, how do I give it a partition table without loosing the files? The disk was pre cleared and then formatted using the UnRAID GUI, so all the settings should be default as per 5b6. You can use the "mkmbr" program to restore the partitioning without affecting the data. You just need to know if your partition started on sector 64, or sector 63? I do not recommend you use sfdisk or any other partitioning tool other than "mkmbr" or the shell script version I created "unraid_partition_disk.sh", as if you get the partition definition wrong (not exactly as unRAId would have partitioned it) unRAID will not recognize the disk as its own and it will re-partition/re-format it.
February 24, 201214 yr What would the command be if its /dev/sdb? Thanks. According to the release notes (excerpt below) it is mkmbr /dev/sdb It was described in this post for the 5.0b6 release : http://lime-technology.com/forum/index.php?topic=11540.0 Also included with this release is command-line utility called "mkmbr". Here is the documentation: /* mkmbr <device> [<offset> [<type>]] * * This program may be used to write an "unRAID style MBR". This is simply a normal MBR * with a single partition 1 starting in either sector 63 or sector 64 and spanning the * entire remaining size of the disk. For normal operation, partition 1 "type" is set * to 0x83 (Linux). A special case is this: if "type" is set to 0, this is recognized * by the unRAID management utility as a "factory erased" disk, that is, the entire * contents of partition 1 are presumed set to zeros. This lets us add the disk immediately * to an existing array without disturbing parity. If you use this program to set "type" * to 0, but partition 1 is not all-zeros, you will not be able to reconstruct a failed * drive - you have been warned! * * This program only handles hard drives less than 2TB in size; however, an attempt to * write the MBR on a hard drive larger than 2TB should be recognized and cause the program * to exit without writing anything. (Should output an "inconsistent size" message.) * * The four useful combinations for unRAID are (using /dev/sdc for example): * mkmbr /dev/sdc 63 0x83 => normal MBR, partition 1 starts in sector 63 * mkmbr /dev/sdc 64 0x83 => normal MBR, partition 1 starts in sector 64 * mkmbr /dev/sdc 63 0 => factory erased, partition 1 starts in sector 63 * mkmbr /dev/sdc 64 0 => factory erased, partition 1 starts in sector 64 * * Since offset and type default to 63 and 0x83 respectively, one could use instead: * mkmbr /dev/sdc => normal MBR, partition 1 starts in sector 63 * mkmbr /dev/sdc 64 => normal MBR, partition 1 starts in sector 64 * * You could also use this program to create an MBR of any "type" with partition 1 starting * at any "offset" (and spanning remaining space on disk). The unRAID management utility * will deem the MBR "unknown" however. */ This utility may be used to repair a MBR which has been written incorrectly. Please note: this utility, like most MBR utilities, only writes sector 0 of the disk. It does not destroy any file data, and does not render a disk useless (though it might be temporarily useless until MBR is corrected). There is a lot of lore surrounding MBR's and partitioning which has created great confusion over the years. In reality, the data structure of a MBR is extremely simple, and much of the complication surrounding them has to do with getting a simple data structure to represent something more complex than it was originally designed for. With unRaid however, use of the MBR is extremely simple - no funny business with extended partitions, hidden partitions, etc. If you have issues with MBR's please post here and we will sort out what's happening.
February 24, 201214 yr Author Thanks, I found that too Running "reiserfsck --rebuild-tree /dev/sdb1" now as --check errored
February 24, 201214 yr My understanding is that the beta's use 4k aligned or sector 64 as the default. So, unless you purposely used sector 63 during the preclear, I would expect the partition started at 64.
February 25, 201214 yr Author My understanding is that the beta's use 4k aligned or sector 64 as the default. So, unless you purposely used sector 63 during the preclear, I would expect the partition started at 64. It was 63, as I don't format my drives with 64 unless the are actually 64. Data was recovered, did a pre clear and reformatted and we are back in business.
Archived
This topic is now archived and is closed to further replies.