Jump to content

olehj

Members
  • Content Count

    243
  • Joined

  • Last visited

Community Reputation

19 Good

About olehj

  • Rank
    Advanced Member
  • Birthday June 3

Converted

  • Gender
    Male
  • URL
    https://ubrukelig.net
  • Location
    Norway

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @CHBMB Appreciate your complicated plugin, take your time. Thanks! I use it for Emby transcoding and BOINC for Science United!
  2. Oh sweet! I was thinking about creating a plugin/dashboard thing for this tool as well. Glad I didn't have to do it! My Corsair HX1200i is satisfied Looks good!
  3. NFS outdated? It is for sure old, but still widely used and the logic choice for linux users anyway. I tried using Samba without so much more luck really, the problem seemed similar as long as I tried to mount it in fstab. Anyway, to the important bit: Changing the hard link tunable to "no" seem to have solved the issue. Just to be sure here, there's nothing else affected by this? Does Unraid use hard links, and will this tunable might break some functionality? Or is it that I just can't make hard links myself anymore (which I don't use anyway)? fuse_remember has usually always worked at 330, so I will be leaving it to the default value. Anyway, thanks for the update! Tip: add some info that stale file handles might cause issues with hard link support turned on - maybe even on the NFS page itself - would make sense?
  4. In syslog you would find this: Jan 2 21:05:30 Odin emhttpd: req (28): cmdStartMover=Move now&csrf_token=**************** Jan 2 21:05:30 Odin emhttpd: shcmd (2519): /usr/local/sbin/mover |& logger & Jan 2 21:05:30 Odin root: mover: started Jan 2 21:05:30 Odin move: move: file /mnt/cache/storage_ole/testfile Jan 2 21:05:31 Odin root: mover: finished File and folder names might reveal things you don't want to be released. And should probably be scrambled regardless of settings (at least after the main share name). The syslog file is just included in the diagnostic without anonymize this data when the anonymize button is checked.
  5. Alright, I have to ask again, because it is something really strange happening here The only affected NFS shares is the ones with an enabled "Cache" drive. Reading/writing directly to: UD devices: no problems. Cache/scratch: no problems. Unraid data with cache: stale handles after a file has been moved (but not always, sometimes it get instant stale instead when a file has been created) Unraid data without cache: no problems (deactivated cache for the ones which had problems). NFS mount options are identical all over (tried static (my default) and autofs), I even got the same problem with SAMBA, but only when it's mounted via fstab at client side. I simply can't see why this problem would be on my end. Running without cache drive is -NOT- a solution, just a workaround.
  6. Changed Status to Closed Changed Priority to Minor
  7. It turns out it happens with my Kubuntu 19.10 install, dmesg is filled up with: [ 307.567757] NFS: server 192.168.5.10 error: fileid changed fsid 0:59: expected fileid 0xfd00000301de1fda, got 0xfd0500006014b341 [ 307.567965] NFS: server 192.168.5.10 error: fileid changed fsid 0:59: expected fileid 0xfd00000301de1fda, got 0xfd0500006014b341 ..when I create a file on a share, after refreshing the folder I get a stale file handle. Can access it through Samba without any problems, and it works with NFS in Win10Pro (even if it spits out a load of inputs into syslog in Unraid).
  8. I don't see why this is related to UD at all. UD only share one device "Data", and does NOT mount anything from a remote location. Unraid/UD does not have anything mounted from remote devices at all. So far this breaks the functionality for me, I see it's correct to use "Urgent"
  9. Must add that the 9000 MTU 10GbE NIC ran entirely their own local network directly connected between two NIC's, and should not even be conflicted within the regular net. But it was tested with 1500 MTU as all other cards. The network connection here is quite solid overall and never had it drop out. Also, there was someone mentioning the same problem with 6.8.0rc5 in the forums here as well. He/she "fixed" it by disabling the cache, also not a real fix.
  10. There's a reason why I choose to use logging, I want to make sure the Mover worked as intended. And so far we have the option of creating anonymous diagnostic file, then this should be excluded/scrambled as well. Turning it off does not remove the Mover log entries until you reboot when the syslog is written from scratch again. Not solving the problem unless it was off the entire time (which is default). It still should be fixed.
  11. All NIC's running at 1500 MTU, no difference whatsoever.
  12. The 1GbE uses the default MTU, and there was no change. However, it was working for over a year without problems with jumbo frames on the 10GbE. I doubt this is a network problem as it happens on two entirely different network connections and subnets.