SMB Speed starts out great but gets really slow (to around 20MB/s) a day after installation

  • Hi there!


    So far I've been very happy with OMV and everything works as it should... well, almost.


    When doing a fresh install, my SMB speeds are fantastic! Constantly maxing out between 90-110MB/s. Awesome! I could transfer 200GB of large files and ~100GB of many small files without a problem at all. 6 hours later, another ~500GB of files went through with a rock solid speed of 100MB/s as well.
    But somehow, after a day or two after installing OMV, the SMB transfers are getting REALLY slow to about 5-20MB/s with even a few sudden drops to the KB/s range. Since I googled for around 5 hours and were getting nowhere, I just did a fresh install yesterday and everything was working fine again. Heavenly speeds. (I thought I must have somehow broken some kernel thing when I did an update previously).


    But around 12h after the fresh install, the speeds are back to being horrendous.
    I googled again for around 4 hours and I'm seriously getting frustrated so maybe someone can help me out here.




    My configuration is:
    Raspberry Pi 4B,
    Root fs on SD card (64GB Sandisk Extreme UHS-I Class 10)
    Raspian Buster Lite -> Install Script -> OMV
    Data drives are 2x 4TB HDD's, connected via USB3 (external power) in a 2-bay enclosure
    Gigabit LAN (working and recognized as such)



    Since the configuration is working perfectly after fresh install, I can rule out a hardware issue, so it must be some configuration. What I did so far trying to resolve the issue:
    - Rebooting OMV and PC (of course, lol)
    - Checking Energy Management, tried different settings
    - Tried every possible setting in smb.conf
    - Disabled SMB 1.0 in Windows
    - Tried different SMB versions
    - Checking System Time synchronization of PC and OMV
    - Switched from DHCP to static (although my router is assigning a static IP address anyway)
    - Checking "top" -> CPU is almost at idle all the time, around 0.3%
    - Checking Ram, using 0.1% of total RAM
    - Checking "iotop" -> Nothing special
    - (i'm sure I did some other things as well but these are the ones I remember at least)



    In my mind, there can also be another two possible issues that I didn't check:
    - Wrong SMB config (since I did shutdown and start my PC in between the "working good" and "working bad" cases)
    - The Filetransfer is somehow getting cached on the SD card and getting transferred to the HDD (since the ~20MB/s is the write speed I get when writing directly to SD card via SMB)
    (these are just "meh, could theoretically be possible" scenarios)


    So... does anyone have a clue about what might be happening here? I'm getting crazy!


    Thanks :)

  • Are you transferring files constantly or intermittently? Because the memory controller on SDcards is not meant for constant operation & is likely throttling as it gets too hot. It's also possible that the USB controller on the Pi is having trouble with constant operation (bear in mind a $35 computer will have compromises on component quality which are unavoidable for obvious reasons).


    If constant operation is what you're after, you may be better off getting a mid-grade x86 system.

    • Offizieller Beitrag

    I have no problems saturating GbE when transferring large files to/from my RPi4. However, I use NFS.


    But if I add extra protocols like SSH or rsync, the speed goes down. Also if it is many small files rather than few large. Also if it is several parallel transfers.


    if the SD card is involved in caching any of the file transfers to from your RPi4, then your OMV install is massively borked. So I doubt that is it.


    Temperature problems?
    Power problems?
    The windows client in the other end is slow?

  • Ah yeah, I should've mentioned: using ext4.


    Funnily enough, temperature is the only thing I didn't check, but I'm guessing this won't be it since I've installed heatsinks and a fan on the RPi.
    Power can't be the issue because it's a proper 3A PS.
    Windows client is an i7 @4.4Ghz with 32 Gigs of ram, checked transfer from NVME SSD as well as HDD - makes no difference.


    I'm completely clueless... ?(


    Still, will check temperature and try to disable ssh and see how it goes.


    EDIT: Just checked and idle CPU is around 40°C. While transferring it stays rock solid @42°C, occasionally spikes up to 43°C but that's it.

    • Offizieller Beitrag

    If you reinstall, make sure to clone the SD card at once. And see if things get fast again after restoring the card.


    Is there something else installed, on top of OMV? Did you change ANY settings at all before performance was reduced?


    Try iperf to check bandwidth.


    Try to boot the client from a live Linux distro and test Linux to Linux.


    Also the SATA / USB interface in the enclosure might be incompatible with Linux.


    No need to disable SSH, if you don't use it when copying files.


  • Nope, nothing there. No Docker, no Portainer, no other software. Only OMV.
    Sure, I did the usual stuff like adding users, adding shares and stuff but nothing fancy. Not even an update.


    iperf test looked just like I suspected:


    The JBOD enclosure might not be ideal for Linux but that still doesnt explain why I get full ~100MB/s for HOURS on end until this error occurs ?(


    EDIT: Will test on a Linux Live version now to see if smb is the problem. Will report back asap.


    EDIT 2: Just booted from Linux Live (Ubuntu) and the problem was still there, although a bit better: 30MB/s write. Couldnt use NFS though and had to use SMB/CIFS. For some reason Ubuntu didn't like NFS

    • Offizieller Beitrag

    Strange. I use NFS with Ubuntu all the time. In fact I hardly use anything else to access my NAS from all my Ubuntu clients.


    You may need to install nfs-common in Ubuntu first and then use a NFS specific mount command on the client to access a NFS share on the NAS.


    I doubt things change by themselves. And I suspect that YOU unintentionally changed something or did something, possibly seemingly unrelated, to cause this. Possibly in connection with the USB/SATA interface, the share, the HDD, SMB or the network. That is why a clone of a fresh install could be interesting to restore.


    If the restored clone is fast, then it would suggest that indeed something you did after cloning is the cause.


    I once figured out that changing any of the physical disk properties on the HDD would cause the HDD on a HC2 to stop working normally. But only after a reboot. Until I rebooted everything (almost always) seemed fine. I did perhaps 5 fresh installs and 5 clone restores before I had it confirmed.

  • I think I might look into the USB Blacklisting thing and if that doesn't work I'm moving on.


    My journey has been going on for almost a week now and I'm getting tired of it.
    First, nextcloud: Good GUI and compatibility, excellent read/write speeds but the system (e.g. the whole data structure) is too fragile imho and somehow the CPU started going to 100% all the time because of some infinite loop in a php file and there's no patch besides manually editing the code. I could do that but I don't wanna trust the safety of my data with this kind of system.
    Now OMV, which seems rock solid, with I/O from 1999 (at least in my case, lol).
    I know a DIY NAS comes with a lot of work but this constant searching for the needle in a haystack is making me crazy.
    Will try FreeNAS next.


    Anyhow, I really really appreciate your help! Thanks so much for your answers and taking the time to help me out :)

  • Dumb question: what happens if you turn the system off for a while and then you try again?

    OMV BUILD - MY NAS KILLER - OMV 6.x + omvextrasorg (updated automatically every week)

    NAS Specs: Core i3-8300 - ASRock H370M-ITX/ac - 16GB RAM - Sandisk Ultra Flair 32GB (OMV), 256GB NVME SSD (Docker Apps), Several HDDs (Data) w/ SnapRAID - Fractal Design Node 304 - Be quiet! Pure Power 11 350W


    My all-in-one SnapRAID script!

  • No, no, no, no! That only works for Windows computers.
    I think... X/

    I don't know if you replied with a joke, but I was serious. Maybe the SD was overheating - is the Flash Memory plugin installed?


    @Kaliber45 you could try installing OMV on another media, like a USB stick, and see if it makes a difference.

    OMV BUILD - MY NAS KILLER - OMV 6.x + omvextrasorg (updated automatically every week)

    NAS Specs: Core i3-8300 - ASRock H370M-ITX/ac - 16GB RAM - Sandisk Ultra Flair 32GB (OMV), 256GB NVME SSD (Docker Apps), Several HDDs (Data) w/ SnapRAID - Fractal Design Node 304 - Be quiet! Pure Power 11 350W


    My all-in-one SnapRAID script!

  • I don't know if you replied with a joke, but I was serious. Maybe the SD was overheating - is the Flash Memory plugin installed?
    @Kaliber45 you could try installing OMV on another media, like a USB stick, and see if it makes a difference.

    Tested the "cold" pi (12+ hours off) and the result was the same.
    Just did ANOTHER fresh install of OMV and I get constant 110MB/s write speed (read speed was always good) again. So it can't be the SD Card because it's usually very hot after formatting, writing, installing Armbian Buster etc.


    So the only thing that could possibly have caused this are two settings regarding the HDD (which I didn't make now):
    - Advanced Power Management (although setting it back after the bug occured didnt bring any difference previously)
    - Spindown Time

  • Maybe something fragmenting or an increase in number of files or an increasing log file size.
    On a fresh build try and benchmark the above before and after the speed change.
    Are you somehow initially xfering files to/from hard drive then later to/from sd card?
    Is the speed change gradual or rapid?

  • After another 12 hours of searching, I think I'll officially give up. Still the same issue: Fresh install (just added a user to connect, NOTHING else) -> 110MB/s constant for 24h. But when I reboot the PI -> back to 20MB/s.

    • Offizieller Beitrag

    That the problems appear after a reboot might be significant.


    Perhaps you have applied some changes that degrade performance but does not take effect until you reboot?


    So you could try a fresh install. Check performance. Do nothing. Reboot. Check performance. If performance still is good, then that would indicate that my suspicion is right. If performance after just a reboot is bad it would indicate that I am wrong and the problem is present in OMV or the hardware.


    Make sure you clone the root fs after a fresh install so you can quickly come back to a good working config without wasting time on installing, setting up users and shares and so on.


    Then do whatever additional changes you like, but reboot and test performance after each. Then you should be able to figure out what is the problem. It is what you did between the two latest reboots. Hopefully you only did one small thing.


    This is just a guess. But if it is true, it should be easy, if tedious, to find out if you do as I describe above. Just try to be a little methodical to isolate and narrow down the problem. Simplify. Reduce.


    Do you do something with the physical disk properties? Perhaps to get the HDD to spin down? That could be one problem...

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!