Disk Issues - Remote Help

[Defylimits]

Morning All,

So I've got a bit of a problem and wondering if anyone can help (although I suspect I already know the answer!).

Have an array of 6 disks and recently had one have an issue and has been disabled (contents emulated), see the attached Smart information. Not sure how to read that if anyone could give me some pointers of what is wrong with it. Also attached the disk logs which make it look like its a sata link issue??

So the disk didn't have much on it and I've made sure that this has now been 'moved' off the disk onto others in the array, although there's no files on the disk in the explorer, the summary page says 4.02GB is used?

Now I need to remove the disk to make sure that the rest of the arrays contents is protected. Here's the kicker, I'm not in the same country as the server, it currently lives at my families house (whilst I wait for my house purchase to go through but thats a different problem!), and my family have gone on extended holiday. I access the server by remoting into a VM run on the server, note this VM runs on a seperate disk through unassigned devices.

As you can see I can't take down the array as I wont be able to access it to remove the disk and restart it, is there any way to remove the disk from the array without stopping it, or just blanking it and putting it back into the array to protect the parity? Or anyway to keep the VM up whilst the array is stopped. Running unraid version 6.6.7, I think I know the answer but thought I'd ask as its going to be a couple of weeks before I can get to/get someone to the server physically.

Cheers

Diskloginformation.txt WDC_WD40EFRX-68N32N0_WD-WCC7K0NNFX24-20190430-0720.txt

[witalit]

SMART looks OK to me.. What do others think? 

 

Ah yes common issue 

Quote

 irq_stat 0x08000000, interface fatal error

For this error appearing in disk logs is re-plug sata seems to be suggested fix on interwebs.

 

Unfortunately I don't know what else to suggest. 

Edited April 30, 2019 by witalit

[JorgeB]

1 minute ago, witalit said:

What do others think? 

Agree, looks more like a connection issue, but full diags would be preferable.

 

5 minutes ago, Defylimits said:

is there any way to remove the disk from the array without stopping it,

No, you can't remove it or rebuild it without stopping the array, most you can do is to exclude it from all the shares so that at least for now nothing gets written to the emulated disk, which will use all other disks, but the array will remain unprotected.

[Defylimits]

Thanks for the quick responses!

2 minutes ago, johnnie.black said:

No, you can't remove it or rebuild it without stopping the array, most you can do is to exclude it from all the shares so that at least for now nothing gets written to the emulated disk, which will use all other disks, but the array will remain unprotected.

Already done! I'm assuming if a disk does now go *pop* then I'll lose the data on that disk, but will be able to recover the data from the other disks.

[itimpi]

1 hour ago, Defylimits said:

Thanks for the quick responses!

Already done! I'm assuming if a disk does now go *pop* then I'll lose the data on that disk, but will be able to recover the data from the other disks.

With Unraid if a disk fails then at the worst case you only lose the data on the failed disk.   In your case with an already failed disk you would not be able to recover another failed disk using standard methods.

 

A disk that has no empty files still has a file system on it so is still part of parity.   For the disk not to be affecting parity it has to be all zeroes.  What you MAY be able to do is to zero the emulated failed disk so that it is no longer affecting parity.  You could use the technique described here to do this but stop after step 4.    This means that if another disk fails you should have a recovery path to getting its contents back as at the logical level only one disk has now failed (since the zeroed disk is not affecting parity) although you will have to be able to stop the array to do any such recovery.