I just upgraded from v5.0.5 to v6 according to the wiki, and installed a new HDD at the same time. When I assigned disks and started the array, webGUI showed my new HDD and one of my previous data disks were UNMOUNTABLE. I didn't notice this right away, and of course UNRAID started a parity check when I brought the array online. I canceled the parity check when I noticed it found a lot of errors and was making a lot of writes to the parity drive.

 

The existing data drive was always connected to a PCI SATA controller, and that's also where I connected the new drive (only those two drives on that card). I've since removed the new HDD, replaced cables, tried a new PCI SATA controller, run NEW CONFIG, but that old data drive still shows unmountable.

 

Reiserfsck fails and recommends rebuild-sb.

 

I tried reloading UNRAID on my flash drive and carrying over a previous disk.cfg, removed the unmountable drive from the array, and started the array hoping the contents would be emulated, but there were big gaps in my user shares. I assume this is a result of the parity corrections when the drive showed unmountable in the first place.

 

Is my data from this HDD gone? Or can I preclear and/or format this disk and rebuild from parity? Maybe just replace the drive and rebuild?

tower-diagnostics-20160119-2142.zip

If you’re sure disk1 was really old disk1 and not old parity, there’s one thing you can try with nothing to lose.

 

-Go to tools and do a new config

-Reassign all disks (including disk1)

-Check “Parity is already valid” and start array

-Stop array and unassign disk1

-Start array in maintenance mode and run reiserfsck on /dev/md1

 

https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Drives_formatted_with_ReiserFS_using_unRAID_v5_or_later

 

This will be done on the emulated disk, so if it doesn’t work you can still try to recover from the actual disk, if it does you can then rebuild to same or new disk.

 

I just upgraded from v5.0.5 to v6 according to the wiki, and installed a new HDD at the same time... and of course UNRAID started a parity check when I brought the array online.

johnnie.black gives good advice. Just thought I would comment on these bits.

 

You should never change more than one thing at a time. Upgrade first then after it's working add new disk, or add new disk then after it's working upgrade.

 

Did you start from scratch so you had to assign all your drives? Of course you would get a parity build when you start from scratch.

-Go to tools and do a new config

-Reassign all disks (including disk1)

-Check “Parity is already valid” and start array

-Stop array and unassign disk1

-Start array in maintenance mode and run reiserfsck on /dev/md1

 

https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Drives_formatted_with_ReiserFS_using_unRAID_v5_or_later

 

This will be done on the emulated disk, so if it doesn’t work you can still try to recover from the actual disk, if it does you can then rebuild to same or new disk.

 

Ran reiserfsck on the emulated disk and failed:

 

root@Tower:~# reiserfsck --check /dev/md1
reiserfsck 3.6.24

Will read-only check consistency of the filesystem on /dev/md1
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 Wed Jan 20 12:28:22 2016
###########
Replaying journal: Done.
Reiserfs journal '/dev/md1' in blocks [18..8211]: 0 transactions replayed
Checking internal tree..

Bad root block 0. (--rebuild-tree did not complete)

Aborted

 

-Check “Parity is already valid” and start array

 

I went back and noticed this output in syslog when I first started the array:

 

Jan 20 12:24:55 Tower emhttp: shcmd (272): mkdir -p /mnt/disk1
Jan 20 12:24:55 Tower emhttp: shcmd (273): set -o pipefail ; mount -t auto -o noatime,nodiratime /dev/md1 /mnt/disk1 |& logger
Jan 20 12:24:55 Tower kernel: REISERFS (device md1): found reiserfs format "3.6" with standard journal
Jan 20 12:24:55 Tower kernel: REISERFS (device md1): using ordered data mode
Jan 20 12:24:55 Tower kernel: reiserfs: using flush barriers
Jan 20 12:24:55 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
Jan 20 12:24:55 Tower kernel: REISERFS (device md1): checking transaction log (md1)
Jan 20 12:24:55 Tower kernel: REISERFS warning: reiserfs-5090 is_tree_node: node level 0 does not match to the expected one -1
Jan 20 12:24:55 Tower kernel: REISERFS error (device md1): vs-5150 search_by_key: invalid format found in block 0. Fsck?
Jan 20 12:24:55 Tower kernel: REISERFS (device md1): Remounting filesystem read-only
Jan 20 12:24:55 Tower kernel: REISERFS error (device md1): vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [1 2 0x0 SD]
Jan 20 12:24:55 Tower kernel: REISERFS warning: reiserfs-5090 is_tree_node: node level 0 does not match to the expected one -1
Jan 20 12:24:55 Tower kernel: REISERFS error (device md1): vs-5150 search_by_key: invalid format found in block 0. Fsck?
Jan 20 12:24:55 Tower logger: mount: wrong fs type, bad option, bad superblock on /dev/md1,
Jan 20 12:24:55 Tower logger:        missing codepage or helper program, or other error
Jan 20 12:24:55 Tower logger:        In some cases useful info is found in syslog - try
Jan 20 12:24:55 Tower logger:        dmesg | tail  or so
Jan 20 12:24:55 Tower logger: 
Jan 20 12:24:55 Tower emhttp: shcmd: shcmd (273): exit status: 32
Jan 20 12:24:55 Tower emhttp: mount error: No file system (32)
Jan 20 12:24:55 Tower emhttp: shcmd (274): rmdir /mnt/disk1

 

Is there any hope in reverting my flash drive back to my previous v5.0.5 config (all pre-upgrade files) and then replacing the disk?

Ran reiserfsck on the emulated disk and failed:

 

Maybe someone more familiar with reiserfsck can chime in if there’s a way to make it work, I suspect it will depend on how much of your original parity was overwritten.

 

Is there any hope in reverting my flash drive back to my previous v5.0.5 config (all pre-upgrade files) and then replacing the disk?

 

I assume you didn’t back up your original v5 flash, you can revert to v5 and do a new config, reassign all disks and trust parity, same procedure you did for v6, if you do use v5.0.6 as I’m sure the trust parity option works correctly on that release, then you can see if disk1 mounts and if not, unassign it and check the emulated disk, but I would expect same results as v6.

 

If none of these options work your best option will probably be running reiserfsck on the physical disk1, I remind again that you have to be sure disk1 was really your old disk1, if when you upgraded you assigned a data disk as parity none of these options will work.

 

I did backup my flash from v5, so I restored that and ran through the process from there as you suggested, with the same results just as you predicted. I ran reiserfsck on the physical drive as well, same result.

 

I'm 100% certain I assigned all disks correctly when I initially started v6; I was staring at my pre-upgrade screenshot.

 

I'm now attempting reiserfsck --rebuild-tree on the emulated disk and will post results hopefully within 24 hours.

 

If that also fails, I'll count it as a hard lesson learned and preclear the drive and start over.

Can’t imagine what happened to leave you with such a badly corrupted disk, reiserfsck has been known to recover data from pretty bad situations, so good luck.

Just saw my rebuild-tree finished with huge success. I specified -S in the command to scan the entire partition and that seems to have done the trick. I'll post full results tonight after work, but my quick check through TeamViewer showed successful recovery of many of the files I was missing.

 

UPDATE: I've been able to recover all visible files from the newly rebuilt emulated Disk1. I've read about the 'lost+found' folder this process generates, and I don't think I'm going to waste my time sifting through these 20k+ nameless files without extensions.

 

Once my recovered files finish being copied, I'll be formatting this drive and starting again.

 

Thanks for all the help and advice johnnie.black and trurl!