Removing power from idle hard drives via IO pin and FET from the kernel?

[cedric!]

I'm building a NAS. It contains large hard drives, with smaller SSD's as read/write cache in front of them. [1] The hard drives only spin up when the write cache is full, or when a read request comes in that's not in the cache. This results in the hard drives being almost always spun down. I use older drives, that use 10W while spinning, and about 1 watt while being idle.

I would like to completely remove the power from the idle harddrives, and power them back up when they are needed again. I'm thinking about using smart fets [2,3] for this, controlled by output pins on my single board computer (rockpi-3A)

Can the Linux kernel be configured to raise an IO pin when a harddrive must spin up, and lower the pin again after the drive has returned to idle?
Can the Linux kernel be configured to deal with suddenly appearing drives just after they receive power?
What's the best community to ask for guidance on writing a linux driver that does this?

My hardware:
RockPi 3A version 1.31 running Armbian https://wiki.radxa.com/Rock3/3a
M.2 e-key to PCIE+USB adapter: https://nl.aliexpress.com/item/32998283993.html 12
PCI-E to sata bridge: https://nl.aliexpress.com/item/1005003060227206.html 5
4 sata hard drives and 4 sata ssd's connected to the PCI-E to sata bridge

References:
[1] arch linux bcache: https://wiki.archlinux.org/title/Bcache#Situation:_3_hard_drives_and_3_read/write_cache_SSD's
[2] high side switch: https://nl.farnell.com/on-semiconductor/fdc6330l/ic-mosfet-dual-np-supersot-6-6/dp/9844864
[3] high side switch: https://nl.farnell.com/infineon/bts50902ekaxuma1/power-load-sw-aec-q100-13-5v-soic/dp/2709907

[Berni]

Both linux and windows can handle a HDD disappearing and showing up again.

The whole trick behind it is that the SATA port must support hotplug. Most modern motherboards support that, but usually needs to be turned on in the BIOS. Once that is on, you can just plug a drive into SATA and it simply shows up. Tho on linux it might not automatically mount the filesystem when the drive shows up, but there are ways to make that automatic too.

Getting the linux kernel to automatically spin them up tho might be tricky since once you disconnect the drive, the filesystem will also unmount. So there is nothing to access at that point if the filesystem is not there. You also have to be careful disconnecting the drives as linux might not have flushed all the data in RAM buffers down onto the disk. You have to gracefully unmounted the filesystem or at least manually tell it to sync before cutting power to a HDD.

Id say first try to manually do it by unplugging disks live then plug them in again, seeing if your SSD caching solution can handle the drives disappearing at all.

If that works then id say find out a way to check how full the SSD cache is, then have a script running in the background that powers on the drives every few days or when the SSD write cache is full so that you can flush data down to HDDs.

But in my opinion id say don't bother. The couple of watts you might save is not worth the effort. Even after the energy prices going trough the roof due to the world situation we still get 0.15€ per kWh. So 1W per year costs 1.30€. So if i calculate the cost of my man hours required to get this power saving thing to work, it is cheaper to just pay for the power cost to run it.

[magic]

In Linux you will need to unmount the filesystem before powering down and then mount it after powering back up. There is no way of knowing that the disk that re-appears is the same disk which disappeared and that it hasn't been modified on other machine in the meantime. If you simply power cycle a disk with a mounted filesystem on it, a "phantom" device associated with the old disk will remain in the system, it will remain mounted, and the filesystem will I/O error on every operation other than unmounting. It will not be automatically switched over to the newly connected disk, even if it's the same disk.

I highly recommend using "native" HDD power saving features instead, such as standby on command or after a preset time of inactivity. Consider the hdparm utility and -y, -Y, -S options in particular. These features spin the disk down, saving a majority of its power, but they keep the electronics powered up maintaining connection so Linux knows that it is still the same disk being there all the time. Filesystems can stay mounted and as soon as any access is made, the disk will be automatically woken up from standby as if nothing happened. The access will only need to wait a few seconds for the disk to spin up.

[DiTBho]

disk cache on both disk and linux needs to be flushed

[dobsonr741]

Are you equipped to write kernel mods, compile and test them? To deploy them again and again as the OS updates coming in? And test again. With your live NAS containing g all your data. Would you trust your data on a system concept (power to to NS drives) no one else in the NAS scene produced? Just asking, IMO it’s a high risk to your data, and the data is presumably you care about.

[magic]

Yes, any kernel solution would likely be a PITA to develop and more PITA to maintain long term.

After re-reading the OP I realized that you actually know about the power saving modes and want to eliminate that one last watt. Well, in such case I would start with checking if there is any difference between the "standby" and "sleep" modes. If neither is good enough, maybe try to develop a userspace based solution: monitor the disks for I/O, unmount any relevant filesystems, command the disks to spin down with hdparm, then toggle the GPIO to cut power. You will need some way of knowing when they are needed back, then undo all the steps in reverse order.

[cedric!]

Are you equipped to write kernel mods, compile and test them? To deploy them again and again as the OS updates coming in? And test again. With your live NAS containing g all your data. Would you trust your data on a system concept (power to to NS drives) no one else in the NAS scene produced? Just asking, IMO it’s a high risk to your data, and the data is presumably you care about.

I would love to go on that journey. Of course I understand I'm at high risk of data loss, so I will make sure I have backups (including having tested the backups are good), and I will not conduct the (first) tests on my system with the valuable data.

I wonder if I'm the first one with this idea, and I wonder how many changes to the Linux kernel are needed.
Also, I am aware the power savings are only one watt per drive, but I am planning on using a lot of them. (That's why I use a card that can drive 20 of them)

[DiTBho]

I wonder if I'm the first one with this idea

for me no, because it's not worth it in term of ratio watt-saved / complexity (and limitations) added.

For me, the best solution is
- application userspace, monitoring disks
- when disks not in use, issue commands via SMART to powerdown the motor
- don't touch disk cache at all, so don't unmount anything

it's not easy to understand when disks are actually not in use as it depends on the filesystem policy,and filesystem implementation.

[DiTBho]

my NAS has a different strategy:

• consists of 3 SBCs
• SBC#0 is a very low power SBC without any disks. It boots from flash and spends time monitoring the lan for incoming requests; if so, it wakes up the second SBC. Also periodically wakes up SBC#2
• SBC#1 bootstraps from flash and mounts 6 disks in RAID5 with minimal services { ssh, sshfs, samba, NFS }
  
• SBC#2 is connected to backup devices { disks, tapes }, and has a privileged 10GBps connection to SBC#1. It is usually off except on weekends when backups are scheduled
• SBC#0 monitors SBC#1 and SBC#2, after 45 minutes of inactivity, SBC#0 issues a selective shutdown command
• SBC#1 boots, mounts disks, and launches services in 106 seconds
• SBC#2 boots, mounts devices, and launches services in 41 seconds

[SiliconWizard]

I highly recommend using "native" HDD power saving features instead, such as standby on command or after a preset time of inactivity.

Yes.

The OP may want to read this though: https://superuser.com/questions/925847/demystifying-sata-hotplug
Beware, this is a rabbit hole.

[Nominal Animal]

I use older drives, that use 10W while spinning, and about 1 watt while being idle.

These old drives have four states: active, idle, standby, and sleep.
You can use hdparm -y /dev/device to put the drive to standby, and hdparm -Y /dev/device to put it into sleep.  Have you checked the power consumption when in standby or asleep?  When asleep, the power use should be basically zero, since very little of the drive logic (and not motor) is powered.

The Linux kernel will automatically soft-reset the drive when needed, raising it from sleep (or standby, of course).

You can use hdparm and smartctl (from smartmontools package; use it!) to control the actual timeouts on each spinny-rust drive.

To add quirks to the Linux ASMedia AHCI SATA driver, drivers/ata/achi.c isn't really the problem; the problem is determining exactly when it is okay to turn off the power to the drive, because the darn things have internal caches and such.  I'm not convinced it is worth the hassle.

[Berni]

my NAS has a different strategy:

• consists of 3 SBCs
• SBC#0 is a very low power SBC without any disks. It boots from flash and spends time monitoring the lan for incoming requests; if so, it wakes up the second SBC. Also periodically wakes up SBC#2
• SBC#1 bootstraps from flash and mounts 6 disks in RAID5 with minimal services { ssh, sshfs, samba, NFS }
  
• SBC#2 is connected to backup devices { disks, tapes }, and has a privileged 10GBps connection to SBC#1. It is usually off except on weekends when backups are scheduled
• SBC#0 monitors SBC#1 and SBC#2, after 45 minutes of inactivity, SBC#0 issues a selective shutdown command
• SBC#1 boots, mounts disks, and launches services in 106 seconds
• SBC#2 boots, mounts devices, and launches services in 41 seconds

That is a nice strategy.
So SBC#0 is not actually serving up anything, just spying on LAN traffic that shows someone trying to access SBC#1?


My own storage solution is a NAS in the form of a x86 PC running Unraid. Not the most power efficient solution but you can get down to 20W when doing nothing (has about 100TB of storage). But it is still not that much power, so i don't really care. The NAS server cost many many times more than the power required to run it. Heck my Unraid license cost more than this NAS will burn in power for a handful of years.

Tho a tiny SBC based NAS might be a good idea to introduce at some point as a place to backup the real one every so often automatically. (Right now i just have the most important data manually backed up on some USB HDDs)

[DiTBho]

Have you checked the power consumption when in standby or asleep?  When asleep, the power use should be basically zero, since very little of the drive logic (and not motor) is powered.

Measuring my Seagate Barracuda sATA 500GB disks (~2010), they consome ~50mA x 5V, and ~0.1mA x 12V when asleep, I think recent ones consume less electricity 

[magic]

The OP may want to read this though: https://superuser.com/questions/925847/demystifying-sata-hotplug
Beware, this is a rabbit hole.

SATA hotpulg is nobrainer. I use it all the time on consumer hardware, never had a slightest issue.

As they say, you need to hot(un)plug the SATA connector, not MOLEX (if using an adapter). SATA power connectors and disks are designed to properly sequence supply rails and avoid large inrush currents.
(Dis)connecting power or data first makes no difference. Some connectors combine these two, also no problem.
Unmount everything before hot removing, obviously.

I'm pedantic so I also spin down the disk before disconnection. Spinners cope with sudden loss of power by using the motor as generator to obtain emergency power for proper parking of the heads, but it's easy enough to shut them down orderly in advance. Linux does it too when powering down the whole system.

I use this, which also immediately logically removes the disk from Linux. Not 100% sure but I think it may also error out if the disk is in use (such as mounted), giving you a warning, unlike simply pulling the cable right away.

Code: [Select]

echo 1 >/sys/block/sdx/device/delete

[DiTBho]

So SBC#0 is not actually serving up anything, just spying on LAN traffic that shows someone trying to access SBC#1?

precisely 

[magic]

The OP may want to read this though: https://superuser.com/questions/925847/demystifying-sata-hotplug

Yeah, definitely.

Molex conectors are not designed for hot-plug, hot-remove, hot-swap... they cause electrical peaks.

P.D.: On some molex pins, the current that is passing can be more than 3.5A, that can kill a person (not common, but it can), the voltage (12V) is not what kill people, it is the amperage (>0.3A can kill, no matter the voltage, it is the ampetage what kills).

Remember kids, never hotplug MOLEX connectors. The inrush current may kill you. Not often, but it may