January 11, 201412 yr Hello, I'm really new to Unraid so keep your patient... I installed a Unraid System (5.04) with 2 drives: 1 WD RED 1 TB and 1 WD 250 GB I configured all and start transfer all my data to the NAS. Today i installed one WD green 1 TB as a Parity drive. After the reboot the system was OK and started to build the parity. I them rebooted the system again for cable management and after it startup again the WD Red (with Data) was missing. It was the power cable disconnected. I solved the problem with the cable but now I get that drive "Unformated" in the system. I ran Reiserfsck and the drive is ok: See below the report. How can I recover this drive ? ------------ root@Tower:~# reiserfsck --check /dev/sdb1 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/sdb1 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 Sat Jan 11 14:32:27 2014 ########### Replaying journal: Trans replayed: mountid 12, transid 96559, desc 1958, len 1, commit 1960, next trans offset 1943 Trans replayed: mountid 12, transid 96560, desc 1961, len 1, commit 1963, next trans offset 1946 Trans replayed: mountid 12, transid 96561, desc 1964, len 7, commit 1972, next trans offset 1955 Trans replayed: mountid 12, transid 96562, desc 1973, len 8, commit 1982, next trans offset 1965 Trans replayed: mountid 12, transid 96563, desc 1983, len 8, commit 1992, next trans offset 1975 Trans replayed: mountid 12, transid 96564, desc 1993, len 7, commit 2001, next trans offset 1984 Replaying journal: Done. Reiserfs journal '/dev/sdb1' in blocks [18..8211]: 6 transactions replayed Checking internal tree.. finished Comparing bitmaps..finished Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 43532 Internal nodes 269 Directories 26 Other files 12399 Data block pointers 40996945 (256 of them are zero) Safe links 0 ########### reiserfsck finished at Sat Jan 11 14:38:32 2014 ------------------------
January 11, 201412 yr After you installed the new Parity drive, you said 'it started to build the parity'. Did that finish before you rebooted?
January 11, 201412 yr Author Nop, the parity was at about 5%..... My sysLog in attachement... Thank You all! SysLog.txt
January 11, 201412 yr Author I run the reiserfs checkup and “--rebuild-sb option” and the system seems ok now. Reiserfs was done according to: http://lime-technology.com/forum/index.php?topic=1483 Then the new re-run of checkup give me: 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 Sat Jan 11 22:57:38 2014 ########### Replaying journal: Done. Reiserfs journal '/dev/sdb' in blocks [18..8211]: 0 transactions replayed Checking internal tree.. finished Comparing bitmaps..finished Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 28338 Internal nodes 190 Directories 29 Other files 11677 Data block pointers 25809355 (3081306 of them are zero) Safe links 0 ########### reiserfsck finished at Sat Jan 11 22:57:55 2014 ---------------- Then when I re-start the Array the drive still appear unformatted. Any ideas ?
January 12, 201412 yr The file system is on the first partition,YOU built a superblock on the raw drive (/dev/sdb instead of the correct /dev/sdb1 ) Additionally... you should NOT be running reiserfsck on the /dev/sdX devices at all, as any fixes made invalidated parity as it did not get updated in sync. You should have run reiserfsck on the /dev/mdX device corresponding to your disk. So, you need to run reiserfsck on the /dev/sdb1 device, you'll probably need to re-build the superblock once more, but let it tell you what to do. Then, since parity is now incorrect, get it back in sync by running a correcting parity check. Then, forget the /dev/sdX devices exist and always future perform file-system repairs on the /dev/mdX devices.
January 12, 201412 yr Author Thank you for your help Joe L., I ran "reiserfsck --check /dev/sdd1" The system told me to run "--rebuild-tree", so I did. After i run again the --check and the system told me everything is ok: I tried to build the array again, but the drive still says unformatted Then I tried: reiserfsck --rebuild-sd /dev/sdd1, but I get the report that is ok: ----------------------- root@Tower:~# reiserfsck --rebuild-sb /dev/sdd1 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 0x831 of format 3.6 with standard journal Count of blocks on the device: 244190624 Number of bitmaps: 7453 Blocksize: 4096 Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 204065780 Root block: 8384 Filesystem is clean Tree height: 5 Hash function used to sort names: "r5" Objectid map size 20, max 972 Journal parameters: Device [0x0] Magic [0x2d7396f5] 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: 0x0: sb_version: 2 inode generation number: 300 UUID: 14932c7c-4229-4690-9ab1-62af3d9c5620 LABEL: Set flags in SB: ATTRIBUTES CLEAN Mount count: 1 Maximum mount count: 30 Last fsck run: Sun Jan 12 11:55:50 2014 Check interval in days: 180 Super block seems to be correct ------------------------------------------- What am I doing wrong ? In maintenance mode I have the option for "Rebuild will start Data-Rebuild". Should I gave that option a try?
January 12, 201412 yr post a syslog. You are basically doing things that will harm your ability to recover your data by running commands blindly. An "un-formatted" disk, to unRAID, is ANY disk whose first partition cannot be mounted as a reiserfs files system (for ANY reason) Attempting a fix, without knowing the reason the "mount" command failed, is a mistake. It could be file-system corruption, or more likely, you've overwritten (probably) the MBR of the disk by running the rebuild-sb on the raw drive. Post a syslog. Post the output of fdisk -lu /dev/sdX
January 12, 201412 yr Author Here it is... root@Tower:~# fdisk -lu /dev/sdd Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes 1 heads, 63 sectors/track, 31008336 cylinders, total 1953525168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdd1 64 1953525167 976762552 83 Linux Partition 1 does not end on cylinder boundary. root@Tower:~# SysLog_2.txt
January 14, 201412 yr Author What does it mean that partition 1 doesnt end on cylinder boundary ? Doing a search on Google this seems not to be the problem... Any ideas on how to fix the "unformatted drive" ? It seams a very often problem on Unraid but I can't find a straight answer.... Thanks again for all that tried to help. André Palmela Azeitão - Portugal ______________________ Sent using Tapatalk
January 16, 201412 yr Author Today I started my server with an Ubuntu distro and I can access all my data. The question remains: why is Unraid reporting this drive as unformated? My problem is solved but I think that developers should investigate this further.... André Palmela Azeitão - Portugal ______________________ Sent using Tapatalk
Archived
This topic is now archived and is closed to further replies.