-
Posts
10,192 -
Joined
-
Last visited
-
Days Won
196
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Report Comments posted by limetech
-
-
Please try this test. Go to Settings/NFS and set the "Tunable (fuse_remember)" setting to 0. This might cause your clients to crash and burn due to "stale file handle", but maybe not. Would be interesting test.
-
Were you seeing similar slow performance with previous Unraid OS releases?
-
Changed Priority to Minor
-
What is the nature of the transfer taking place when the crash happens?
That is, reading from server or writing to server?
Large files or small files?
What program is running in the client?
Can you post your /etc/exports file?
I'm having a hard time reproducing this bug.
-
8 hours ago, Rhynri said:
@limetech - If you could please include lstopo in a future release I'd greatly appreciate it.
Added for 6.6.1 release.
-
2
-
-
I also suggest rebooting in 'safe mode' just to rule out plugins which may be clobbering newer packages with older ones.
-
5 hours ago, edgedog said:
Is this issue on your radar and being worked? Is there anything we can provide you to help you do so? Thanks!
Yes, you should already know we need diagnostics.zip not just a syslog snippet which barely helps to troubleshoot anything.
Also it appears you are running Unraid in an ESXi virtual machine. We cannot reproduce this exact issue because we cannot duplicate your exact config. That said, it's possible you are running out of memory. This is because NFS uses an archaic concept called "file handles" which is a numeric value that maps to a file, instead of a path. In a lot of file systems this maps to the inode number. In 'shfs' there are no fixed inodes that correspond to files. Instead inodes are generated and kept in memory by FUSE. That "remember=330" mount option tells FUSE to keep these inodes in memory for 5 1/2 minutes. This was chosen because the typical modern NFS client will cache file handles for 5 minutes. If the client asks for I/O on that handle within 5 min and the handle is no longer valid, you get "stale file handle" messages. After 5 min, the client typically uses a path to re-read the file handle. However you can open alot of files in 5 minutes. This is made worse if you have something like 'cache_dirs' plugin running against shfs mount points. Maybe try increasing memory allotted to the VM and/or reduce that 'remember' value.
On the other hand, it could be an entirely different issue, don't have enough info to determine this.
-
Changed Status to Retest
-
Please don't paste a bunch of syslog entries in your post; we'll see them in the diagnostics.
-
5 minutes ago, Can0nfan said:
why is it broken
don't know
-
1
-
-
Probably this issue is related to NFS mounts of directories under /mnt/user/sharename. Do you have to use NFS in this manner? Why not use SMB? Using UD to do this is untested by anyone at LimeTech.
-
1 hour ago, CHBMB said:
quick someone remove Tom's admin status!
Please do!!
-
Just deleted someone's post by accident, which appeared in topic right where this one did... sorry!
-
Changed Status to Retest
-
Can't do anything without seeing diagnostics.zip captured when issue is happening.
-
Changed Status to Closed
-
Changed Status to Closed
Changed Priority to Other
-
2 minutes ago, david279 said:
I think he's talkiung about the problem with rebooting VMs with certain AMD GPUs. They get stuck and you have to reboot the host to get back into the VM.
Which Bug Report does this refer to?
-
3 hours ago, J89eu said:
Just to confirm after my first post, the AMD reboot bug still exists...
What's the "AMD reboot bug"?
-
1
-
-
We should be able to fix this since it was apparently working before but none of our test servers shows this issue. I'll have to dig up some GPU cards from the junk box and see if we can duplicate. Probably won't have the time to do this before releasing 6.6.0 stable however.
-
Changed Status to Solved
-
25 minutes ago, jonp said:
Luckily we have a threadripper and threadripper 2 as well and we too see some issues with stuttering (but not the boot time issues documented here). I know we're looking into it.
This provides a nice insight into our release process. In the past we would hold back stable releases until all the stuff that previously seemed to work in a prior stable, for some reason quit working correctly in current development.
Clearly if this is something we did, meaning a bug in s/w we write, then probably we would hold back the release. But in this case it's not so clear where the issue is. Therefore, we will probably be releasing 6.6.0 stable even if this issue persists. This is because 6.6.0 includes lots of updates and security fixes which need to be published and this particular issue, though extremely annoying, does not affect a huge percentage of the user base.
-
1 minute ago, bonienl said:
This behavior exists since version 6.0 was introduced.
By default bonding is enabled to allow people to connect to any available port of their system and avoid them complaining about their connection not working because they didn't use eth0 (which happened frequently in the past).
And with motherboards with multiple RJ45 connectors it can be unclear which one is "eth0".
-
This is a very complex subject which will take some thought to determine settings that "won't work". Also this is beyond the scope of this topic.
[6.6.0] NFS Kernel crash
in Stable Releases
Posted
yes diagnostics would be nice as well as seeing your /etc/exports file, which we omit from diagnostics.zip for some reason. (That file only defined NFS exports.)
Also try above test to set 'fuse_remember' to 0.