HDD Sleep/Spindown/Standby

@ark, thank you for posting the patch. This is pretty much what I did, with a small difference: Instead of making the rootfs writeable, I created an overlay partition to prevent accidentally messing up the middleware.

Create a target for your overlay in a writeable dataset of your choice (e.g. /mnt/tank/overlay/). I use the original path for clarity:

#mkdir -p /mnt/tank/overlay/usr/lib/python3/dist-packages/middlewared/utils/disks_

Copy the middleware file you want to alter to the folder you just created:

#cp /usr/lib/python3/dist-packages/middlewared/utils/disks_/disk_class.py /mnt/tank/overlay/usr/lib/python3/dist-packages/middlewared/utils/disks_

Mount bind it temporarily (until the next restart) to “replace” your write-protected orginal file on your rootfs:

#mount --bind /mnt/tank/overlay/usr/lib/python3/dist-packages/middlewared/utils/disks_/disk_class.py /usr/lib/python3/dist-packages/middlewared/utils/disks_/disk_class.py

Make your edits to the file in your overlay directory (e.g. apply ark’s patch from the post above). Don’t forget this step.

Then restart the middleware to test:

#service middlewared restart

If all is OK, you can mount bind it automatically before the middleware starts by creating an init script under System->Advanced Settings->Init/Shutdown Script. This makes the edits permanent:

Description: disk_class.py overlay
Type: Command
Command: mount --bind /mnt/tank/overlay/usr/lib/python3/dist-packages/middlewared/utils/disks_/disk_class.py /usr/lib/python3/dist-packages/middlewared/utils/disks_/disk_class.py
When: Post Init
Enabled: checked
Timout: 10 (default)

This procedure is a little less dangerous compared to making the whole middleware writeable … and shouldn’t trigger support if you ever need to contact them (but of course, you should disable the overlay on init before making a support request to exclude the possibility of this being a problem).

However, you need to make sure you disable the init script before you update the system or you risk temporarily bricking your middleware. After an update, carefully examine if the file that is to be overlay changed. For example, disk_class.py changed between 25.10-RC1 and 25.10.0.1, so I had to copy the original file to my overlay directory and merge my previous changes to the new file before I could mount bind it again.

2 Likes

Thanks, that is an option yes, and I used to do such stuff on init script but as you said if you forget that enabled and do an update, it may break the middleware next boot.

I rather have it revert to the original behavior if I update it by accident than break stuff.

But regarding disable-rootfs-protection, its name is a bit misleading, it is not as scary as it sounds.

Keeping in mind that TN CORE never had that.

When you run disable-rootfs-protection, what it basically does is remount the base Linux partitions (E.g.: boot-pool/ROOT/25.10.0.1/usr) as read-write allowing root/su to change system files, like any normal Linux install, but it doesn’t make the system files writable to any user.

You still need to be root/su to change system files, and if an attacker gets root/su privilege, then they can remount the system partitions as writable just the same, so running disable-rootfs-protection doesn’t make the OS any more vulnerable to an attacker.

This rootfs-protection is really meant to prevent system admin people with root privileges from changing system files and then opening support tickets on it, because the debug file will flag that and IX’s support team won’t spend time looking at a problem that is not theirs responsibility.

Anyway, yes, the mount/bind method is an option to make this work if one prefers that… until hopefully IX fix this problem for the community users.

In the latest Tech Talk the trunas devs are talking about spindown again:

Q3: SMART errors and drive spindown for spares

The statement here is that “we are welcome to hack it into working” but it is “not something they consider (to support?)” and that “it is not best practice”.

I don’t know if we can expect it to get fixed. Apparently it is at least not important enough to get in 25.10.1.

I think in the long run we can either choose to use the patch presented in this thread or to look for alternatives. Personally I’m thinking of switching to openmediavault. You can often read that it’s worse than unraid or trunas but I don’t really know why. With the plugins it seems like a really powerful system with the stability of Debian and support for ZFS and plenty of other filesystems. The dev also seems to have a lot of experience as a former freenas dev.

2 Likes

Just try to install a plugin and you’ll know why
The “click-apply-confirm-AND-WAIT” on each and every single change is a major pain in the lower back. But skip any step in this silly dance and your docker plugin will not come back at the next reboot. Oops!

Another reason for a small home NAS, like mine, to convert to all SSD pools.

Because of this issue, I’m considering going with vanilla Debian + Samba and Docker. I don’t want to waste power on something I access once a month.

I already have a test system like this — it was built with Debian 11 and now is running Debian 13.

Once I had it working, the way I like it, I experienced far fewer breaking changes than I did with TrueNAS over a similar period.

2 Likes

I had plain Debian installed on my app server which is running around 20 docker containers for quite some time. I also added the cockpit webui with the 45 drives file sharing plugin to manage shares. This worked quite well and may also be worth considering. The cockpit webui was still missing things for me, like being able to setup notifications for e.g. smart errors or updates. So yesterday I switched my app server to openmediavault to give it a test run. For storage I could simple mount my mdraid mirror with it’s btrfs filesystem. Everything seems to work well up to now.

That is not really what we are asking for here (or rather asking to fix, it WAS working)

They are talking about spindown for (hot)spares, not a complete pool

If you look the part of the video I posted starting from 30:38 it becomes clear that they are talking about spindown in general, once because the dev says “we covered this in a previous episode” and once because he says “we generally discourage you from spinning your drives down”. Afterwards you can hear the sentences that I quoted above. But I think we will see it in the future releases how they will handle our use case.

1 Like

Thanks for the explanations, looks like I was too cautious!

I have finally bought a NAS system after a few years of looking for the “perfect hardware”, and now it seems like the “perfect software” may no longer fit my needs :upside_down_face:

Would Unraid be the best option if you want something similar?

I’d really like to have an always on SSD pool, but my HD pool with seldomly used media do not need to waste power and generate noise and heat in the closet.

(I got the Aoostar WTR max in the end)

1 Like

The content of this video is very frustrating for me. The question from the community basically asks “We want to spin down our drives” and their response is “no, you don’t.” No curiosity as to why, no examination of the various scenarios which might cause someone to want to spin down. This kind of decision making is fine, I suppose, if you’re Apple and trying to design a one-size-fits-all user experience, but this is NAS software we’re talking about. Users are technical and have all kinds of different requirements.

Worse still, one could argue that the implementation is broken as is. The UI lets you chose drive power management and push buttons that indicate “drives will spin down” but the software implementation overtly does things behind the scenes that are not controllable (e.g. the aforementioned temp checks etc.) that prevents persistent spindown. So the spindown functionality can reasonably be argued to be broken as is.

My preference would be give the community flexibility to make their own decisions on power management and spindown and make the feature actually work. Second best would at least be to be consistent and clear and really commit to the recommendation of “TrueNAS doesn’t support drive spindown” and remove the feature entirely.

9 Likes

You are over expecting this. This is a professional software, with public availability. They sell hardware for companies, with company needs.

so saying that no spin down is requested is valid.

However, the most critical point here is that they do have an option and documentation specifying the existence of this, made a bug, but are not a knowledging it, and solving the issue.

Either there remove the options completely, and case closed, or not, and they have to solve the bug, especially since we found the solution here.

my guess though, is that the solution will come from HexOS. It is a dedicated home NAS OS, with truenas as a base. So if they want spin down as home customers will request, this will be pushed by them.

If the company runs in Europe, electricity is still very expensive. Spinning down drives at night when no one works would simply save costs. Why shouldn’t a company want that?

4 Likes

I understand your point (I am European as well), and I am concerned by the same point.

But for a company, it will pay 500€ a month instead of 250€ for a server (price is an example) which is nothing for the company, compared to reliable storage, and simple to manage.

You are both right, but keep in mind that there are 2 flavors of TrueNAS… Enterprise and Community Edition.

I get that the Enterprise shouldn’t be bothered with this, spin down does increase mechanical wear and most companies still uses magnetic tape for cold storage… but the Community Edition should serve the needs of the community.

It is even more frustrating knowing that IXSystems is based in California where average cost of electricity is over 0.30 USD/kWh, up to 0.60 in some cases, so they should embrace doing power saving for home users, not brush it off.

2 Likes

I updated to 25.10.1 to see if it made any difference and it didnt so Im back to shutting it down every night, great.

Yes, nothing changed to the related code.

For the people using my patch, you can do the update, reboot, unlock rootfs, reapply the same patch file, then reboot one more time.

“Community Edition” is intended to enroll the community into beta testing to feed the Enterprise release, not to specifically cater to the needs of the community.

1 Like

The official announcement doesn’t say that… Meet TrueNAS Community Edition – The Future of Open Storage

It clearly says “built for the TrueNAS Community“, which would be a very misleading statement in that case.

Anyway, I’m still using TN, I made and shared the changes needed for spin down to work properly when configured as described in the official documentation, just wish they would make these changes official.

2 Likes