Posts by BK-Morpheus

Thanks for the thread. I was stumbling upon the same problem....HDD was waking up for no obvious reason.

I was using HD-IDLE for spindowns as one of my HDDs was simply ignoring HDPARM spindown/APM settings.

HD-IDLE was working fine in my tests (and HD-IDLE service /log was also showing spinups and spindowns correctly), on my old HDD (the one that was ignoring HDPARM and without SMART compatibility).

After changing the old HDD to a newer WD HDD I noticed, that HD-IDLE was only working for a short time (manual accessing the HDD was registered correctly in HD-IDLE log as a spinup and goes back to spindown later) but after a while the HDD wakes up without HD-IDLE showing the spinup status. Therefore HD-IDLE will not attempt another spindown as it thinks the disc is still in spindown mode.

Using HDPARM instead was working better in this case with the WD HDD, as it will send the disc back to sleep after the set amount of spindown time. But still I can see and hear the disc spinning up once in a while without any active access to the HDD from my end.

So in that scenario the discs spins up and down many times per day (30min spindown time) without any accesses to the HDD from me.

Having found and read this thread I checked the SMART service:

sudo service smartd status

It's running and accessing the disk, although left completely disabled in OMV webgui. It seems that any access from smartd is not registered in HD-IDLE and that's why HD-IDLE only initiates a spindown after a fresh boot or a manual access on the share from me.

So I went back into the OMV webgui and after changing Power mode in SMART settings (within OMV webgui) to "Standby" and applying this, while still leaving SMART disabled there, the problem went away.

So it seems SMART is active per default, although OMV webgui shows it disabled. After changing a SMART setting in the webgui and saving this, SMART is now acting as configured in the webgui.

Ah okay, seems rasonable. Main reason for me to post my findings here is to help others that might also have Bullseye on a Pi and run into SMB performance problems with OMV6.

As the bullseye image is the "default" at the moment (both on the Raspberry website download section and in their Pi Imager Tool) and I had just received my Pi4 a few days ago (not doing much Linux or Pi stuff before this), I had OMV6 on my new Pi4 without even knowing that OMV6 is not a final/stable release, just because the OMV installer-script has not asked me or warned me, that the stable version is OMV5 and that it's not compatible with bullseye.

I used this installer script: sudo wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install | sudo bash

On OMV+Bullseye I had the problem that my SMB/CIFS transferspeed was very strange....for testing purposes I only had an old 2.5" USB2 HDD connected which Is limited to around ~28MB/s write and 32MB/s read speed.

With SMB I was able to get ~26MB/s write speed from a Windows 10 computer to the Raspberry running OMV6, but when it comes to copying from the SMB share to the Windows 10 computer, I was stuck at ~15MB/s.

So the tests began...trying to pinpoint why the write speed over SMB was so low.

1. First I tried all those magic "extra parameters" for the SMB share, that can be found all over the forum without any change (and it takes a while to test, because of the cache on Pi+OMV...I needed to let a copy process run for a few seconds until the the Cache was empty/full and the Pi's IO process went to ~100%, than the speed for big files was shown. Of course I tested with "write cache" enabled (but also without just for testing) and with different file systems (NTFS first, then ext4 just to make sure it has nothing to do with NTFS).
2. After no success, I checked the speed between Pi and HDD (running hdparm and dd tests with and without cache) and saw the values that I was expecting on this old external 2.5" USB.2.0 HDD....~28MB/s write speed, 31MB/s read speed. So this was not the problem.
3. Next test: Checking my network performance with iperf between Pi and Windows computer!
   Depending on who was running as client and who was running as server on iperf the results were between 880MBit/s and 975MBit/s so this was fine as well.
4. Enabling FTP and check if this protocol was giving me different performances:
   Write- and read-speed were around 26-30MB/s when using FTP, so it clearly must be a problem with SMB
5. Checking SMB version:
   The connection between my Win10 computer and the Pi was using SMB3.1 so this seemded fine and forcing a lower protocol version via SMB extra parameters in OMV was not solving the problem

After all this I remembered that in a youtube video someone was telling that many people had problems with GPIO or PiCams when they switched from Buster to Bullseye and that those people were kinda angry because bullseye was declared as a "stable" release.

So I switched to the latest "buster" release but other than that installed every thing the same way (still using a lite Image without desktop, writing it to the microSD card with Pi Imager and after updating the packages etc. I used the same OMV installation script from their github.

After this was done I loaded the OMV webgui, logged in and was immediately surprised that the looks of the OMV gui were different. So I checked the OMV version and only at that point I found out that:

• OMV5 is a stable release, OMV6 is not
• the script for OMV isntallation is checking if you run buster or bullsey
• the OMV installation script automatically installs OMV6 when running bullseye (without informing the user that the latest stable OMV is not compatible with the latest stable Raspberry OS or asking if the user would like to proceed with nonstable OMV6 release installation or stop at that point

With buster+OMV5 my SMB performance was fine out of the box with the same USB2 drive....29MB/s write speed, 31-33MB/s read speed.
Also hitting ~75MB/s write speed and 100-110MB/s read speed on and USB3 Sandisk USB stick.

Of course I'm still not 100% sure if the specific SMB read speed problem I had with bullseye+OMV6 was OMV related or a problem with bullseye itself, but as HDparm/DD, iperf and FTP performance was "normal" and only SMB performance was broken, I guess the source of that behavior is more on the OMV6 side of things.

Long story short: I highly recommend bust+OMV5 over bullseye+OMV6 for now when using SMB shares, but you experience may vary.

Maybe the devs could implement some additional lines in their script...I have no real clue on Linux or scripts but it seems like their is a check for bullseye and buster and an error feedback when running something else then Debian10 or Debian11 but no Feedback about what will happen after the script finds a bullseye installation.

A pause with Feedback like

"Debian 11 / Bullseye OS found! OMV5 is not compatible, only OMV6 can be installed but here is no stable release of OMV6 yet. Would you like to stop the script or proceed with nonstable OMV6 Installation instead? Y/N"

would be appreciated from my beginner point of view.

At least when running into issues after proceeding with the OMV6 installation the user knows this is not a stable release and any problems/strange behaviors on OMV might be related to that.