19 minutes ago, dlandon said:

You probably have a corrupted flash drive.

Just did some more testing. This only happens with the nvidia unraid build as when using stock unraid, I get no errors at all!

 

Have you heard of this issue before?

5 minutes ago, Solverz said:

Just did some more testing. This only happens with the nvidia unraid build as when using stock unraid, I get no errors at all!

 

Have you heard of this issue before?

No.

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?

 

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.

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

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 June 19, 20206 yr by Solverz
Spelling Correction

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.

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

Edited June 19, 20206 yr by Solverz

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

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.

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!!!

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.

I noticed that every once in a while I get a error in my log. Anyone know what this means? And or should I be concerned?

 

I do have my dockers and VM's running on the NVME samsung drive.

 

2 hours ago, itskamel said:

I noticed that every once in a while I get a error in my log. Anyone know what this means? And or should I be concerned?

 

I do have my dockers and VM's running on the NVME samsung drive.

 

Post your diagnostics.

1 hour ago, dlandon said:

Post your diagnostics.

here they are.

tower-diagnostics-20200620-1150.zip

51 minutes ago, itskamel said:

here they are.

tower-diagnostics-20200620-1150.zip 134.43 kB · 0 downloads

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.

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".

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.

I released a new version 2020.06.20 that fully supports 6.9 Multi Language.  Those of you on 6.9 Beta will be able to download the language packs and have UD translation installed as it gets translated for each language.  @ich777 is working on the German translation.

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.

 

37 minutes ago, itskamel said:

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.

 

Yes.

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!!!

 

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 June 21, 20206 yr by Solverz
Correction on findings

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 June 21, 20206 yr by Thx And Bye

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

 

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?

I did a quick search of this thread and didn't see anything relevant so sorry if this has been asked before.

 

Can we have UD show the temp for zfs_member drives? It shows in the SMART info and just needs to be passed to the main page.