Forgot to say, if the rebuilt is goes well, i.e., there are no issues from any of other disks, you can do a new parity sync after it finishes, this way the array would be protected while you run reiserfsck on the new disk1.

 

Probably sounds pretty confusing by now, doesn't it?

 

uhh.....yes, haha

Forgot to say, if the rebuilt is goes well, i.e., there are no issues from any of other disks, you can do a new parity sync after it finishes, this way the array would be protected while you run reiserfsck on the new disk1.

Why didn't we think of that!? To me that does seem the simplest, and the best of both worlds.

Alright, I gotta put it on hold for a bit anyway.  Knew I had extra slots in the case, but forgot to check my sata ports and I need some more.

 

So what's the consensus route here....is grabbing a 2nd new drive going to be the best route?  I'd rather not spend the money if I don't have to, but it it's the best route I will

You don't absolutely need a 2nd new disk => but it would give you both a disk to do a rebuild on AND a new empty disk in the array to copy any recovered data to.  How useful this is depends on how much free space is on the other disks in the array.

 

In addition, since you have another disk that's rather "iffy" (disk 3), that would give you another new disk to use to replace it once you get the initial problem sorted.

 

Before you do ANYTHING, however, reseat your cables on the problem disk and see if that makes a difference.  A loose SATA cable can very easily cause the "unmountable" issue you're seeing -- and it'd be a shame to ultimately discover that you'd simply had a loose cable.  Doesn't seem likely that's the issue -- but it's definitely worth checking.

 

... forgot to check my sata ports and I need some more.

 

Do you have ANY spare ports -- or are you maxed out with the 6 drives you have?

 

Also, do you have a Windows PC with a spare SATA port on it?

 

doh, forgot to add to my last post that I pulled the sata cable and relaced it with a completely different one and pulled the power and reseated it.  Still came up unmountable.

 

Is there a "go to" pci card that has worked well for adding ports?

... forgot to check my sata ports and I need some more.

 

Do you have ANY spare ports -- or are you maxed out with the 6 drives you have?

 

Also, do you have a Windows PC with a spare SATA port on it?

 

Yeah, my board is maxed out at 6 ports.  Need to get a pci card to add ports.

 

 

Yes, I have a desktop with free ports

I'd try this:

 

(a)  Download the free Linux Reader on your desktop PC:  https://www.diskinternals.com/linux-reader/

 

(b)  Install Linux Reader

 

©  Shut down your PC.  Connect the "bad" disk from UnRAID to a SATA port on your desktop; then turn it back on.

 

(d)  Run Linux Reader and see if it can see the files on your UnRAID disk.    If so, you can copy them from that disk to another location on your desktop (if you have space).  If you don't have enough space, at least copy those that you really care about (e.g. pictures), just to confirm they're actually readable.

 

Note:  You do NOT want to do ANYTHING that would write to that disk -- but Linux Reader is safe, since it doesn't support writes to that drive.

 

Note:  If you CAN see the files okay; then I'd just leave that disk connected to your desktop;  do a New Config on the UnRAID server with a new disk in place of the old one;  let it do a parity sync; and then just copy the files to your new UnRAID server across your network.

 

Note:  If you CAN see the files okay; then I'd just leave that disk connected to your desktop;  do a New Config on the UnRAID server with a new disk in place of the old one;  let it do a parity sync; and then just copy the files to your new UnRAID server across your network.

If it can be read in Windows that would be the best (and simplest) option. Glad we got some more heads involved.

 

If it can't be read in Windows don't do anything else without getting further advice on the other options.

Awesome, that sounds logical/safe.  I'll work on that later tonight and report back.  Thank you guys so much for the help

Got that linux reader running.  The drive shows up no problem, but when I double click on it a window that says "Reading file tree" pops up and then the program more or less freezes

Finally got it to open something up on that drive.  This is the screen that popped up

 

 

Got that linux reader running.  The drive shows up no problem, but when I double click on it a window that says "Reading file tree" pops up and then the program more or less freezes

 

That confirms that the drive is bad => it's actually not surprising, but good to confirm before you attempt recovery using the Linux tools on the UnRAID server.

 

Just to be certain -- you ARE connecting the drive via an internal SATA port, and not via a USB bridge device ... right?    As long as that's the case, there's nothing else to try with the desktop.

 

Got that linux reader running.  The drive shows up no problem, but when I double click on it a window that says "Reading file tree" pops up and then the program more or less freezes

 

That confirms that the drive is bad => it's actually not surprising, but good to confirm before you attempt recovery using the Linux tools on the UnRAID server.

 

Just to be certain -- you ARE connecting the drive via an internal SATA port, and not via a USB bridge device ... right?    As long as that's the case, there's nothing else to try with the desktop.

yes it's connected to an internal sata port.

 

so at this point am I pretty much boned on that drive? 

 

basically my only next step is to add the new drive and let it rebuild whatever it can?

When I said "bad", I should have said either bad or corrupted.

 

 

Since you don't have any extra SATA ports on your UnRAID system, I'd do the following ...

 

=>  Connect JUST the bad drive to that system (disconnect all of the others) and your new drive

 

=>  Boot to UnRAID and do a New Config with only that drive and the new drive (to provide some storage space on a known-good drive)

 

=>  Now run reiserfsck and see if you can reconstruct the data from that drive.  Generally you want to run it with just the -check option first;  then either -fix-fixable  or  -rebuild-tree  depending on what the results of the -check are.

 

[ See http://linuxcommand.org/man_pages/reiserfsck8.html ]

 

There are several folks who are very well versed in this tool on the forum -- I'm not one of them, but I suspect they'll jump in with some advice if you run the -check option and post the results here.

 

If you succeed at recovery some of your data with reiserfsck, copy what you recover to the new drive => and then you can do a New Config with the OTHER drives that were in the system plus the new drive (with the recovered data) and you'll be ready to go ... and still only using the 6 SATA ports you already have.

 

 

If you aren't successful at recovery anything, and want to try a rebuild of the disk from the original disks, note that doing the above hasn't impacted your ability to do this, since none of the other disks will be in the system while you try this.    So you can still do a New Config with "parity is already valid" with the original 6 disks;  and try the rebuild => knowing, of course, that parity actually is NOT valid and a good bit of the rebuilt disk will be erroneous ... but you could still try it and then try the same reiserfsck operations on the rebuilt disk to see if you get any better results (not likely, but certainly possible).    As I've already noted, I don't think this is likely to succeed, but it certainly won't hurt to try it.

 

 

If neither the original disk, 'nor a rebuilt disk (if you try that option) are successful with reiserfsck, then you've simply lost all of the data on that disk => so you should simply do a New Config with the other 5 disks from the original system plus your new disk.

 

ok, I will try that tonight.  Thanks

ran the reiserfsck check and this is the message it came back with:

 

reiserfsck 3.6.24

 

Will read-only check consistency of the filesystem on /dev/md1

Will put log info to 'stdout'

 

The problem has occurred looks like a hardware problem. If you have

bad blocks, we advise you to get a new hard drive, because once you

get one bad block  that the disk  drive internals  cannot hide from

your sight,the chances of getting more are generally said to become

much higher  (precise statistics are unknown to us), and  this disk

drive is probably not expensive enough  for you to you to risk your

time and  data on it.  If you don't want to follow that follow that

advice then  if you have just a few bad blocks,  try writing to the

bad blocks  and see if the drive remaps  the bad blocks (that means

it takes a block  it has  in reserve  and allocates  it for use for

of that block number).  If it cannot remap the block,  use badblock

option (-B) with  reiserfs utils to handle this block correctly.

 

bread: Cannot read the block (488378637): (Input/output error).

Reiserfsck can't check a disk with bad sectors, you have to remap them or use badclocks to create a list of them for reiserfsck to use (and skip them), this works when there are only a few, disk looks too damaged, but if you want to try first run badblocks:

 

badblocks -s -v -o /boot/badblocks.log /dev/md1

 

When done run:

 

reiserfsck --check -B /boot/badblocks.log /dev/md1

can that be run from within the gui or does it have to be done from a terminal?

You'll need to use the console or SSH into the server.

 

IMO a better option is using DD to make a clone of the disk ignoring all read errors, again if the disk is very damaged there's not a great chance of success but in my experience it works better than badblocks, but for this option you'd need an extra disk, 2TB or larger.

 

If you want to try it connect both on the same server, and with the array stopped:

 

dd if=/dev/sdX of=/dev/sdY conv=noerror,sync status=progress

 

Replace X with source and Y with destination.

 

This will take a long time, in part because of the small block size used to minimize the data lost to errors, when done you'll need to run reiserfsck on the destination disk.

 

PS: if the destination disk is larger than 2TB don't assign it to an array slot or unRAID will resize and change the partition to GPT, use the cache slot or the unassigned devices plugin to try to mount it after reiserfsck.