Yeah, I was skeptical about the data as I said, if you believe the reporting system. 44GB/Day on some cheapie boot drives, they should have died long ago.
There are lot of question regarding the write to pool in each 5 seconds.
I was getting used to sleep with this noise then I upgraded to 24.10.0.2 and now there is a silence. Actually I don’t know what is going on, why this silece. No errors, zpool looks OK, but this is really frustrating as this was not announced. Also so much people and so long time are asking the 5 seconds write and sharfing urban legends and wizard tricks about how to “fix” it (move logt to SSD, disable k3b etc.) that this should have been in the official documentation for 10 years.
Something is matching with a magic: someone wrote todisable k3b/kubernetes. I have just found this:
"The TrueNAS feature backend moves from Kubernetes to Docker to streamline App deployment and management "
This is more or less the same like one of the idea I read. And it is integrated into the TrueNAS.
Any idea why we no longer have the 5 seconds write to the disks?
If needed, I can give you a script to restore the “k3s-style random writes to the pool” feature.
You may also notice the “inexplicable high CPU usage when simply enabling apps” feature is also missing if you were planning to rely on it to heat your house during the winter.
7 Likes
Actually I did not know if something went wrong during upgrade or just fixed a 10+ years issue.
Instead of the “k3-style random writes to the pool” script have you already found article about this that describe this is now fixed and also need to find another heating for the house? 
I would read about that…
1 Like
And many thanks for your answer.
1 Like
5 seconds is a transaction group. At at the very least logging to the system dataset could be responsible for regular writes even if the NAS is not actively serving or receiving data. So placing the system dataset on SSD allows the HDDs to remain quiet.
@etorix Yes I read this solution too and as far as I remember I attempted to implement it but disk writes remained.
Now the only thing I did is to update the TrueNAS scale to 24.10.0.2.
Maybe the update moved the system dataset to SSD?
(I use Proxmox virtualization which is running from SSD. TrueNAS is running as guest (image is from that SSD). I configured some PCI passthrough devices: HDD controller (conencted to 4 HDDs), 2.5Gbps NW card, NVMe SSD + interface card for that). So technically it is possible to move system dataset to the disk image of the TrueNAS which is located on the SSD of Proxmox)
Also I remember I attempted to check Applicaitons as a few “built in” was installed. I thought it is related to the TrueNAS scale itself as it was using names that was similar to the features that TrueNAS can use. Now in the applications menu if I go to configuration then I should chose the pool. Maybe this is the explanation as I no longer have applications (I did not have only system related ones)
If it’s not clear, Docker is a far more efficient way to run apps than Kubernetes. This results in less continuous writes and lower idle CPU usage.
24.10 Electric Eel switches the app’s system from Kubernetes to Docker.
I am having the exact same issue now, however, it only appeared after I attempted to run a single VM in ElectricEel-24.10.2.
We’re now seeing about 300-600 KiB/s in writes to the boot-pool. I moved the system dataset, which was not on the boot-pool at the time, to the boot-pool and then back off of it before rebooting to see if that fixed the issue. Without a reboot, this did not change the write behavior.
It appears that after deleting the VM and moving the boot-pool around (not sure if necessary) and that final reboot “fixed” the issue. We’re now seeing abnormal writes to the pool that houses the system-dataset but at least it’s not trying to write 10TB or something per year to a boot-pool ssd. This level of writes is preventing the system to enter a low power state for extended periods of time.
Is this a known issue with ElectricEel-24.10.2?