Genom

Than maybe on the new flash something got corrupted, because the same cache drives/array under 6.8 worked fine, and once I went in and removed my cache pool use a yesterday, the share has been working fine without the unstable start stops I had. I am too behind on stuff to fiddle with the cache settings for the next few weeks so I am going to mark this as solved, but I don't really feel it is and will likely have to revisit it.

Adding on that I have been doing some testing, and it may have been related to the 6.12 storage changes. I was running on 6.8 for a while since it was stable and I dont update stable things, but my flash drive died, and when I got a new one re-licensed, I put on the latest software package, that being 6.12, and it changes the concept of cache completely. So my config was primary storage cache, secondary array, and with only 2TB of cache SSD, it was constantly shuffling files around it looks like. Changing my share to Array only, things seem to be more stable, but needs more testing. At least I was able to finally copy a 42GB backup file that had been pending forever.

I appreciate the feedback, but I dont think this is the issue, as the storage is much faster than my 1Gb ethernet. I can also create a share on pretty much anything in my network, and move a 10GB file with no start/stops. It's only the Unraid system that does it.

Been having this issue for a while now. Didnt push much as the server was virtualized and unsupported, but after dealing with the issue for a year I gave in and moved back to a physical server, but the issue is still there. it is:\ On transfers to the singular share I have setup it starts OK, and runs fine for a minute or so. Then network transfers stop, my disk IO times shoot up, and it sits there. If it's something like sabnzdb doing a download, it eventually restarts and completes, but something like a plain file copy/backup form my system to the share fails because the timeout is too long, sometimes I even lose t he network mount. Main work machine runs Arch/KDE, but other network devices such as Linux and Windows laptops show the same issue. CPU usage during this is usually pretty much idle, except for 1 core pegging 100%. Sometimes it stays pegged, sometimes a different core gets pegged, before then settle down and transfers start again. Reducing transfers speeds in sabnzbd can help improve stability, but then I am downloading at half or less speed. Attached for reference is a diagnostics package created while downloading with sabnzbd about 5 seconds after a slowdown from 40MB/s to nothing. I can also do a large file copy and generate when it crashed if that would be more helpful. Any other info/tips/ideas would be appreciated. Its not a dealbreaker yet, but it is causing issues with my backups and work and I would like to fix it. nas-diagnostics-20241017-0103.zip

If it helps anybody in the future when virtualizing with Proxmox 8.1 When starting the VM, before it gives the UEFI shell, hit Esc. It will look to lock up with some dialog at the top of the screen, but after 20-30 seconds it will go into the UEFI interface. At this point go into the boot options and change the boot order, Make sure the USB drive is the first boot device. Save and reset, and it will startup.

Just tried that, and I get a Access Denied error. Same thing if I try to manually load the efi So no go so far.

I have several Debian VM's on this server that run as UEFI just fine. I am now trying to virtualize my unraid server to get it into a redundant hardware environment, but cant seem to get it to boot. I have created the VM, pass through the USB port to the VM. If it is set to UEFI, it does not boot, just dumping me into the UEFI shell. ls fs0: in the shell shows the USB folders, and EFI/boot/boot64x.efi exists. I tried creating the USB with the image writer as well as manually, following the instructions for a manual setup, but have the same result. If I change the VM to BIOS, it starts up fine, but since I am going to be passing through a LSI 9300 for HD's, wanted to stay in UEFI all around. These issues show up before passing through the PCIe card at all. If anybody has any suggestions, it would be greatly appreciated