limetech

If you google 'ryzen linux' you will find numerous reports. Here is the granddaddy: https://bugzilla.kernel.org/show_bug.cgi?id=196683 AMD replaced early chips: https://www.extremetech.com/computing/254750-amd-replaces-ryzen-cpus-users-affected-rare-linux-bug

Not close, soon(tm)

Thanks for the debugging help. I can't explain why this works at this time. If the issue gets reported more often we'll have to dive into kernel source to see what's going on. It appears you have only 1GB RAM, that's right at the minimum we recommend. Probably related to this.

Well that look a-ok. How about output of: cat /boot/syslinux/syslinux.cfg

Thank you. One more request? Please post output of this command: cat /proc/mounts

Please post diagnostics.zip Tools/Diagnostics I'd like to see what's going on, probably it's going to be, "ahh right, that's what's happening"... thx

I don't see how that works at all - there is no 'root' device in Unraid. What is /dev/sda referring to after you boot? OP: you could also try UEFI boot.

Please elaborate. Does this mean your video stream completely freezes, or bad stutter, or webui unresponsive? And you notice this precisely when mover starts and then frees up precisely when mover finishes? What is being moved? The 'mover' is very aggressive at copying files. It uses 'sendfile()' kernel interface that can result in copying a large file in a single system call. If cache is on SSD and moving to a HDD could be RAM is rapidly and totally filling up with buffered data. If this is the case, will require some thought about how to fix.

We can try to add that patch to upcoming Unraid 6.7 release which is on 4.19 kernel at the moment.

All correct. Here's the conundrum: It is possible in 'shfs' to pass the inode number of the file on the actual device it's located on. However, recall that inode numbers must be unique within a file system, and linux considers entirety of 'mnt/user/' a single file system. It's possible there could be files on multiple disks that have the same inode number. Back when hard link support was added, we added a change so that 'shfs' would form an 'st_ino' field that consisted of the actual inode number of the file along with the disk number - this made 'st_ino' unique. BUT we started getting reports of all kinds of NFS-attached media players all of a sudden not seeing all the files within user shares. After much debugging and actually looking at source code for one of these players, it turned out that our 'st_ino' field sometimes was greater than 32 bits (the field itself is 64 bits), this combined with a bug in the player NFS client code resulted in the issue we were seeing. The compromise reached was to revert our change to pass the actual inode values.

That should not be the case. Are you sure you really have hard links? You can look at the inode numbers on the /mnt/disk<N> where the files exist to verify.

Your 'ls -li' command is listing "pseudo" inode numbers in the fuse file system. The two names indeed point to same file. Example: root@Test1:/mnt/user/test# echo "foo" >foo root@Test1:/mnt/user/test# ln foo bar root@Test1:/mnt/user/test# cat foo foo root@Test1:/mnt/user/test# cat bar foo

Maybe. Is your web browser sitting on the Dashboard page? If so, if you navigate off that page or close the tab, does 'lsof' activity go away? If not, could be some other plugin using that command.

Please post diagnostics. Tools/Diagnostics

"support", as in linux kernel longterm support, means they will back-merge bug fixes only. With rare exceptions, no new device support, not even new PCI ID's for device which use the same driver as existing devices. Also, in the past I've been concerned about btrfs development - the line between a "bug fix" which will get back-ported and "improvement", which is not back-ported, is has not been that well defined. Meaning, some "fixes" required more code changes than developers were comfortable about trying to back-port. These days, I think that has largely settled down. Bottom line is that we need to try and keep up-to-date with kernels in order to support the latest hardware. Very likely Unraid 6.7.0-rc1 will be released with 4.19 kernel, but possible we move to 4.20 kernel before 6.7 stable is released.

It's a little funky - it only shows up after you have specified a header text color. I would say this is a bug.

Good idea, thank you.

Probably these will get merged into 4.19 since 4.19 is a LTS (long-term support) kernel.

It was prophetic.

To upgrade: If you are running any 6.4 or later release, click 'Check for Updates' on the Tools/Update OS page. If you are running a pre-6.4 release, click 'Check for Updates' on the Plugins page. If the above doesn't work, navigate to Plugins/Install Plugin, select/copy/paste this plugin URL and click Install: https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer.plg Refer also to @ljm42 excellent 6.4 Update Notes which are helpful especially if you are upgrading from a pre-6.4 release. BIOS: Especially if using Virtual Machines, we highly recommend keeping your motherboard bios up-to-date. Bugs: If you discover a bug or other issue new to this release, please open a Stable Releases Bug Report. This will likely be the last of the Unraid 6.6 series since the linux kernel, 4.18.20 was recently marked EOL (no more updates). We had a devil of a time deciding whether to simply update to the 4.19 kernel now, but we're about to start Unraid 6.7 public -rc, which uses 4.19 kernel. If 6.7 stretches out too far we may need to produce a 6.6.7 for security updates of if something apocalyptic comes up. Version 6.6.6 2018-12-01 Base distro: openssl: version 1.1.1a (CVE-2018-0734 CVE-2018-5407) openssl-solibs: version 1.1.1a (CVE-2018-0734 CVE-2018-5407) samba: version 4.8.7 (CVE-2018-14629 CVE-2018-16841 CVE-2018-16851 CVE-2018-16853) Linux kernel: version 4.18.20 OOT Intel 10gbps network driver: ixgbe: version 5.5.2 Management: bug fix: error reported by 'btrfs filesystem show' prevented proper btrs cache pool analysis update smartmontools drivedb and hwdata/{pci.ids,usb.ids,oui.txt,manuf.txt} webgui: Black and White theme: make select arrow consistent for all browsers webgui: All themes: create consistent select arrow for all browsers using pure css webgui: Fixed: flash share warning is given when SMB is disabled webgui: Added customizable header background color webgui: All themes: css corrections webgui: Revert FAT32 filename collisions webgui: Dashboard: add disk utilization, cpu load & memory usage coloring webgui: Syslinux Configuration: rename Basic/Advanced view to Raw/Menu webgui: Fixed: parity schedule not taking zero values (e.g. Sunday=0) webgui: Prevent Adblocker from hiding share list webgui: Fixed missing font-awesome class in VM CPU popup window webgui: Improved PCIe ACS override help text webgui: Improved VFIO allow unsafe interrupts help text webgui: Apply syslinux changes to all menus except safe mode webgui: add per DIMM information toggle webgui: Fixed PHP warnings in Vars.page webgui: Docker: narrow CPU pinning list to fit lower resolutions webgui: Added confirmation checkbox when missing disk in array webgui: Disable cache slots selection when cache disks are re-arranged webgui: Added confirmation checkbox when missing cache disk webgui: Remove unused information in array view

Bilged the last two posts in this topic - please keep it civil people.

Correct. We're adding bt kernel drivers in Unraid 6.7 release.

These are not random people on the internet, they are specifically users of Unraid and presumably they know how they want iSCSI support to get integrated. Although the post immediately following yours argues otherwise. 🙄

That's the key question for us. iSCSI is nice, but this could be a rather large effort to get right. What is the minimum usable iSCSI support? eg, simply map an 'md' device to a target backing store?

In samba settings for a share, if your add: browseable = No Then the share will not show up in windows Explorer. Not sure if UD can make this happen, but that's the way to solve it.