Jump to content

Kyle Boddy

Members
  • Posts

    23
  • Joined

  • Last visited

Posts posted by Kyle Boddy

  1. Shrug. I'm already planning on moving back to Windows Server 2019 because of the fuse filesystem (primarily) and unRAID's general not very good support on this as well as other issues (like my Mellanox thread).

     

    It's insanely slow for large amounts of files. Only wish I had figured that out before I installed unRAID, paid for a license, and spent 3 weeks migrating data + configs. It's a shame because I love the dashboard, docker ecosystem, and tooling, but the core product is extremely flawed for this use case.

  2. 5 hours ago, Frank1940 said:

    You might also try this setting in Windows Explorer.  It tends to eliminate a lot of overhead compared with  the other selections, Windows does a lot of file reading to compile the data for the other choices.  Begin by opening up the Server in Windows Explorer.  Then right click on the share with the issue.

     

    image.png.ff6de1018d1468265f49cca6f94ec3c5.png

     

    Good advice - I do have this set along with other settings on client-side computers to improve the access speed, and it's still 200x+ slower in unRAID.

  3. 4 minutes ago, JorgeB said:

    User shares can be very slow with many small files, if it's an option make those shares use a single disk then use a disk share instead of a user share.

     

    I might try that in the future, but I'd probably just switch back to Windows if I was going to remigrate the data. Is there any way to cache the folder structure in RAM (I have 40 GB available) to reduce this issue? Is the Folder Caching plugin supposed to do this?

  4. This is an excellent guide - very easy to follow and I did so! Unfortunately, browsing directories with thousands of files in them is still very slow. File transfer speeds are acceptable, but indexing/browsing is incredibly slow and I can't seem to get Folder Caching to work to boot. This was not a problem when the server was Windows 10, but using unRAID, browsing/indexing speeds are intolerably slow.

     

    Any idea if RSS should help here, or any other mods?
     

     

  5. I am running the latest unRAID 6.10.3 with Folder Caching implemented and activated, with cache_pressure of 1 set.

     

    I have a few directories/shares that have thousands of files in the top level. Formerly these shares were on a Windows Server box, and SMB browsing of the directories was a bit slow in Windows Explorer, but after indexing, was fine. From the command line after a single file listing (to presumably cache the file structure), access was nearly instant.

     

    This is not the case on unRAID. I have batch scripts that require listing the files from the directory nightly, and the slowdown is somewhere between 200-1000x slower despite the Folding Caching plugin, a 10G-SFP connection, local access, and RSS support enabled (along with a client reboot and server samba restart command issued).

     

    Checking the Folder Caching logs doesn't seem like it's doing much, just repeating an "Executed find" log message every ten seconds or so despite a client machine requesting a directory listing and hanging for several minutes:

     

    Quote

    2022.08.07 16:21:56 Executed find in (0s) 00.18s, wavg=00.18s Idle____________  depth 9999 slept 10s Disks idle before/after scan 9998s/9998s Scan completed/timedOut counter cnt=14694/14695/0 mode=4 scan_tmo=30s maxCur=9999 maxWeek=9999 isMaxDepthComputed=1 CPU= 5%, filecount[9999]=202851
    2022.08.07 16:22:07 Executed find in (0s) 00.17s, wavg=00.18s Idle____________  depth 9999 slept 10s Disks idle before/after scan 9998s/9998s Scan completed/timedOut counter cnt=14695/14696/0 mode=4 scan_tmo=30s maxCur=9999 maxWeek=9999 isMaxDepthComputed=1 CPU= 5%, filecount[9999]=202851
    2022.08.07 16:22:17 Executed find in (0s) 00.18s, wavg=00.18s Idle____________  depth 9999 slept 10s Disks idle before/after scan 9998s/9998s Scan completed/timedOut counter cnt=14696/14697/0 mode=4 scan_tmo=30s maxCur=9999 maxWeek=9999 isMaxDepthComputed=1 CPU= 4%, filecount[9999]=202851
    2022.08.07 16:22:27 Executed find in (0s) 00.18s, wavg=00.18s Idle____________  depth 9999 slept 10s Disks idle before/after scan 9998s/9998s Scan completed/timedOut counter cnt=14697/14698/0 mode=4 scan_tmo=30s maxCur=9999 maxWeek=9999 isMaxDepthComputed=1 CPU= 4%, filecount[9999]=202851


     

    I applied these fixes without much change:

     

     

    Any suggestions? Screenshots of my Folder Caching uploaded along with Diagnostics.

     

    image.png.b912556db248fd13ff4d4e6c96acf7ac.png

     

    And heck, while you're here, if you can look into why I can't bind my Mellanox 10G-SFP card to eth0, feel free to have a look at this thread that has been dying a slow death:

     

     

    morra-diagnostics-20220807-1625.zip

    • Like 1
  6. I successfully was able to bind eth2-4 to vfio-pci which removed them from unRAID. However, the Mellanox card still does not show up in the Interface Rules list, as shown by the images attached.

     

    I have also attached anonymized Diagnostics. Can someone please look into this or advise me to file a bug ticket? I can try binding the last 1G ethernet port to vfio-pci and rebooting and seeing what happens, but I doubt that would fix the problem.

     

    ifconfig on the command line clearly shows eth1 = Mellanox card, and when it isn't bridged to br1, it gets the same IP (static IP set from the router of 172.16.0.124).


    Thanks for reviewing. This seems like a pretty serious bug.

     

    @JorgeB @bonienl

    eth0.PNG

    eth1.PNG

    ifconfig.PNG

    iommu.PNG

    tower-diagnostics-20220731-1837.zip

  7. On 7/9/2022 at 12:53 PM, _cjd_ said:

    I'm running a mellanox connectx-3 - not sure if you're looking for SFP+ or not, but it's been rock solid and can't beat the price off ebay for 10Gb.

     

    edit: I now read GbE so i guess that may mean ethernet/rj45 but I'll leave this up in case it's helpful to someone.

     

    I had issues with getting this to show up in the Interface List - does yours show up there? If so, did you do anything specific to get it there? I am trying to bind it to eth0 and running into this issue:

     

     

  8. There are many posts saying to move the MAC address of an eth3 or similar to eth0 to get the DNS settings and features of eth0. For example, I have my Mellanox 10G-SFP card connected via DAC and working over 10G link, pulling an IP with no issue in unRAID. It's marked as eth4, and when it is connected while eth0 is not (1GBE), DNS issues occur, because unRAID does not allow eth4 to get the DNS server from the DHCP server.

     

    No problem. Re-assign eth4's MAC to eth0 in the Interface List, I've read 20 posts about that subject. No one I've found has this issue, however: The Mellanox card simply does not exist in the Interface List despite being in the Network Settings.

     

    Take a look at the attached image - it shows Interface eth0, eth1, eth2, and eth3, which are all onboard NICs and all 1GBE. eth4 is nowhere to be found despite being directly above that section, and working, to boot.

     

    At the moment I either have to set the DNS server by manually editing the /etc/resolv.conf file every boot by adding nameservers 172.16.0.1 to the file, or keep eth0 connected with 1GBE along with eth4 connected via 10G-SFP, which causes Fix Common Issues plugin to yell about how two NICs should not be on the same subnet (which is true).

     

    Furthermore, on booting with just eth4 plugged in, the unRAID console says that IPv4 address is not set, even though it definitely is by DHCP (another artifact of not having eth0 up, I'm sure).

     

    Any resolution to get this to show up?

     

    EDIT: The card is indeed a Ethernet controller: Mellanox Technologies MT27500 Family [ConnectX-3], but the mode is set properly to ethernet mode (eth), not infiniband mode (IB) as evidenced by the following command's output:

     

    root@Tower:~# cat /sys/bus/pci/devices/0000\:07\:00.0/mlx4_port1
    eth

     

    mellanox-list.PNG

    tower-diagnostics-20220711-2134.zip

×
×
  • Create New...