Drive Failure?

[RParkerMU]

I'm looking for some guidance regarding one of my drives. When listed as part of the array the drive has a red X, and shows device is disabled contents emulated; however the drive is also listed also having about 560 gigs of data on it. I ran a smart test which this drive passed, and I have a recent parity check. The parity check was running again when I capture the diagnostics, but I have one from last week.

 

If the drive is determined to be bad, I have enough capacity to pull it without replacing.

unraid-diagnostics-20180225-1047.zip

[JorgeB]

Disk has a lot of reported UNC, IMO it should be replaced, or removed if you don't need the space, but you'll need to move all data from the emulated disk to other disks first.

[sevenz]

I have exactly the same problem with OP, happened a few days ago. Not sure if I should create a new post or post it here. What is UNC, and where do I look for it in the diagnostic zip file?

 

Anyway I don't mean to hijack the thread, somehow the problem timing is the same with OP. I`ll open a new thread if this is not appropriate.

 

I uploaded the diagnostics file in the attachment.

mynas-diagnostics-20180223-1932.zip

[trurl]

10 minutes ago, sevenz said:

I should create a new post

^this

[sevenz]

Alright

[RParkerMU]

@johnnie.black Is moving the data as simple as copying from disk2 (failed disk) to the correct spot on user0?

[Delarius]

I'd be very careful about moving in that way. You really have a few options - rebuild the disk in the usual way (the disk is 'emulated') and thus parity can and will rebuild to a new disk.

On the other hand, when I've had a failed disk I did copy one disk to another (note disk to disk NOT disk to user share) and then added the drive back.

Just wanted to get this in quickly - because you absolutely risk data loss if you do a disk to user share copy.

Note that user0 almost always refers to a cache drive. If you can you'd be better off moving the data to one of the /mnt/disk# mount points.

[trurl]

5 minutes ago, Delarius said:

Note that user0 almost always refers to a cache drive.

user0 never refers to the cache drive. It is the contents of the user shares except for the contents of cache.

 

Other than that, he is correct. You must not move from disk to user share or from user share to disk. Only move from disk to disk.

 

But, do you really want to remove the drive? Or would it make more sense to rebuild it? If you remove a disk from the array you will have to get all the data off of it (or the emulated disk in this case), set a New Config, and resync parity. And until you have resynced parity, you would be running without protection, including all that shuffling of data.

 

The normal remedy in these cases is to rebuild to a new disk, and that is exactly what unRAID is designed to do.

[RParkerMU]

I am considering just removing the drive since I have the capacity and I'm trying to be frugal. Would it really be a bad practice for me to move the data off this disk and remove it? Can the array be running while the resync parity is running?

[trurl]

Another possibility is to copy from the emulated disk to another system or to an Unassigned Device. This way you would only read from the emulated disk instead of writing to the unprotected array. Then after you New Config without the disk and resync parity, you could copy the data back to the protected array.

 

35 minutes ago, RParkerMU said:

Can the array be running while the resync parity is running?

The array must be running to resync parity. Any access of the array will of course slow down the parity sync.