Unassigned Devices - Managing Disk Drives and Remote Shares Outside of The Unraid Array


Recommended Posts

8 hours ago, mDriver said:

I am trying to install unassigned.devices-plus from https://github.com/dlandon/unassigned.devices/blob/master/unassigned.devices-plus.plg to access my exFat drives but the installation process failed with simple-xml parse errors 

Install it from Community Applications.

Link to comment
21 hours ago, dlandon said:

Update to today's release.  It should help with the disks being detected.

I have backup unassigned.devices.cfg and delete it, try does current release have detect disks normal. BTW, result still negative.

 

- Only two disk show and first row blank name ( after 1st refresh )

- Each refresh will show one more disk and first row still blank name

- All dev always correctly show on dashboard page

- I make UD have 21, 9 or 3 disks also got same issue

- when problem occur, some process cause high CPU loading

- Restore backup cfg file, then all work again

 

image.png.7eeaa29d68bcff4b8543ab42729fc1d3.png 

 

image.png.7a9b2dd4123530a928e0d0e4ccb168bb.png

 

image.png.7d07ef7bfd74fdd3d6cede640edc49ca.png

 

image.png.bc2bc3c0081038355a2d1b0a79834b4e.png

Edited by Vr2Io
Link to comment
7 minutes ago, slimshizn said:

Thought my server just kicked off my UD's. Rebooted ( after a LONG uptime ), still down, came here to check out what's going on.

Went to historical devices, clicked on each disks settings.
Hit save

Hit done

Each is back where it's supposed to be.

Cool update.

What version of Unraid are you running?

Link to comment
22 minutes ago, slimshizn said:

Went to historical devices, clicked on each disks settings.
Hit save

Hit done

Each is back where it's supposed to be.

The new disk alias feature does things a little different with regard to Historical devices.  When a new device is hot plugged UD assigns the 'devX' to the hot plugged device and creates an entry in the unassigned.devices.cfg file.  When the device is removed, it will show in the Historical devices list.  Normally a historical device would not show unless the user made some setting changes on the device.

 

What you did was to overcome something I am not getting right when UD does the saving of the 'devX' and there is no current entry for that serial number in the unassigned.devices.cfg.  I'll try to reproduce this issue and see if I can resolve it.

  • Like 1
Link to comment

Can I check somewhere what exact command the Plugin runs when I click mount?
In a specific log file maybe (aber I clicked it)

I have a share I dont want to keep mounted,  because it might keep the USB HDD spinning all the time (the Host is no real server), so I want to add the mount command to the (LuckyBackup) sheduled task  (and unmount after) - if possible.

Link to comment
37 minutes ago, wambo said:

Can I check somewhere what exact command the Plugin runs when I click mount?
In a specific log file maybe (aber I clicked it)

I have a share I dont want to keep mounted,  because it might keep the USB HDD spinning all the time (the Host is no real server), so I want to add the mount command to the (LuckyBackup) sheduled task  (and unmount after) - if possible.

The best way to do this is to assign an alias disk name and add commands to your script to mount, unmount, and spin down the disk:

# Mount a disk
/usr/local/sbin/rc.unassigned mount name=diskname
# Unmount a disk
/usr/local/sbin/rc.unassigned umount name=diskname
# Spindown a disk
/usr/local/sbin/rc.unassigned spindown name=diskname

 

Link to comment

I really dont understand myself sometimes. I just found that big blue section that literally explains what I wanted to know...

I was unsure about the alias disk name (google really didnt bring something fitting in the first hits)... but in the blue box it just uses the SOURCE which I can look up.

 

Link to comment
5 hours ago, dlandon said:

The new disk alias feature does things a little different with regard to Historical devices.  When a new device is hot plugged UD assigns the 'devX' to the hot plugged device and creates an entry in the unassigned.devices.cfg file.  When the device is removed, it will show in the Historical devices list.  Normally a historical device would not show unless the user made some setting changes on the device.

 

What you did was to overcome something I am not getting right when UD does the saving of the 'devX' and there is no current entry for that serial number in the unassigned.devices.cfg.  I'll try to reproduce this issue and see if I can resolve it.

Thank you for your work.

Link to comment

Is there a place for feature requests? Specifically,

 

1.) Creating a button to easily archive or delete log files

2.) A button to enable autoscroll when viewing the log...Really handy when clicking on the refresh button to watch the scripts progress.

3.) Easy way to specify log file location (storing on the flash drive is handy)

 

 

Link to comment

I've encountered a new issue, or at least it appears to be since my searches on Google and here on the forums haven't revealed anything. 3 days ago I started replacing 3 of my 10TB drives with 3 x new 16TB drives. All went well with the replacements, but I've encountered a problem. I wanted to zero the old 10TB drives so I could use 2 of them to replace a couple of aging 8TB SMR drives on my backup server. I connected the drives to my hot-swap rack on my media unRAID server and UD sees them, but puts an 'ARRAY' label on them.

 

No option to preclear, format or remove partition(s) from the disks. I assumed something odd had been written to the drives so I used SeaTools to 1st try erasing just track zero. That didn't work. I then tried attaching the drives to an Ubuntu system and it sees the drives as XFS formatted, but they are not mountable and xfs_repair doesn't seem to be able to fix them. As a last ditch resort I booted SeaTools and ran a FULL erase of one of the drives. When re-installed in the hot-swap rack, it still shows with the ‘ARRAY’ label and no options to do anything.

 

Something in either UD and/or unRAID itself has likely changed and it’s keeping a list of devices which were previously in the array. As a full zero of the drive with SeaTools didn’t change this behavior, I’m sure it’s not the drives themselves but a code change in UD and/or unRAID. Suggestions?

 

UDIssue-DeviceShownasArray.jpg.e4fc64b6e8fc89055ce60ad4f24204a0.jpg

Link to comment

The 'Array' indication on the 'Mount' button is from Unraid not assigning a 'devX' device to the disk.  Notice the device shows as 'sdb' and not 'Dev X'.  The idea behind this is to give you a heads up that the disk dropped out of the array.  Unfortunately there is a bug that creates this situation in certain cases of the order when UD devices are hot plugged.  It is fixed in 6.10rc3 (not yet released).

 

There are several ways to fix this:

  • Stop the array and then restart the array.  The 'devX' designations will be reset.
  • Reboot the array.
  • Thanks 1
Link to comment
12 minutes ago, dlandon said:

The idea behind this is to give you a heads up that the disk dropped out of the array.  Unfortunately there is a bug that creates this situation in certain cases of the order when UD devices are hot plugged.  It is fixed in 6.10rc3 (not yet released).

 

Thanks for the quick response. It's definitely bothersome and until the last few UD updates it hasn't been an issue. In my case the drives were not dropped from the array or disabled - they were replaced while the drives were still fine and just upgraded to higher capacity models.


Perhaps you might consider adding some code to UD that will let users 'override' this scenario? At least the option to wipe all partitions from the disk and remove it from historical devices. I'm running 6.10.0-rc2 and have been for a few months and this is the 1st time I've encountered this.

 

I’ve used the same pro-active replacement of the drives before they fail or get dropped from the array a couple of times since I've been on rc2. It's only after the last 2 - 3 UD updates that the issue started. I don't use USB drives in the array and so far I can't recall any times where a SATA connected drive was dropped except when it completely failed.

 

Stopping and restarting the array or rebooting unRAID may work for some but it isn’t a great option when you have numerous users actively accessing data on the server.

 

Link to comment
8 minutes ago, AgentXXL said:

Stopping and restarting the array or rebooting unRAID may work for some but it isn’t a great option when you have numerous users actively accessing data on the server.

Understood.  Once 6.10rc3 is released, you can upgrade and this should not be a problem.  You might try clicking on the double arrows in the upper right hand corner of the UD page.  There's a slight chance that might fix it.

Link to comment
11 minutes ago, dlandon said:

Understood.  Once 6.10rc3 is released, you can upgrade and this should not be a problem.  You might try clicking on the double arrows in the upper right hand corner of the UD page.  There's a slight chance that might fix it.

 

I assume you mean the 'refresh' symbol? Tried that numerous times and it hasn't resolved it. Now waiting for users to respond to my reboot notification but that could be hours. And as for rc3, who knows when that will come. Guess I get a forced break from my tasks until then.

 

Do you know which version of UD I could try to roll-back to so I can try to resolve it in the interim?

 

Edited by AgentXXL
grammar
Link to comment

I didn't think the refresh would do anything, but thought it would be worth a try.

 

There isn't a previous version of UD to roll back to.

 

Maybe you should consider planned maintenance during a quiet time so you can handle these situations.  If you're running 24/7, you're running a data center operation.  Unraid wasn't really meant for that.

Link to comment
1 minute ago, dlandon said:

I didn't think the refresh would do anything, but thought it would be worth a try.

 

There isn't a previous version of UD to roll back to.

 

Maybe you should consider planned maintenance during a quiet time so you can handle these situations.  If you're running 24/7, you're running a data center operation.  Unraid wasn't really meant for that.

 

COVID has forced many of us to build out our homelabs so that we can work from home. unRAID certainly isn't what I'd use if I was back at work daily.

 

I just find it odd that it started after one of the last 2 or 3 updates to UD. I have done this same capacity upgrade procedure a couple of times since running rc2 and this is the 1st time I've encountered this problem. What's really annoying is that a drive that has been completely wiped by the manufacturer tools (SeaTools in this instance) still shows up with the 'ARRAY' tag. That's obviously pointing to something that's tracking the drive by s/n or other methods in either unRAID or UD. Very frustrating.

 

 

Link to comment
1 minute ago, AgentXXL said:

I just find it odd that it started after one of the last 2 or 3 updates to UD.

This feature was just added a few releases ago.

 

1 minute ago, AgentXXL said:

That's obviously pointing to something that's tracking the drive by s/n or other methods in either unRAID or UD.

Unraid tracks serial numbers to know where a disk is installed.  UD tracks serial numbers so you can attach certain settings and operations to a UD disk.  This issue has nothing to do with tracking a serial number.  UD requests Unraid through an API call to present a list of the disks Unraid does not have assigned to the array, or a pool.  These are Unassigned Disks and Unraid assigns a 'devX' designation to the disk.  Because of a bug, there are times when Unraid doesn't get the list of Unassigned Devices correct.

 

The 'Array' designation has nothing to do with a partition being there or a file system on the partition.  UD sees the disk and when Unraid does not assign a 'devX' designation, assumes the disk dropped from the array.  This has happened to users with cabling and controller issues.  If the disk is not marked 'Array' and the user tries to do anything with the disk, they risk losing data or invalidating parity.  Neither of which is good.

Link to comment
12 hours ago, slimshizn said:

Thought my server just kicked off my UD's. Rebooted ( after a LONG uptime ), still down, came here to check out what's going on.

Went to historical devices, clicked on each disks settings.
Hit save

Hit done

Each is back where it's supposed to be.

Cool update.

 

I had the same experience after updating the UD plugin to the latest version just now. All my UD drives had been moved to history. Thanks for the quick fix you provided, it resolved the situation easily.

  • Like 1
Link to comment
2 minutes ago, Lev said:

 

I had the same experience after updating the UD plugin to the latest version just now. All my UD drives had been moved to history. Thanks for the quick fix you provided, it resolved the situation easily.

Thanks for letting me know.  It was literally a two line fix of a rather simple problem once I found it.

  • Like 2
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.