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


Recommended Posts

4 minutes ago, dlandon said:

No.

I see, thank you for the help by the way I appreciate it :)

 

Would you think this issue is being caused by an issue with the unraid build or unassigned devices itself? or any ideas on what I could do to figure out what is going on? :)

 

Link to comment
1 hour ago, Solverz said:

I see, thank you for the help by the way I appreciate it :)

 

Would you think this issue is being caused by an issue with the unraid build or unassigned devices itself? or any ideas on what I could do to figure out what is going on? :)

 

Let me set it up on my test server and see if I can figure it out.

Link to comment
1 minute ago, dlandon said:

I just fired up Nvidia 6.8.3 and don't see any problems.

Thank you for testing that, I just found some important information to add below as soon as your post came through!

 

I just done some more testing and I found out that the issue only occurs when the jellyfin docker has auto start enabled. This happens on the stock and the nvidia unraid build. (I was incorrect in saying it was the unraid nvidia build causing the issue before Sorry!)

 

So to explain what happens: if the jellyfin docker has auto-start enabled and I reboot the server I get the errors (on stock and nvidia unraid). If i disable autostart on the jellyfin docker and reboot the server I get no errors at all.

 

So basically I have no idea why enabling autostart on the jellyfin docker causes this, I tested all my other dockers which includes plex and I get no errors when autostart is enabled on them...

Edited by Solverz
Spelling Correction
Link to comment
Just now, Solverz said:

Thank you for testing that I juat found some important information to add below as soon as your post came through!

 

I just done some more testing and I found out that the issue only occurs when the jellyfin docker has auto start enabled. This happens on the stock and the nvidia unraid build. (I was incorrect in saying it was the unraid nvidia build causing the issue before Sorry!)

 

So to explain what happens: if the jellyfin docker has auto-start enabled and I reboot the server I get the errors (on stock and nvidia unraid). If i disable autostart on the jellyfin docker and reboot the server I get no errors at all.

 

So basically I have no idea why enabling autostart on the jellyfin docker causes this, I tested all my other dockers which includes plex and I get no errors when autostart is enabled on them...

I suspect you have a mis-configured docker.  Check your mappings, especially to UD devices.  If you are passing through a UD device to the docker, be sure to mark it 'Pass Thru' in UD so it does not get mounted.  A disk passed through to a docker and mounted with UD will be corrupted.

Link to comment
33 minutes ago, dlandon said:

I suspect you have a mis-configured docker.  Check your mappings, especially to UD devices.  If you are passing through a UD device to the docker, be sure to mark it 'Pass Thru' in UD so it does not get mounted.  A disk passed through to a docker and mounted with UD will be corrupted.

I do not have any UD devices being passed through to any dockers but your mention of mappings got me thinking, so I checked them all and decided to re create the Jellyfin docker step by step identically until I ran into the issue. I found out that mapping the dockers transcode folder to /tmp on the host was causing the issue! So after removing this mapping the UD error was no more even with auto start enabled on the Jellyfin Docker.

 

So now the question is why would this mapping cause this error :D

Edited by Solverz
Link to comment
3 minutes ago, Solverz said:

I do not have any UD devices being passed through to any dockers but your mention of mappings got me thinking, so I checked them all and decided to re create the Jellyfin docker step by step identically until I ran into the issue. I found out that mapping the dockers transcode folder to /tmp on the host was causing the issue! So after removing this mapping the UD error was no more even with auto start enabled on the Jellyfin Docker.

 

So now the question is why would this mapping cause this error :D

UD keeps working copies of it's configuration files in the /tmp file system and copies changes to the flash to cut down on flash reads and improve response time.  Your docker probably interferred with the /tmp file system.  I'm surpised you didn't have other issues.

Link to comment
3 minutes ago, dlandon said:

UD keeps working copies of it's configuration files in the /tmp file system and copies changes to the flash to cut down on flash reads and improve response time.  Your docker probably interferred with the /tmp file system.  I'm surpised you didn't have other issues.

That makes sense, the only reason I mapped it to /tmp is because it is a temp directory in the memory which seems a perfect place for on the fly transcodes and I read everyone else was doing it so thought it was fine to do so but this shows that it is not a good idea.

 

I do not fully understand how it all fundamentally works but I will try and map it to a sub folder in /tmp to see if that makes a difference as I assume it wont interfere with any of the other stuff that is loaded in the root /tmp that way? I could be wrong about this though. :)

 

Thank you for the help again!!!

Link to comment
5 minutes ago, Solverz said:

That makes sense, the only reason I mapped it to /tmp is because it is a temp directory in the memory which seems a perfect place for on the fly transcodes and I read everyone else was doing it so thought it was fine to do so but this shows that it is not a good idea.

 

I do not fully understand how it all fundamentally works but I will try and map it to a sub folder in /tmp to see if that makes a difference as I assume it wont interfere with any of the other stuff that is loaded in the root /tmp that way? I could be wrong about this though. :)

 

Thank you for the help again!!!

I agree. I would use a sub-folder and not map to /tmp.  The docker may change permissions and mess up other folders.

Link to comment
28 minutes ago, dlandon said:

The server hosting your remote shares is going off-line:


Jun 19 09:54:12 Tower unassigned.devices: SMB/NFS server '192.168.1.13' is not responding to a ping and appears to be offline.

This can cause issues with other UD device commands timing out.

ok that makes sense, so i only have it set to rsync once daily when that machine is on. i wonder why it is trying at 9am? should be doing it at 6am only. also that is from a workstation PC to the array. should have nothing to do with "unassigned drives".

Link to comment
7 minutes ago, itskamel said:

ok that makes sense, so i only have it set to rsync once daily when that machine is on. i wonder why it is trying at 9am? should be doing it at 6am only. also that is from a workstation PC to the array. should have nothing to do with "unassigned drives".

If you have CIFS mounts (remote mounts) mounted and the remote server goes off-line, there are Linux commands that will hang even when not done on the CIFS mounts.  That is why UD has timeouts on all commands.  If there weren't time outs, UD would hang.  If I remember correctly the worst are 'lsof' and 'df'.

 

If the remote server is only on at certain times of the day, you shoud unmount the remote shares while it is off.

  • Like 1
Link to comment
1 hour ago, dlandon said:

If you have CIFS mounts (remote mounts) mounted and the remote server goes off-line, there are Linux commands that will hang even when not done on the CIFS mounts.  That is why UD has timeouts on all commands.  If there weren't time outs, UD would hang.  If I remember correctly the worst are 'lsof' and 'df'.

 

If the remote server is only on at certain times of the day, you shoud unmount the remote shares while it is off.

ok makes sense now. so should i make a script where it will mount the drive, rsync, then unmount the drive and see how that goes? btw thanks for the reply.

 

Link to comment
On 6/20/2020 at 12:28 AM, dlandon said:

I agree. I would use a sub-folder and not map to /tmp.  The docker may change permissions and mess up other folders.

Mapping to a sub folder worked!

 

Thank you so much for all the help!!! :D

 

EDIT: After testing for a while, mapping to a sub folder in /tmp also started to cause issues.... So based on this I do not think it is a good idea to map to /tmp in any way :(

Edited by Solverz
Correction on findings
Link to comment
5 hours ago, Solverz said:

Mapping to a sub folder worked!

You can also use /dev/shm to map to RAM.

/tmp seems to be mounted to rootfs on unRAID and not a tempfs like /dev/shm.  

For unRAID this shouldn't make much of a difference (since it runs in RAM anyways) but for other Linux distros /tmp might not be in RAM while /dev/shm (if available) should always map to RAM-

 

Edited by Thx And Bye
Link to comment
1 hour ago, Thx And Bye said:

You can also use /dev/shm to map to RAM.

/tmp seems to be mounted to rootfs on unRAID and not a tempfs like /dev/shm.  

For unRAID this shouldn't make much of a difference (since it runs in RAM anyways) but for other Linux distros /tmp might not be in RAM while /dev/shm (if available) should always map to RAM-

 

Thank you for this helpful information! I will give this a try :)

 

However, mapping to /tmp or /tmp/example/ also started to cause issues, so I have edited my previous post...

 

Anyway, I am going to stop discussing this here as it is going to get off the topic of this UD thread :)

 

Link to comment

hi all. I'm getting a weird disk error in a fairly new (couple months old) unassigned SSD. I haven't noticed any performance problems other than trim failing. here's the disk log output:

 

Jun 21 01:00:56 Kal-El kernel: sd 1:0:3:0: [sde] tag#1704 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
Jun 21 01:00:56 Kal-El kernel: sd 1:0:3:0: [sde] tag#1704 Sense Key : 0x5 [current]
Jun 21 01:00:56 Kal-El kernel: sd 1:0:3:0: [sde] tag#1704 ASC=0x21 ASCQ=0x0
Jun 21 01:00:56 Kal-El kernel: sd 1:0:3:0: [sde] tag#1704 CDB: opcode=0x42 42 00 00 00 00 00 00 00 18 00
Jun 21 01:00:56 Kal-El kernel: print_req_error: critical target error, dev sde, sector 1950394355
Jun 21 01:00:56 Kal-El kernel: BTRFS warning (device sde1): failed to trim 1 device(s), last error -121
Jun 21 03:47:43 Kal-El kernel: sd 1:0:3:0: [sde] tag#711 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00
Jun 21 03:47:43 Kal-El kernel: sd 1:0:3:0: [sde] tag#711 CDB: opcode=0x28 28 00 00 37 11 b0 00 00 20 00
Jun 21 03:47:43 Kal-El kernel: print_req_error: I/O error, dev sde, sector 3609008
Jun 21 04:54:20 Kal-El kernel: sd 1:0:3:0: [sde] tag#2505 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00
Jun 21 04:54:20 Kal-El kernel: sd 1:0:3:0: [sde] tag#2505 CDB: opcode=0x28 28 00 01 6d 40 88 00 03 60 00
Jun 21 04:54:20 Kal-El kernel: print_req_error: I/O error, dev sde, sector 23937160
Jun 21 11:24:34 Kal-El kernel: sd 1:0:3:0: [sde] tag#2521 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00
Jun 21 11:24:34 Kal-El kernel: sd 1:0:3:0: [sde] tag#2521 CDB: opcode=0x28 28 00 04 46 5e 50 00 00 48 00
Jun 21 11:24:34 Kal-El kernel: print_req_error: I/O error, dev sde, sector 71720528
Jun 21 11:52:55 Kal-El kernel: sd 1:0:3:0: [sde] tag#1491 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00
Jun 21 11:52:55 Kal-El kernel: sd 1:0:3:0: [sde] tag#1491 CDB: opcode=0x28 28 00 00 e8 2a b8 00 01 40 00
Jun 21 11:52:55 Kal-El kernel: print_req_error: I/O error, dev sde, sector 15215288
Jun 21 11:52:55 Kal-El kernel: sd 1:0:3:0: [sde] tag#1492 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
Jun 21 11:52:55 Kal-El kernel: sd 1:0:3:0: [sde] tag#1492 Sense Key : 0x2 [current]
Jun 21 11:52:55 Kal-El kernel: sd 1:0:3:0: [sde] tag#1492 ASC=0x4 ASCQ=0x2
Jun 21 11:52:55 Kal-El kernel: sd 1:0:3:0: [sde] tag#1492 CDB: opcode=0x28 28 00 04 4b b6 50 00 01 a0 00
Jun 21 11:52:55 Kal-El kernel: print_req_error: I/O error, dev sde, sector 72070736
DONE

"critical target error" and "I/O error" certainly sound ominous. Running smart tests on the disk don't show any problems. Any ideas?

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.