February 20, 201313 yr I rebuilt a disk after preclear earlier today and now that disk is showing as unformatted. I now need help on what to do. Im assuming I could just rebuild the disk again though I would like to know why its showing as unformatted right now. Edit: Little more information on what happened. It started with this, http://lime-technology.com/forum/index.php?topic=25993.0 . My disk was showing some pending sectors so I stopped the array, unassigned the disk, started the array, stopped the array, precleared the removed disk to try to force more errors out, Disk was clean so I reassigned, started the array, hit rebuild. After hitting rebuild the array acted like I assumed it would, reads on parity and disk 1 and writes on disk 2. Once the rebuild was done is when the disk showed as unformatted which is where I am at now.
February 20, 201313 yr I rebuilt a disk after preclear earlier today and now that disk is showing as unformatted. I now need help on what to do. Im assuming I could just rebuild the disk again though I would like to know why its showing as unformatted right now. Edit: Little more information on what happened. It started with this, http://lime-technology.com/forum/index.php?topic=25993.0 . My disk was showing some pending sectors so I stopped the array, unassigned the disk, started the array, stopped the array, precleared the removed disk to try to force more errors out, Disk was clean so I reassigned, started the array, hit rebuild. After hitting rebuild the array acted like I assumed it would, reads on parity and disk 1 and writes on disk 2. Once the rebuild was done is when the disk showed as unformatted which is where I am at now. 1. post a syslog 2. see #1. 3. un-formatted simply means not-mounted. (99% of the time) Now to figure out why it did not mount. You can try running reiserfsck on the /dev/mdX device corresponding to the diskX number. If disk4, the command would then be: reiserfsck --check /dev/md4 Report the results. reconstructing a disk that will not mount (because of file-system errors of some kind) will result in an identical disk that will not mount (with the exact same file system errors).
February 20, 201313 yr Author Feb 20 07:55:41 Tower emhttp: shcmd (380): /usr/local/sbin/emhttp_event stopping_svcs (Other emhttp) Feb 20 07:55:41 Tower emhttp_event: stopping_svcs (Other emhttp) Feb 20 07:55:41 Tower emhttp: shcmd (381): ps axc | grep -q rpc.mountd (Other emhttp) Feb 20 07:55:41 Tower emhttp: _shcmd: shcmd (381): exit status: 1 (Other emhttp) Feb 20 07:55:41 Tower emhttp: Stop SMB... (Other emhttp) Feb 20 07:55:41 Tower emhttp: shcmd (382): /etc/rc.d/rc.samba stop |$stuff$ logger (Other emhttp) Feb 20 07:55:41 Tower emhttp: Spinning up all drives... (Other emhttp) Feb 20 07:55:41 Tower emhttp: shcmd (383): /usr/sbin/hdparm -S0 /dev/sde $stuff$> /dev/null (Drive related) Feb 20 07:55:41 Tower kernel: mdcmd (22): spinup 0 (Routine) Feb 20 07:55:41 Tower kernel: mdcmd (23): spinup 1 (Routine) Feb 20 07:55:41 Tower kernel: mdcmd (24): spinup 2 (Routine) Feb 20 07:55:41 Tower emhttp: Sync filesystems... (Other emhttp) Feb 20 07:55:41 Tower emhttp: shcmd (384): sync (Other emhttp) Feb 20 07:55:56 Tower emhttp: shcmd (385): /usr/local/sbin/emhttp_event unmounting_disks (Other emhttp) Feb 20 07:55:56 Tower emhttp_event: unmounting_disks (Other emhttp) Feb 20 07:56:17 Tower emhttp: shcmd (386): set -o pipefail ; umount /mnt/user0 |$stuff$ logger (Other emhttp) Feb 20 07:56:18 Tower emhttp: shcmd (387): rmdir /mnt/user0 |$stuff$ logger (Other emhttp) Feb 20 07:56:18 Tower emhttp: shcmd (388): set -o pipefail ; umount /mnt/user |$stuff$ logger (Other emhttp) Feb 20 07:56:18 Tower emhttp: shcmd (389): rmdir /mnt/user |$stuff$ logger (Other emhttp) Feb 20 07:56:18 Tower emhttp: shcmd (390): crontab -c /etc/cron.d -d $stuff$> /dev/null (Other emhttp) Feb 20 07:56:18 Tower emhttp: Unmounting disks... (Other emhttp) Feb 20 07:56:18 Tower emhttp: shcmd (391): umount /mnt/disk1 |$stuff$ logger (Other emhttp) Feb 20 07:56:19 Tower emhttp: shcmd (392): rmdir /mnt/disk1 |$stuff$ logger (Other emhttp) Feb 20 07:56:19 Tower emhttp: shcmd (393): umount /mnt/cache |$stuff$ logger (Other emhttp) Feb 20 07:56:20 Tower emhttp: shcmd (394): rmdir /mnt/cache |$stuff$ logger (Other emhttp) Feb 20 07:56:20 Tower emhttp: shcmd (395): /usr/local/sbin/emhttp_event stopping_array (Other emhttp) Feb 20 07:56:20 Tower emhttp_event: stopping_array (Other emhttp) Feb 20 07:56:20 Tower kernel: mdcmd (25): stop (unRAID engine) Feb 20 07:56:20 Tower kernel: md1: stopping (Drive related) Feb 20 07:56:20 Tower kernel: md2: stopping (Drive related) Feb 20 07:56:20 Tower emhttp: shcmd (396): rmmod md-mod |$stuff$ logger (Other emhttp) Feb 20 07:56:20 Tower emhttp: shcmd (397): modprobe md-mod super=/boot/config/super.dat slots=6 |$stuff$ logger (unRAID engine) Feb 20 07:56:20 Tower kernel: md: unRAID driver removed (System) Feb 20 07:56:20 Tower emhttp: shcmd (398): udevadm settle (Other emhttp) Feb 20 07:56:20 Tower kernel: md: unRAID driver 2.1.4 installed (System) Feb 20 07:56:20 Tower emhttp: Device inventory: (Drive related) Feb 20 07:56:20 Tower emhttp: WDC_WD20EADS-00W4B0_WD-WCAVY5404768 (sdb) 1953514584 (Drive related) Feb 20 07:56:20 Tower emhttp: WDC_WD20EARX-008FB0_WD-WCAZAH570580 (sdc) 1953514584 (Drive related) Feb 20 07:56:20 Tower emhttp: WDC_WD20EADS-00W4B0_WD-WCAVY5827694 (sdd) 1953514584 (Drive related) Feb 20 07:56:20 Tower emhttp: ST3160023AS_5JS272FT (sde) 156290904 (Drive related) Feb 20 07:56:20 Tower kernel: mdcmd (1): import 0 8,16 1953514552 WDC_WD20EADS-00W4B0_WD-WCAVY5404768 (unRAID engine) Feb 20 07:56:20 Tower kernel: md: import disk0: [8,16] (sdb) WDC_WD20EADS-00W4B0_WD-WCAVY5404768 size: 1953514552 (Drive related) Feb 20 07:56:20 Tower kernel: mdcmd (2): import 1 8,32 1953514552 WDC_WD20EARX-008FB0_WD-WCAZAH570580 (unRAID engine) Feb 20 07:56:20 Tower kernel: md: import disk1: [8,32] (sdc) WDC_WD20EARX-008FB0_WD-WCAZAH570580 size: 1953514552 (Drive related) Feb 20 07:56:20 Tower kernel: mdcmd (3): import 2 8,48 1953514552 WDC_WD20EADS-00W4B0_WD-WCAVY5827694 (unRAID engine) Feb 20 07:56:20 Tower kernel: md: import disk2: [8,48] (sdd) WDC_WD20EADS-00W4B0_WD-WCAVY5827694 size: 1953514552 (Drive related) Feb 20 07:56:20 Tower kernel: mdcmd (4): import 3 0,0 (unRAID engine) Feb 20 07:56:20 Tower kernel: mdcmd (5): import 4 0,0 (unRAID engine) Feb 20 07:56:20 Tower kernel: mdcmd (6): import 5 0,0 (unRAID engine) Feb 20 07:56:20 Tower emhttp: shcmd (399): /usr/local/sbin/emhttp_event driver_loaded (System) Feb 20 07:56:20 Tower emhttp_event: driver_loaded (System) Feb 20 07:56:20 Tower emhttp: shcmd (400): /usr/local/sbin/emhttp_event stopped (Other emhttp) Feb 20 07:56:20 Tower emhttp_event: stopped (Other emhttp) Feb 20 07:56:20 Tower emhttp: shcmd (401): :>/etc/samba/smb-shares.conf (Other emhttp) Feb 20 07:56:20 Tower emhttp: Start SMB... (Other emhttp) Feb 20 07:56:20 Tower emhttp: shcmd (402): /etc/rc.d/rc.samba start |$stuff$ logger (Other emhttp) Feb 20 07:56:20 Tower logger: Starting Samba: /usr/sbin/nmbd -D Feb 20 07:56:20 Tower logger: /usr/sbin/smbd -D Feb 20 07:56:21 Tower emhttp: shcmd (403): ps axc | grep -q rpc.mountd (Other emhttp) Feb 20 07:56:21 Tower emhttp: _shcmd: shcmd (403): exit status: 1 (Other emhttp) Feb 20 07:56:21 Tower emhttp: shcmd (404): rmmod md-mod |$stuff$ logger (Other emhttp) Feb 20 07:56:21 Tower emhttp: shcmd (405): modprobe md-mod super=/boot/config/super.dat slots=6 |$stuff$ logger (unRAID engine) Feb 20 07:56:21 Tower kernel: md: unRAID driver removed (System) Feb 20 07:56:21 Tower emhttp: shcmd (406): udevadm settle (Other emhttp) Feb 20 07:56:21 Tower kernel: md: unRAID driver 2.1.4 installed (System) Feb 20 07:56:21 Tower emhttp: Device inventory: (Drive related) Feb 20 07:56:21 Tower emhttp: WDC_WD20EADS-00W4B0_WD-WCAVY5404768 (sdb) 1953514584 (Drive related) Feb 20 07:56:21 Tower emhttp: WDC_WD20EARX-008FB0_WD-WCAZAH570580 (sdc) 1953514584 (Drive related) Feb 20 07:56:21 Tower emhttp: WDC_WD20EADS-00W4B0_WD-WCAVY5827694 (sdd) 1953514584 (Drive related) Feb 20 07:56:21 Tower emhttp: ST3160023AS_5JS272FT (sde) 156290904 (Drive related) Feb 20 07:56:21 Tower kernel: mdcmd (1): import 0 8,16 1953514552 WDC_WD20EADS-00W4B0_WD-WCAVY5404768 (unRAID engine) Feb 20 07:56:21 Tower kernel: md: import disk0: [8,16] (sdb) WDC_WD20EADS-00W4B0_WD-WCAVY5404768 size: 1953514552 (Drive related) Feb 20 07:56:21 Tower kernel: mdcmd (2): import 1 8,32 1953514552 WDC_WD20EARX-008FB0_WD-WCAZAH570580 (unRAID engine) Feb 20 07:56:21 Tower kernel: md: import disk1: [8,32] (sdc) WDC_WD20EARX-008FB0_WD-WCAZAH570580 size: 1953514552 (Drive related) Feb 20 07:56:21 Tower kernel: mdcmd (3): import 2 8,48 1953514552 WDC_WD20EADS-00W4B0_WD-WCAVY5827694 (unRAID engine) Feb 20 07:56:21 Tower kernel: md: import disk2: [8,48] (sdd) WDC_WD20EADS-00W4B0_WD-WCAVY5827694 size: 1953514552 (Drive related) Feb 20 07:56:21 Tower kernel: mdcmd (4): import 3 0,0 (unRAID engine) Feb 20 07:56:21 Tower kernel: mdcmd (5): import 4 0,0 (unRAID engine) Feb 20 07:56:21 Tower kernel: mdcmd (6): import 5 0,0 (unRAID engine) Feb 20 07:56:21 Tower emhttp: shcmd (407): /usr/local/sbin/emhttp_event driver_loaded (System) Feb 20 07:56:21 Tower emhttp_event: driver_loaded (System) Feb 20 07:56:27 Tower emhttp: Spinning up all drives... (Other emhttp) Feb 20 07:56:27 Tower emhttp: shcmd (408): /usr/sbin/hdparm -S0 /dev/sde $stuff$> /dev/null (Drive related) Feb 20 07:56:27 Tower kernel: mdcmd (7): set md_num_stripes 1280 (unRAID engine) Feb 20 07:56:27 Tower kernel: mdcmd (: set md_write_limit 768 (unRAID engine) Feb 20 07:56:27 Tower kernel: mdcmd (9): set md_sync_window 384 (unRAID engine) Feb 20 07:56:27 Tower kernel: mdcmd (10): set spinup_group 0 0 (unRAID engine) Feb 20 07:56:27 Tower kernel: mdcmd (11): set spinup_group 1 0 (unRAID engine) Feb 20 07:56:27 Tower kernel: mdcmd (12): set spinup_group 2 0 (unRAID engine) Feb 20 07:56:27 Tower kernel: mdcmd (13): spinup 0 (Routine) Feb 20 07:56:27 Tower kernel: mdcmd (14): spinup 1 (Routine) Feb 20 07:56:27 Tower kernel: mdcmd (15): spinup 2 (Routine) Feb 20 07:56:27 Tower emhttp: shcmd (409): /usr/local/sbin/set_ncq sdb 1 $stuff$> /dev/null (Drive related) Feb 20 07:56:27 Tower emhttp: shcmd (410): /usr/local/sbin/set_ncq sdc 1 $stuff$> /dev/null (Drive related) Feb 20 07:56:27 Tower emhttp: shcmd (411): /usr/local/sbin/set_ncq sdd 1 $stuff$> /dev/null (Drive related) Feb 20 07:56:27 Tower emhttp: shcmd (412): /usr/local/sbin/set_ncq sde 1 $stuff$> /dev/null (Drive related) Feb 20 07:56:27 Tower emhttp: Start array... (Other emhttp) Feb 20 07:56:27 Tower kernel: mdcmd (16): start STOPPED (unRAID engine) Feb 20 07:56:27 Tower kernel: unraid: allocating 18660K for 1280 stripes (3 disks) Feb 20 07:56:27 Tower kernel: md1: running, size: 1953514552 blocks (Drive related) Feb 20 07:56:27 Tower kernel: md2: running, size: 1953514552 blocks (Drive related) Feb 20 07:56:27 Tower emhttp: shcmd (413): udevadm settle (Other emhttp) Feb 20 07:56:27 Tower emhttp: shcmd (414): /usr/local/sbin/emhttp_event array_started (Other emhttp) Feb 20 07:56:27 Tower emhttp_event: array_started (Other emhttp) Feb 20 07:56:27 Tower emhttp: Mounting disks... (Other emhttp) Feb 20 07:56:27 Tower emhttp: shcmd (415): mkdir /mnt/disk1 (Routine) Feb 20 07:56:27 Tower emhttp: shcmd (416): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md1 /mnt/disk1 |$stuff$ logger (Other emhttp) Feb 20 07:56:27 Tower kernel: REISERFS (device md1): found reiserfs format "3.6" with standard journal (Routine) Feb 20 07:56:27 Tower kernel: REISERFS (device md1): using ordered data mode (Routine) Feb 20 07:56:27 Tower kernel: reiserfs: using flush barriers Feb 20 07:56:27 Tower kernel: REISERFS (device md1): journal params: device md1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 (Routine) Feb 20 07:56:27 Tower kernel: REISERFS (device md1): checking transaction log (md1) (Routine) Feb 20 07:56:27 Tower kernel: REISERFS (device md1): Using r5 hash to sort names (Routine) Feb 20 07:56:27 Tower emhttp: shcmd (417): chmod 770 '/mnt/disk1' (Other emhttp) Feb 20 07:56:27 Tower emhttp: shcmd (418): chown nobody:users '/mnt/disk1' (Other emhttp) Feb 20 07:56:27 Tower emhttp: shcmd (419): mkdir /mnt/disk2 (Routine) Feb 20 07:56:27 Tower emhttp: shcmd (420): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md2 /mnt/disk2 |$stuff$ logger (Other emhttp) Feb 20 07:56:27 Tower kernel: REISERFS warning (device md2): sh-2021 reiserfs_fill_super: can not find reiserfs on md2 (Minor Issues) Feb 20 07:56:27 Tower logger: mount: wrong fs type, bad option, bad superblock on /dev/md2, Feb 20 07:56:27 Tower logger: missing codepage or helper program, or other error (Errors) Feb 20 07:56:27 Tower logger: In some cases useful info is found in syslog - try Feb 20 07:56:27 Tower logger: dmesg | tail or so Feb 20 07:56:27 Tower logger: Feb 20 07:56:27 Tower emhttp: _shcmd: shcmd (420): exit status: 32 (Other emhttp) Feb 20 07:56:27 Tower emhttp: disk2 mount error: 32 (Errors) Feb 20 07:56:27 Tower emhttp: shcmd (421): rmdir /mnt/disk2 (Other emhttp) Feb 20 07:56:27 Tower emhttp: shcmd (422): mkdir /mnt/cache (Other emhttp) Feb 20 07:56:27 Tower emhttp: shcmd (423): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/sde1 /mnt/cache |$stuff$ logger (Drive related) Feb 20 07:56:27 Tower kernel: REISERFS (device sde1): found reiserfs format "3.6" with standard journal (Routine) Feb 20 07:56:27 Tower kernel: REISERFS (device sde1): using ordered data mode (Routine) Feb 20 07:56:27 Tower kernel: reiserfs: using flush barriers Feb 20 07:56:27 Tower kernel: REISERFS (device sde1): journal params: device sde1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 (Routine) Feb 20 07:56:27 Tower kernel: REISERFS (device sde1): checking transaction log (sde1) (Drive related) Feb 20 07:56:27 Tower kernel: REISERFS (device sde1): Using r5 hash to sort names (Routine) Feb 20 07:56:27 Tower emhttp: shcmd (424): chmod 770 '/mnt/cache' (Other emhttp) Feb 20 07:56:27 Tower emhttp: shcmd (425): chown nobody:users '/mnt/cache' (Other emhttp) Feb 20 07:56:28 Tower emhttp: shcmd (426): mkdir /mnt/user0 (Other emhttp) Feb 20 07:56:28 Tower emhttp: shcmd (427): /usr/local/sbin/shfs /mnt/user0 -disks 16777214 -o noatime,big_writes,allow_other,default_permissions (Other emhttp) Feb 20 07:56:28 Tower emhttp: shcmd (428): mkdir /mnt/user (Other emhttp) Feb 20 07:56:28 Tower emhttp: shcmd (429): /usr/local/sbin/shfs /mnt/user -disks 16777215 2000000 -o noatime,big_writes,allow_other,default_permissions,remember=0 (Other emhttp) Feb 20 07:56:28 Tower emhttp: shcmd (430): crontab -c /etc/cron.d - <<< "# Generated mover schedule: 40 3 * * * /usr/local/sbin/mover |$stuff$ logger" (Other emhttp) Feb 20 07:56:28 Tower emhttp: shcmd (431): /usr/local/sbin/emhttp_event disks_mounted (Other emhttp) Feb 20 07:56:28 Tower emhttp_event: disks_mounted (Other emhttp) Feb 20 07:56:29 Tower sudo: root : TTY=console ; PWD=/ ; USER=nobody ; COMMAND=/usr/bin/python /mnt/cache/.Sabnzbd/SABnzbd.py -d -s 0.0.0.0:8081 --config-file /mnt/cache/.Sabnzbd --pid /var/run/sabnzbd/ > /dev/null 2>$stuff$1 Feb 20 07:56:33 Tower sudo: root : TTY=unknown ; PWD=/ ; USER=nobody ; COMMAND=/usr/bin/python /mnt/cache/.SickBeard/SickBeard.py --daemon --port 8082 --datadir /mnt/cache/.SickBeard --pidfile /var/run/sickbeard/sickbeard.pid > /dev/null 2>$stuff$1 Feb 20 07:56:37 Tower emhttp: shcmd (432): :>/etc/samba/smb-shares.conf (Other emhttp) Feb 20 07:56:37 Tower emhttp: Restart SMB... (Other emhttp) Feb 20 07:56:37 Tower emhttp: shcmd (433): killall -HUP smbd (Minor Issues) Feb 20 07:56:37 Tower emhttp: shcmd (434): ps axc | grep -q rpc.mountd (Other emhttp) Feb 20 07:56:37 Tower emhttp: _shcmd: shcmd (434): exit status: 1 (Other emhttp) Feb 20 07:56:37 Tower emhttp: shcmd (435): /usr/local/sbin/emhttp_event svcs_restarted (Other emhttp) Feb 20 07:56:37 Tower emhttp_event: svcs_restarted (Other emhttp) Feb 20 07:56:45 Tower in.telnetd[2629]: connect from 192.168.1.133 (192.168.1.133) (Routine) Feb 20 07:56:48 Tower login[2630]: ROOT LOGIN on '/dev/pts/0' from '192.168.1.133' (Logins) reiserfsck --check Will read-only check consistency of the filesystem on /dev/md2 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_open: the reiserfs superblock cannot be found on /dev/md2. Failed to open the filesystem. If the partition table has not been changed, and the partition is valid and it really contains a reiserfs partition, then the superblock is corrupted and you need to run this utility with --rebuild-sb.
February 20, 201313 yr First, that is not a complete syslog. It would also help to know what version of unRAID you are running? See here: http://lime-technology.com/forum/index.php?topic=9880.0 The response you got from reiserfsck is identical to one where the disk is dead, or no longer responding (or a cable has become disconnected). It is not necessarily a bad superblock. Second... (and I'm guessing /dev/sdd is the disk that is not mounting... please verify) does /dev/sdd respond at all (check to see if it is not disconnected or dead, or locked up)? hdparm -i /dev/sdd fdisk -lu /dev/sdd If it does respond, try reiserfsck --check /dev/sdd1 (note the 1 on the end of the device name denoting the FIRST partition) third... you might want to disable your add-ons for now, they are only complicating things. They have been known to keep disks from mounting if they attempt to use the disks before they are initialized and ready by unRAID.
February 20, 201313 yr Author version: 5.0-rc8a You are correct in that sdd (sdc now after reboot) is the drive that is showing unformatted hdparm output Model=WDC WD20EADS-00W4B0, FwRev=01.00A01, SerialNo=WD-WCAVY5827694 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50 BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=3907029168 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 AdvancedPM=no WriteCache=enabled Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7 * signifies the current active mode fdisk output Disk /dev/sdc: 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/sdc1 64 3907029167 1953514552 83 Linux Partition 1 does not end on cylinder boundary. reiserfsck output 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/sdc1. Failed to open the filesystem. If the partition table has not been changed, and the partition is valid and it really contains a reiserfs partition, then the superblock is corrupted and you need to run this utility with --rebuild-sb. Syslog is attached Also Im not sure if its related but it almost seems like my parity is incorrect. If I understand what I read I should be able to access files contained on this disk through the parity calculation should I not? I am not seeing any files that were on this disk. If this is the case I am not overly pissed as I backed up 80% of the data before I did the disk rebuild onto a HDD outside the array and the data I didnt can be replaced fairly easy. Just thought I would save you the trouble if this is the case. Syslog.txt
February 20, 201313 yr OK... Your fsck output seems to show the partition starts on sector 64. Let's see if the reiserfs file system is there as expected. OK, let's try something to see if we can figure out where the file-system actually starts type: dd if=/dev/sdc count=195 | od -c -A d | sed 30q The output should look a lot like this below... Note where the string "R e I s E r 2 F s" appears.... Let's see if yours is at the same address, or one sector further. It should be 512 bytes further than my example. If the string is on a line at address "0097840" like this 0097840 220 \0 002 \0 R e I s E r 2 F s \0 \0 \0 the file system is starting on sector 63. If the string is on a line at address "0098352" like this: 0098352 006 \0 001 \0 R e I s E r 2 F s \0 \0 \0 the file system is starting on sector 64. Output on one of my drives looks like this (it has a file-system starting on sector 63): 195+0 records in 195+0 records out 99840 bytes (100 kB) copied, 0.00169403 s, 58.9 MB/s 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000448 \0 \0 203 \0 \0 \0 ? \0 \0 \0 361 _ 8 : \0 \0 0000464 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000496 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 U 252 0000512 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0097792 376 \v G \a e \a - \0 \a 212 267 001 022 \0 \0 \0 0097808 \0 \0 \0 \0 \0 \0 \0 \0 004 \0 \0 % 254 227 \ 0097824 204 003 \0 \0 036 \0 \0 \0 \0 \0 \0 \0 \0 020 314 003 0097840 220 \0 002 \0 R e I s E r 2 F s \0 \0 \0 0097856 003 \0 \0 \0 005 \0 217 016 002 \0 \0 \0 204 ] \0 \0 0097872 001 \0 \0 \0 353 300 256 263 242 347 N 347 264 362 315 364 0097888 345 V 253 366 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0097904 \0 \0 \0 \0 \a \0 036 \0 255 262 303 M \0 N 355 \0 0097920 \0 \0 \0 \0 I'm trying to discover if the re-constructed file system exists where unRAID should have put it... (starting on sector 64) Joe L.
February 20, 201313 yr Author root@Tower:~# dd if=/dev/sdc count=195 | od -c -A d | sed 30q 195+0 records in 195+0 records out 99840 bytes (100 kB) copied, 0.00167101 s, 59.7 MB/s 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000448 \0 \0 203 \0 \0 \0 @ \0 \0 \0 p 210 340 350 \0 \0 0000464 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000496 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 U 252 0000512 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0098304 \0 \0 \0 \0 024 f ] 026 p N Z 004 \0 \0 \0 \0 0098320 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 024 312 j 006 0098336 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0098368 \0 \0 \0 \0 \a \0 \0 \0 \0 \0 \0 \0 F 021 \0 \0 0098384 \0 \0 \0 \0 221 S 303 342 ; 211 \n F * l 355 345 0098400 205 376 314 _ \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0098416 \0 \0 \0 \0 030 \0 \0 \0 216 317 224 001 \0 \0 \0 \0 0098432 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0098512 N 4 \0 \0 > \0 \0 \n 4 \0 \0 N 3 \0 \0 0098528 331 3 \0 \0 N 3 \0 \0 331 3 \0 \0 f % \0 \0 0098544 364 0 \0 \0 z 034 \0 \0 x " \0 \0 z 034 \0 \0 0098560 x " \0 \0 z 034 \0 \0 x " \0 \0 z 034 \0 \0 * 0099840
February 21, 201313 yr root@Tower:~# dd if=/dev/sdc count=195 | od -c -A d | sed 30q 195+0 records in 195+0 records out 99840 bytes (100 kB) copied, 0.00167101 s, 59.7 MB/s 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000448 \0 \0 203 \0 \0 \0 @ \0 \0 \0 p 210 340 350 \0 \0 0000464 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000496 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 U 252 0000512 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0098304 \0 \0 \0 \0 024 f ] 026 p N Z 004 \0 \0 \0 \0 0098320 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 024 312 j 006 0098336 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0098368 \0 \0 \0 \0 \a \0 \0 \0 \0 \0 \0 \0 F 021 \0 \0 0098384 \0 \0 \0 \0 221 S 303 342 ; 211 \n F * l 355 345 0098400 205 376 314 _ \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0098416 \0 \0 \0 \0 030 \0 \0 \0 216 317 224 001 \0 \0 \0 \0 0098432 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0098512 N 4 \0 \0 > \0 \0 \n 4 \0 \0 N 3 \0 \0 0098528 331 3 \0 \0 N 3 \0 \0 331 3 \0 \0 f % \0 \0 0098544 364 0 \0 \0 z 034 \0 \0 x " \0 \0 z 034 \0 \0 0098560 x " \0 \0 z 034 \0 \0 x " \0 \0 z 034 \0 \0 * 0099840 Looks like you need to rebuild the superblock, just as the reiserfsck command suggested. The "ReIser2Fs" string is not there as expected. Joe L.
February 21, 201313 yr Author Just making sure this is what I need to do once the rebuild-sb is run. 1. The version of reiserfs is 3.6.x. 2. Block size is 4096 (default) 3. “No journal device was specified. (If journal is not available, re-run with --no-journal-available option specified)” Is journal default?” (Answer Y) This one I am not sure about 4. “Do you use resizer?” (Answer N) 5. It tells you that a new uuid has been generated. 6. “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?” Answer Y This one I am not sure about 7. The following info is displayed: Reiserfs super block in block 16 on 0x901 of format 3.6 with standard journal Count of blocks on the device: 73264320 Number of bitmaps: 2236 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: <my UUID removed> LABEL: Set flags in SB: Is this ok ? (y/n)[n]: 8. Answer “Y”. 9. With amazing speed the program does its thing and ends
February 21, 201313 yr You did want to rebuild the journal header... I think your response was correct. Now, assuming you ran the rebiuld-sb on either (the preferred ... assuming we are still talking about disk2) /dev/md2 or the first partition of the physical disk (less preferred, since parity will be out of sync and need to be checked afterwards) /dev/sdc1 (note the trailing "1" on the device name denoting the first partition) Trying this once more should show the reiserfs string where it was expected: dd if=/dev/sdc count=195 | od -c -A d | sed 30q And... you should be able to perform reiserfsck --check /dev/md2 to get the overall file-system status.
February 21, 201313 yr Set flags in SB: Is this ok ? (y/n)[n]: 8. Answer “Y”. You always want to answer in the same "case" as the prompt. If you answered "Y" and it wanted "y", it might have ignored the request and done nothing (very quickly) You can easily find out by running the reiserfsck --check once more on the drive. 9. With amazing speed the program does its thing and ends Yes, it is only fixing the very first few blocks of the file-system, so it is very fast.
February 21, 201313 yr Author rebuild completed new reiserfsck --check root@Tower:~# reiserfsck --check /dev/md2 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/md2 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 Thu Feb 21 15:51:27 2013 ########### Replaying journal: Done. Reiserfs journal '/dev/md2' in blocks [18..8211]: 0 transactions replayed 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 The dd shows the same as before root@Tower:~# dd if=/dev/sdc count=195 | od -c -A d | sed 30q 195+0 records in 195+0 records out 99840 bytes (100 kB) copied, 0.00796299 s, 12.5 MB/s 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000448 \0 \0 203 \0 \0 \0 @ \0 \0 \0 p 210 340 350 \0 \0 0000464 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000496 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 U 252 0000512 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0098304 \0 \0 \0 \0 024 f ] 026 p N Z 004 \0 \0 \0 \0 0098320 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 024 312 j 006 0098336 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0098368 \0 \0 \0 \0 \a \0 \0 \0 \0 \0 \0 \0 F 021 \0 \0 0098384 \0 \0 \0 \0 221 S 303 342 ; 211 \n F * l 355 345 0098400 205 376 314 _ \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0098416 \0 \0 \0 \0 030 \0 \0 \0 216 317 224 001 \0 \0 \0 \0 0098432 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0098512 N 4 \0 \0 > \0 \0 \n 4 \0 \0 N 3 \0 \0 0098528 331 3 \0 \0 N 3 \0 \0 331 3 \0 \0 f % \0 \0 0098544 364 0 \0 \0 z 034 \0 \0 x " \0 \0 z 034 \0 \0 0098560 x " \0 \0 z 034 \0 \0 x " \0 \0 z 034 \0 \0 *
February 21, 201313 yr Author Would this be the next step based on this topic here: http://lime-technology.com/forum/index.php?topic=1483 I then needed to get reiserfsck to search the entire drive to try and rebuild the directory structure. I ran the program “reiserfsck –scan-whole-partition –rebuild-tree /dev/md2”. (UPDATE 8/8/11: If you ever run on on an OS level device rather than an unRAID device, make sure to use the first partition - ie., “reiserfsck /dev/sdc1", and not the disk level device.)
February 22, 201313 yr rebuild completed new reiserfsck --check root@Tower:~# reiserfsck --check /dev/md2 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/md2 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 Thu Feb 21 15:51:27 2013 ########### Replaying journal: Done. Reiserfs journal '/dev/md2' in blocks [18..8211]: 0 transactions replayed 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 The dd shows the same as before root@Tower:~# dd if=/dev/sdc count=195 | od -c -A d | sed 30q 195+0 records in 195+0 records out 99840 bytes (100 kB) copied, 0.00796299 s, 12.5 MB/s 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000448 \0 \0 203 \0 \0 \0 @ \0 \0 \0 p 210 340 350 \0 \0 0000464 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000496 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 U 252 0000512 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0098304 \0 \0 \0 \0 024 f ] 026 p N Z 004 \0 \0 \0 \0 0098320 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 024 312 j 006 0098336 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0098368 \0 \0 \0 \0 \a \0 \0 \0 \0 \0 \0 \0 F 021 \0 \0 0098384 \0 \0 \0 \0 221 S 303 342 ; 211 \n F * l 355 345 0098400 205 376 314 _ \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0098416 \0 \0 \0 \0 030 \0 \0 \0 216 317 224 001 \0 \0 \0 \0 0098432 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0098512 N 4 \0 \0 > \0 \0 \n 4 \0 \0 N 3 \0 \0 0098528 331 3 \0 \0 N 3 \0 \0 331 3 \0 \0 f % \0 \0 0098544 364 0 \0 \0 z 034 \0 \0 x " \0 \0 z 034 \0 \0 0098560 x " \0 \0 z 034 \0 \0 x " \0 \0 z 034 \0 \0 * Then I'm guessing you did not respond with the exact same response the --rebuild-tree expected, so it did nothing. Joe L.
February 22, 201313 yr I just tried a --rebuild-tree on an old disk I happen to have in one of my servers. It is an 8Gig drive. (yes, 8 gig) I use it for tests with pre-clearing, etc, since it is so small it takes very little time to perform any given test. The captured output is below. It needed an explicit "Yes" to continue and actually run. If I responded with "y" or"Y" it did absolutely nothing and returned a prompt instantly. If it runs, it prints a synopsis of what it finds. I suspect in your prior use of --rebuild-sb , you did not ask it to actually write out the repaired superblock. root@Tower3:/boot# reiserfsck --rebuild-tree /dev/hdj1 reiserfsck 3.6.21 (2009 www.namesys.com) ************************************************************* ** Do not run the program with --rebuild-tree unless ** ** something is broken and MAKE A BACKUP before using it. ** ** If you have bad sectors on a drive it is usually a bad ** ** idea to continue using it. Then you probably should get ** ** a working hard drive, copy the file system from the bad ** ** drive to the good one -- dd_rescue is a good tool for ** ** that -- and only then run this program. ** ** 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/hdj1) 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: Done. Reiserfs journal '/dev/hdj1' in blocks [18..8211]: 0 transactions replayed ########### reiserfsck --rebuild-tree started at Thu Feb 21 21:11:34 2013 ########### Pass 0: ####### Pass 0 ####### Loading on-disk bitmap .. ok, 8274 blocks marked used Skipping 8273 blocks (super block, journal, bitmaps) 1 blocks will be read 0%....20%....40%....60%....80%....100% left 0, 0 /sec 2 directory entries were hashed with "r5" hash. "r5" hash is selected Flushing..finished Read blocks (but not data blocks) 1 Leaves among those 1 Objectids found 4 Pass 1 (will try to insert 1 leaves): ####### Pass 1 ####### Looking for allocable blocks .. finished 0%....20%....40%....60%....80%....100% left 0, 0 /sec Flushing..finished 1 leaves read 1 inserted ####### Pass 2 ####### Flushing..finished Pass 3 (semantic): ####### Pass 3 ######### Flushing..finished Files found: 0 Directories found: 3 Pass 3a (looking for lost dir/files): ####### Pass 3a (lost+found pass) ######### Looking for lost directories: Flushing..finishede 0, 0 /sec Pass 4 - finished done 0, 0 /sec Flushing..finished Syncing..finished ########### reiserfsck finished at Thu Feb 21 21:11:35 2013 ########### I suspect you never actually ran the command...
February 22, 201313 yr Author Correct, I just ran the rebuild-sb command not the rebuild-tree command. I didnt want to run something I wasnt suppose to so I was checking to make sure. I will kick off the rebuild-tree command and report back when its done.
February 22, 201313 yr Correct, I just ran the rebuild-sb command not the rebuild-tree command. I didnt want to run something I wasnt suppose to so I was checking to make sure. I will kick off the rebuild-tree command and report back when its done. I think it may fail if the superblock was not first fixed. Typing reiserfsck --check /dev/md2 should tell you how to proceed. If the --rebuild-tree is needed, it should tell you. (and I think it did if I'm not mistaken) Bad root block 0. (--rebuild-tree did not complete)
February 22, 201313 yr Author So went from bad to worse. I had a screen capture set up and the rebuild tree finished saying it found 700 or so files and put them in lost+found. However at some point the array rebooted(its behind a UPS). Now my parity as well as disk2 are showing as no device available. Attached new syslog Edit: Did a complete shutdown waited a bit and booted back up. Disks are now showing. As a 23 y/o this thing is giving me more stress than midterms right now syslog-2013-02-22.txt
February 22, 201313 yr Author Ok after running chmod to allow me to view the files I have the directory structure back! Just a quick glance and it seems like 90% of my files are intact and even named correctly! Joe thanks for all the help and patience. If you ever come up to SD you have a beer waiting for you.
Archived
This topic is now archived and is closed to further replies.