Hi,

 

I just want to get confirmation of a phenomenon I noticed today.  As I am trialing Unraid, I'm practicing assigning and unassigning devices to various functions within the system.  Presently I've assigned 2 parity drives and 3 data drives.  I assigned 2 cache drives as an experiment and removed them after the experiment.  While they were in the system, they assumed drive designations sdg and sdh.  When I removed the cache and physically the drives, the designations sdg and sdh remain on the Dashboard, but now as unassigned devices instead of cache drives.

 

Fine enough.  This brings up my question.  I assume now that these drives count against my licensed limits even though they do not physically exist on the system any longer.  In other words, I can continue to add drives to functions in the array up to my license limit (12 for Plus) but never remove them. Am I correct? 

15 minutes ago, rbm said:

and physically the drives, the designations sdg and sdh remain on the Dashboard, but now as unassigned devices instead of cache drives.

That's not normal, if you physically remove them, they should disappear, but if they didn't they will after a reboot.

You were correct; they disappeared after a reboot.  The reboot was not clean though and ended in a trace.  Hit reset and the system came back with a dirty array that needed parity checked.  Hmmm,  wonder what's up with that.  In any case, thanks for clearing up my question.

On 3/26/2018 at 3:15 PM, rbm said:

When I removed the cache and physically the drives, the designations sdg and sdh remain on the Dashboard, but now as unassigned devices instead of cache drives.

 

When you physically removed the drives, was the array "Started"?  Meaning unRaid has the concept of the "array" being Started or Stopped.  Stopped is the state where you can change the device configuration, etc. without interference by any app which may be using those devices (because if the array is Stopped, no shares are exported, no docker containers are running and no VM's are running).  Clicking the Start button brings the array "online", where all the device file systems are mounted, shares exported, docker and VM's started.

 

If you hot plug or unplug a device, generally this is not recognized by unRaid when array is Started.  If you hot unplug a device and it shows up on the dashboard may be a bug depending on how that device is being used.

 

For completeness, there is another state in-between Started and Stopped which we call Started in Maintenance Mode.  This is a state where devices are brought online but none of the filesystems are mounted (and thus also no shares exported, no dockers or VM's running).  In this state it is possible to perform "file system check" operations.  The fact this must be done with filesystems not mounted is a restriction of the linux filesystem types.

When a drive is physically hot-removed under Linux, the device node remains (dev/sdX)

Some actions need to be done manually prior to removal:

• unmounting filesystem
• deleting device node

When a drive is physically hot-added under Linux, the following actions need to be taken for the device to be recognized:

• re scanning the drive controller for new devices

While the array is Stopped, unRAID is regularly polling the drive controllers for new/removed devices

While the array is Started, unRAID is not checking the controllers for changes and thus does not see the device disappearing. Stopping the array should clear up the trailing device nodes. 

So if you did the device removal while array is Started, that would be a simulation of drive failure (ie Drive disappeared while the array is active) and re adding devices would probably get them to show up as new devices as they have new device nodes.

 

21 hours ago, limetech said:

 

When you physically removed the drives, was the array "Started"?  Meaning unRaid has the concept of the "array" being Started or Stopped.  Stopped is the state where you can change the device configuration, etc. without interference by any app which may be using those devices (because if the array is Stopped, no shares are exported, no docker containers are running and no VM's are running).  Clicking the Start button brings the array "online", where all the device file systems are mounted, shares exported, docker and VM's started.

 

If you hot plug or unplug a device, generally this is not recognized by unRaid when array is Started.  If you hot unplug a device and it shows up on the dashboard may be a bug depending on how that device is being used.

 

For completeness, there is another state in-between Started and Stopped which we call Started in Maintenance Mode.  This is a state where devices are brought online but none of the filesystems are mounted (and thus also no shares exported, no dockers or VM's running).  In this state it is possible to perform "file system check" operations.  The fact this must be done with filesystems not mounted is a restriction of the linux filesystem types.

When I removed the devices, I stopped the array and then unconfigured them from the cache assignment on the main page.  Then I started the array, and physically removed the drives from their hot-swap bays.  Shutdown and startup were cleanly done in both cases.  It's just that the /dev/sdXX devices remained.  I believe that they remained known to the OS because they were both used drives with SMART problems. I believe the I/O problems with the drive prevented the OS from cleaning getting rid of them because of pending I/O or something else related to hardware.  In any case, once  the system was rebooted, the situation returned to normal.

 

I would call this an unusual situation and not related to any defect in Unraid.

1 minute ago, rbm said:

Then I started the array, and physically removed the drives from their hot-swap bays.  Shutdown and startup were cleanly done in both cases.  It's just that the /dev/sdXX devices remained. 

This is why the the sdX devices remained.

The array was already running, so unRAID was no longer issuing the controller scans. Had you stopped the array, unplugged the devices, then unconfigured the cache drives to be able to start the array without them being present the /sdX devices would have then disappeared. There is nothing unusual about this situation, just that most people don't encounter them unless their drives dropped out while the array was live; in which case most people would stop the array to correct the issue and hence not notice that the sdX devices still being there.

 

I've done hot swap replacements before - array drive has too many SMART/sector errors, array restarted to rebuild on a hot spare, remove the failed drive - and the sdX device remains until I restart the array again, or tell the Linux kernel that the device have been removed issuing a command to the dev sysfs

echo 1 > /sys/block/sdh/device/delete