So I have a disk that is device disabled/ emulatedcontents enabled. I am actually not really interested in troubleshooting this disk, because it is a very small (compared to the others) drive that I bought back in 2017. I have been meaning to replace it and another of the same kind for some time, because they are so old and small. So with that being said, I am not really sure of the protocol to do this. I have read over https://docs.unraid.net/unraid-os/manual/storage-management/ and obviously the "Replacing failed/disabled disk(s)" is what I would want, but it says that it wont fix any device that is showing as unmountable. I don't think that my drive is showing as unmountable, but I want to be sure. It looks like this (Disk 3):

 

So if it is mountable, just to clarify, is that I power down, replace the old drive with new drive, and then when I start the machine again, will it still show disk 3 the way it is above, but then I basically take the new drive in the unassigned devices pool, assign it to that spot in the array, and then Unraid does its things and imprints the emulated contents onto that drive. If I do that, is parity then maintained? I don't need to rebuild it from scratch? Also, how does this work if I do/don't pre-clear the new drive?

 

Sorry if this is super basic, just want to make sure I'm not going to mess up the array or cause data loss.

Edited May 12, 20251 yr by daydreamingdude

Might be worth getting more clarity on why it was disabled even though you want to replace it.

 

Attach Diagnostics ZIP to your NEXT post in this thread. 

1 minute ago, trurl said:

Might be worth getting more clarity on why it was disabled even though you want to replace it.

 

Attach Diagnostics ZIP to your NEXT post in this thread. 

Attached

tower-diagnostics-20250512-1139.zip

SMART for disk3 looks OK, no self-tests have been run on it. Emulated disk3 is mounted.

 

I don't see any problem with that disk in syslog, which goes back to May 7.  If it was disabled before that, it wouldn't be used anyway.

 

How long has this disk been disabled?

 

Unrelated, your appdata and system shares have files on the array.

 

 

Disk has been disabled since the 8th actually. 

 

So if everything looks okay, then would following the "Replacing failed/disabled disk(s)" guide generally be what I want? I think I would probably replace the SATA cable as well, just to be sure. 

 

And for the appdata and system shares, that seems not great. Is there a safe and easy way to relocate them elsewhere? Would I want to move them to the flash drive? Seems like it might break a lot of the volume path files.

1 minute ago, daydreamingdude said:

And for the appdata and system shares, that seems not great. Is there a safe and easy way to relocate them elsewhere? Would I want to move them to the flash drive? Seems like it might break a lot of the volume path files.

You definitely don't want them on flash. The volume paths would be the least of your troubles if you had something constantly writing to flash. You generally should avoid writing anything to the boot flash drive.

 

The Unraid OS doesn't run from the flash drive. The OS is contained in archives on flash. These archives are unpacked fresh at each boot, into RAM, and the OS runs completely in RAM. Think of it as firmware. These archives are not changed in any way as the OS is used, so each boot is a fresh install. Only updates to the OS modify these archives. Settings from the webUI (your configuration) are also stored on flash so they can be reapplied at boot. You must always have a current backup of flash so you will be able to recover your configuration if necessary.

 

Continued...

Pools are part of user shares just like the array. The user shares are simply the combined top level folders on array and pools. Assuming you have your mappings and other paths specifying user shares and not specific disks or pools, they will work fine whichever disk or pool the files are on.

 

Best if the "default shares"

 

https://docs.unraid.net/unraid-os/manual/shares/user-shares/#default-shares

 

have all files on cache or other pool with nothing on the array, so Docker/VM performance will not be affected by slower array reads and especially writes, and so array disks can spin down since these files are always open.

 

Continued...

Nothing can move open files, so you have to go to Settings and Disable both Docker and VM Manager before these shares can be moved.

 

We can work on all that after you finish the rebuild of disk3.

Thank you for breaking that down. I agree that should be secondary after the rebuild. It may take me a second to get to the rebuild. Full time job and all that, so I will bump this topic once I have done that. But for the rebuild, sounds like the "Replacing failed/disabled disk(s)" section is what I want. Once I swap out the new disk in that disk spot, I shouldn't have to rebuild parity, right? And does it matter in terms of speed if I preclear or don't the new disk?

1 minute ago, daydreamingdude said:

I shouldn't have to rebuild parity, right?

Correct. In fact, parity must already be valid, since rebuild depends on parity plus all other disks to provide the data for the rebuild.

 

https://docs.unraid.net/unraid-os/overview/nas/#parity-protected-array

 

4 minutes ago, daydreamingdude said:

And does it matter in terms of speed if I preclear or don't the new disk?

Every bit of the new disk will be written during rebuild, so that is pretty good test of the disk. And you still have the original if something doesn't go as planned with the new disk.

Gotchya. Sounds simple enough then. Thanks for your help and flagging that other issue. I'll reach out once I am ready to tackle that (or if I have any issues with swapping out the disks)