Disk disabled ooppss

[Ineedcoffee]

Hey everyone. Maid a stupid mistake. The array was running and I ejected one of my drives thinking it was my empty slot for some new hard disks I'm adding.  Nothing was reading or writing to the disc.

 

I just clicked it back in shut down/restarted the array.

 

Drive shows disabled.. What do I have to do to make sure I didn't damage anything and get it off disabled and back to healthy status.

[trurl]

You have to rebuild it.

 

Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

[blackbox]

bump

[blackbox]

11 hours ago, trurl said:

You have to rebuild it.

 

Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

So how would you go about rebuilding this.

 

As I was looking I found the new config tool.  Would that work in this instance?

[trurl]

12 hours ago, trurl said:

Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread

 

[blackbox]

7 minutes ago, trurl said:

 

Sorry Trurl.  Here it is

tower-diagnostics-20210803-2134.zip

[blackbox]

36 minutes ago, trurl said:

 

Can you give me some insight into what your looking at? I am interested to learn.

[trurl]

Sorry, those diagnostics are without the array started, so can't see if disks mount. Start array and post new diagnostics.

[blackbox]

1 hour ago, trurl said:

Sorry, those diagnostics are without the array started, so can't see if disks mount. Start array and post new diagnostics.

Yup, Sorry, I didn't know the logs were different. Here is with the array running.

 

Disk 1 was the drive I ejected on accident. I was trying to get the trays out to attach disk 10 and 11 which are the newest drives. 10 & 11 just finished the preclear processes.

tower-diagnostics-20210803-2348.zip

Edited August 4, 2021 by blackbox

[trurl]

10 hours ago, blackbox said:

10 & 11 just finished the preclear processes.

Looks like these have already been added to the array and formatted.

 

Unrelated, but you shouldn't be ignoring this:

Aug  3 07:55:01 Tower root: Fix Common Problems: Error: Same share (media) exists in a different case ** Ignored
Aug  3 07:55:01 Tower root: Fix Common Problems: Error: Same share (Media) exists in a different case ** Ignored

Probably you accidentally created one of these shares by using the wrong upper/lower case in a docker host path or some other path specification.

 

You should consolidate these so they are all in the same share with the same upper/lower case and fix things so specified paths use the correct case.

 

Linux is case-sensitive, so it is important to get case correct when specifying paths on your fileserver. These are different shares as far as Linux is concerned. But SMB isn't case-sensitive, so you will only be able to see one of these shares on the network, which might make you think files are missing.

 

[trurl]

Did you reboot after the ooppss? I didn't notice it in syslog.

 

SMART for disk1 looks OK. Emulated disk1 is mounted. You can rebuild the disk to itself:

 

https://wiki.unraid.net/Manual/Storage_Management#Rebuilding_a_drive_onto_itself

[trurl]

12 hours ago, blackbox said:

Can you give me some insight into what your looking at? I am interested to learn.

You can open Diagnostics ZIP and examine the files yourself, all but one file is plain text.

 

In system/df.txt, I can see that disk1 is mounted, and in smart/ I can see that disk1 is disabled, and its important SMART attributes look OK, so

3 minutes ago, trurl said:

SMART for disk1 looks OK. Emulated disk1 is mounted.

 

Unraid disables a disk when a write to it fails. After a disk is disabled it won't be used again, instead it is emulated by reading all other disks. The failed write, and any subsequent writes to the disk, are emulated by updating parity, so those writes can be recovered by rebuilding.

 

It is also possible that a failed read will cause Unraid to get the emulated data from all the other disks, then try to write it back to the disk. If that write fails the disk is disabled. Since you said nothing was writing to the disk (including dockers?) that may be what happened in your case.

On 8/3/2021 at 8:45 AM, Ineedcoffee said:

Nothing was reading or writing to the disc.

 

I just clicked it back in shut down/restarted the array.

When you plugged the disk back in it would have connected as a different device so when Unraid tried to sync the filesystems to prepare for shutdown, it would not have found the disk and that is probably when it became disabled.

 

Maybe the disk isn't really out-of-sync (much), so it would be possible to New Config - Trust Parity, and so avoid the rebuild, but you would want to do a parity check after just to make sure, and if there were sync errors, they would have to be corrected.

 

So the simplest thing to do is just rebuild. The safest thing would be to rebuild to another disk so the original disk could be a failsafe in case there was a problem during rebuild.

 

But if you are careful (always double check connections when mucking about), and diligent (setup Notifications to alert you by email or other agent as soon as a problem is detected), should be little risk to rebuilding.

[Ineedcoffee]

On 8/4/2021 at 10:40 AM, trurl said:

You can open Diagnostics ZIP and examine the files yourself, all but one file is plain text.

 

In system/df.txt, I can see that disk1 is mounted, and in smart/ I can see that disk1 is disabled, and its important SMART attributes look OK, so

 

Unraid disables a disk when a write to it fails. After a disk is disabled it won't be used again, instead it is emulated by reading all other disks. The failed write, and any subsequent writes to the disk, are emulated by updating parity, so those writes can be recovered by rebuilding.

 

It is also possible that a failed read will cause Unraid to get the emulated data from all the other disks, then try to write it back to the disk. If that write fails the disk is disabled. Since you said nothing was writing to the disk (including dockers?) that may be what happened in your case.

When you plugged the disk back in it would have connected as a different device so when Unraid tried to sync the filesystems to prepare for shutdown, it would not have found the disk and that is probably when it became disabled.

 

Maybe the disk isn't really out-of-sync (much), so it would be possible to New Config - Trust Parity, and so avoid the rebuild, but you would want to do a parity check after just to make sure, and if there were sync errors, they would have to be corrected.

 

So the simplest thing to do is just rebuild. The safest thing would be to rebuild to another disk so the original disk could be a failsafe in case there was a problem during rebuild.

 

But if you are careful (always double check connections when mucking about), and diligent (setup Notifications to alert you by email or other agent as soon as a problem is detected), should be little risk to rebuilding.

Trurl, I really appreciate all the help. In the end I just did the disk rebuild to avoid any potential problems. Took a little over 24hours but everything is back up and running again. Thank you.

[blackbox]

On 8/4/2021 at 10:24 AM, trurl said:

Did you reboot after the ooppss? I didn't notice it in syslog.

 

SMART for disk1 looks OK. Emulated disk1 is mounted. You can rebuild the disk to itself:

 

https://wiki.unraid.net/Manual/Storage_Management#Rebuilding_a_drive_onto_itself

So on a different issue but kind of the same. I added those two disks 10 and 11.  I purchased those to do a shinobi docker setup. I had added those disks to the array but in the videos I see spaceinvador uses the unassigned drives plugin. GREAT!!!!! I didn't know that plugin existed and it would make since to me why you would set it up that way because you don't need a parity of the all the recordings all the time.

 

So now how do I remove two disks from the array? I assume I would remove the 2 disks and the parity and just rebuild the parity again off of the 3 disks and leave those two unassigned?

 

Is there a special way or order I should do this in?

Edited August 7, 2021 by blackbox

[trurl]

Why are 2 different users posting to this thread, do you have more than one account on the forum?

 

[blackbox]

11 minutes ago, trurl said:

Why are 2 different users posting to this thread, do you have more than one account on the forum?

 

Sorry. Yea they are both me. I didn't have access to my password manager/email and I made Ineedcoffee for my phone to give a quick response. This is my main account.

Edited August 7, 2021 by blackbox

[trurl]

It is very confusing, and you don't want to confuse people who are trying to help you prevent data loss. We deal with a lot of users and a lot of posts and a lot of problems, anything you do to make that more complicated is likely to result in even more problems.

 

Can we get rid of that ineedcoffee account?

[blackbox]

3 hours ago, trurl said:

It is very confusing, and you don't want to confuse people who are trying to help you prevent data loss. We deal with a lot of users and a lot of posts and a lot of problems, anything you do to make that more complicated is likely to result in even more problems.

 

Can we get rid of that ineedcoffee account?

Yes you can and I apologize, that's was not my intention.

Edited August 7, 2021 by blackbox

[trurl]

12 hours ago, blackbox said:

So on a different issue but kind of the same. I added those two disks 10 and 11.  I purchased those to do a shinobi docker setup. I had added those disks to the array but in the videos I see spaceinvador uses the unassigned drives plugin. GREAT!!!!! I didn't know that plugin existed and it would make since to me why you would set it up that way because you don't need a parity of the all the recordings all the time.

 

So now how do I remove two disks from the array? I assume I would remove the 2 disks and the parity and just rebuild the parity again off of the 3 disks and leave those two unassigned?

 

Is there a special way or order I should do this in?

In addition to Unassigned Devices, v6.9+ allows for multiple pools, so you can create another pool for that purpose and let Unraid manage it instead of using Unassigned Devices plugin.

 

I have a pool named "cache" for caching User Shares, and a pool named "fast" for dockers and VMs.

 

To remove disks from the array, go to Tools - New Config, Preserve All, unassign the disks you want to remove from the array, and start the array to begin parity rebuild. Parity must be rebuilt so those disks are not included.

 

 

[blackbox]

5 hours ago, trurl said:

In addition to Unassigned Devices, v6.9+ allows for multiple pools, so you can create another pool for that purpose and let Unraid manage it instead of using Unassigned Devices plugin.

 

I have a pool named "cache" for caching User Shares, and a pool named "fast" for dockers and VMs.

 

To remove disks from the array, go to Tools - New Config, Preserve All, unassign the disks you want to remove from the array, and start the array to begin parity rebuild. Parity must be rebuilt so those disks are not included.

 

 

For the pools. Whats the additional benefit for letting unraid have management of the drives instead of keeping them unassigned? My perception of pools were just for fast data transfer to be stored on the disk with mover later on. Which works great. Will pools for OK with standard disks not SSD?

[itimpi]

6 hours ago, blackbox said:

For the pools. Whats the additional benefit for letting unraid have management of the drives instead of keeping them unassigned? My perception of pools were just for fast data transfer to be stored on the disk with mover later on. Which works great. Will pools for OK with standard disks not SSD?

Pools will work fine with standard drives.

 

One benefit of using Pools over Unassigned Devices is that pools can participate in User Shares whereas Unassigned Devices cannot.    I personally now only use Unassigned Devices for drives I consider as removable. 

[ChatNoir]

Also, pools can have RAID redundancy where UD drives cannot.

[blackbox]

On 8/8/2021 at 8:34 AM, itimpi said:

Pools will work fine with standard drives.

 

One benefit of using Pools over Unassigned Devices is that pools can participate in User Shares whereas Unassigned Devices cannot.    I personally now only use Unassigned Devices for drives I consider as removable. 

 

On 8/8/2021 at 9:07 AM, ChatNoir said:

Also, pools can have RAID redundancy where UD drives cannot.

I'm convinced, Just created a my second pool instead of using the unassigned drives.