For Synology and QNAP, under normal circumstances, it is impossible to achieve the ideal state of accessing the data of a hard disk, where only the hard disk itself works, while other unrelated hard disks remain in sleep mode. Because by default, both products use raid1 technology to write critical system data to all hard disks at the same time, which will cause all hard disks to wake up when there is reading or writing. The prerequisite for solving this problem is to insert only one hard disk (preferably SSD) when initializing the nas, and then insert other data hard disks after the system is fully installed (so that all apps will only be installed and run on the SSD, so at least the operation of the system and the working factors of these apps will no longer affect other data hard disks.
Secondly, use the mdadm command to process the data hard disk. Because even if the system is installed on the SSD first, when adding data hard disks to the NAS later, Synology and QNAP will still add multiple raid1s to these hard disks to store some key data. Therefore, if you want to hibernate in an ideal state, you need to remove each data hard disk from the raid1. However, due to security considerations, you need to add the hard disk back to each raid1 briefly every day to synchronize data. For details, please refer to the actual steps below.
Note: This article only talks about Synology. Some bloggers have written very detailed tutorials on how to set up QNAP. You can search for it yourself.
First, log in to the Synology system via ssh. I don’t need to explain in detail how to ssh.
Switch to root user after ssh
sudo -iUse Commands
cat /proc/mdstatCheck how many MDs (MD stands for raid1) there are and which hard disks are used. The following picture shows my black Synology:
There are 4 raid0s here: md0, md1, md2, and md3. md0 and md1 use all hard disks, while md3 only uses 4 mechanical hard disks. md2 corresponds to the disk where the system is located. Since we recommended only inserting SSD during initialization, there is only sdf3 here.
Note: In this article, sdf refers to the SSD solid state drive, and 3 refers to the third partition of the solid state drive.
First check md0 and md1, which are similar to qnap's md9 and md13
mdadm -D /dev/md0
As can be seen from the above figure, md0 contains 4 data hard disks, namely sda, sdb, sdc and sdd, plus sdf1. 1 is the serial number of the partitions of each hard disk in this md, and the rest are similar.
mdadm -D /dev/md1
md1 also contains four data hard disks, namely sda2, sdb2, sdc2 and sdd2, plus sdf2.
mdadm -D /dev/md3
md3 only contains 4 data hard disks, namely sda, sdb, sdc and sdd. So our next goal is also clear, which is md0 and md1, because these two raids contain both data disks and system solid-state disks. So if the system reads and writes data, the 4 data disks will inevitably be awakened. Separating the 4 data disks from md0 and md1 is what we have to do next. But for everyone's own Synology system, how to distinguish which are solid-state disks and which are HDD data disks? (Why do I say HDD data disk? The local tyrants use SSD as data disk, and they will directly ask, why do they need to hibernate?) Use
parted /dev/sd(#) printThe command can find out which are HDD data disks and which are SSD hard disks. To achieve the ideal method we mentioned earlier, why do we need to install the system only on SSD? Because the disk where the system is installed must be running all the time and cannot be put to sleep. The others are HDD data disks that need to be put to sleep, so it is a prerequisite to distinguish them clearly.
parted /dev/sdf print
parted /dev/sda print
You can see that my sdf is the system solid state drive, and the other a, d, c, and b are all HDD hard disks, which are our targets. Start the operation. Use the following command to set the corresponding partitions of sda1, sdb1, sdc1, and sdd1 of md0 to fail:
mdadm /dev/md0 -f /dev/sda1 mdadm /dev/md0 -f /dev/sdb1 mdadm /dev/md0 -f /dev/sdc1 mdadm /dev/md0 -f /dev/sdd1Then re-run
mdadm -D /dev/md0
From the above figure, we can see that after running the command, the status of sda1, sdb1, sdc1, and sdd1 are all displayed as faulty. Similarly, perform the same operation on sda2, sdb2, sdc2, and sdd2 of md1:
mdadm /dev/md1 -f /dev/sda2 mdadm /dev/md1 -f /dev/sdb2 mdadm /dev/md1 -f /dev/sdc2 mdadm /dev/md1 -f /dev/sdd2Then re-run
mdadm -D /dev/md1
After running the command, the status of sda2, sdb2, sdc2, and sdd2 are also displayed as faulty
Next, set the 4 hard disks to sleep for 10 minutes respectively:
hdparm -S 120 /dev/sda hdparm -S 120 /dev/sdb hdparm -S 120 /dev/sdc hdparm -S 120 /dev/sddNote: The 120 here does not mean 120 seconds. The -S parameter of the hdparm command specifies the number of 5 seconds, because 120 * 5 = 600 seconds (10 minutes). So running this command requires a simple conversion, which I believe anyone who knows how to use a calculator can do.
After waiting for 10 minutes, check the HDD status to see if it is successful:
hdparm -C /dev/sda | grep state
success!
Here we need to talk about Black and White Synology separately. White Synology is the same as QNAP. Every time you start the computer, all mds will be restored to the initial state. Therefore, every time you shut down and restart the computer, you need to re-run the script to disconnect the HDD hard disk from md0 and md1. The script name is: disconnect_md. At the same time, you need to run the command to put the hard disk to sleep. The script name is: hdd_sleep.sh. Therefore, the recommended practice is to set these two scripts to run automatically at startup. Black Synology is different from White Synology. Restarting will not restore the status of md0 and md1, so you don’t need to run the startup script disconnect_md like White Synology, but you still need to run the script hdd_sleep.sh automatically.
Note: Originally, after -f is detached, there is also -r to delete it directly from the array. However, after my test, I found that as long as -f is detached, the mechanical hard disk can be hibernated, so there is no need to delete it with -r. Moreover, after deleting with -r, I restarted Black Synology and found that the JBOD composed of 4 mechanical hard disks had problems. Therefore, it is dangerous and it is recommended not to delete it.
Considering that the hard disk array status needs to be restored regularly every day so that the system can write system data, regardless of whether it is black or white Synology, the HDD hard disk array status needs to be restored regularly every day so that the system can write data, the script name is: rebulid_md.sh, and then disconnected after a period of time, the script name is: disconnect_md.sh. So here a total of 3 scripts are needed: hdd_sleep.sh, disconnect_md.sh, rebulid_md.sh.
vim /volume1/@userpreference/admin/rebulid_md.sh(Please make sure to confirm the specific path of your nas user) The script content is as follows:
#!/bin/bash echo Re-adding md0 mdadm /dev/md0 --re-add /dev/sda1 mdadm /dev/md0 --re-add /dev/sdb1 mdadm /dev/md0 --re-add / dev/sdc1 mdadm /dev/md0 --re-add /dev/sdd1 echo Re-adding md1 mdadm /dev/md1 --re-add /dev/sda2 mdadm /dev/md1 --re-add /dev/sdb2 mdadm /dev/md1 --re-add /dev/sdc2 mdadm /dev/md1 --re-add /dev/sdd2vim /volume1/@userpreference/admin/disconnect_md.shThe script content is as follows:
#!/bin/bash echo Disconnecting md0 mdadm /dev/md0 --fail /dev/sda1 mdadm /dev/md0 --fail /dev/sdb1 mdadm /dev/md0 --fail /dev/sdc1 mdadm /dev/md0 --fail /dev/sdd1 echo Disconnecting md1 mdadm /dev/md1 --fail /dev/sda2 mdadm /dev/md1 --fail /dev/sdb2 mdadm /dev/md1 --fail /dev/sdc2 mdadm /dev/ md1 --fail /dev/sdd2vim /volume1/@userpreference/admin/hdd_sleep.shThe script content is as follows:
hdparm -S 120 /dev/sda hdparm -S 120 /dev/sdb hdparm -S 120 /dev/sdc hdparm -S 120 /dev/sddDon't forget to give the script execution permissions:
chmod +x /volume1/@userpreference/admin/rebulid_md.sh chmod +x /volume1/@userpreference/admin/disconnect_md.sh chmod +x /volume1/@userpreference/admin/hdd_sleep.shThen run it at a scheduled time every day (I set it to run rebuild_md.sh at 19:30 and disconnect_md.sh at 20:00. You can modify it according to your actual situation):
Similarly, create the disconnect_md.sh script schedule task:
hdd_sleep is a bit different and is a triggered task:
From then on, the mission was accomplished.
I followed the instructions and it was completely successful. With 12 hard drives, the daily standby power consumption was 140W, and after hibernation, the power dropped to 75W. The key is that hibernation can greatly reduce the burden on the hard drives. Thank you for sharing! This is the most detailed and clear tutorial on the entire web, although there is a minor flaw, such as the reminder that the system partition cannot be accessed. I feel that Synology's thinking is very rigid. They can learn from TrueNAS and set up a separate system drive, or let the user choose the boot partition. Enterprise-level products are actually quite concerned about electricity costs.
The ps sleep script seems to have to be run by the root user, and the admin user does not seem to be able to run it.
Yes, you definitely need to root it. However, although I wrote this with the help of BlackSynology, I actually use Qnap (which also does similar things). I spent a lot of time on BlackSynology, but now it is basically useless.
There is another small problem, I don’t know if you have encountered it. My machine always wakes up automatically in the background, that is, it will successfully go into sleep mode, but it will not last long and will wake up.
Did you install the system with only the system disk plugged in when you first installed the system? I remember the article saying that if you install the system with all disks plugged in, it's like there's system code on each disk, and it will definitely wake up automatically at any time.
The HDD was not plugged in during installation. I just plugged in a new HDD yesterday, and when I installed the system, there were two virtual hard drives. This confused me. Now I can't log in to SSH at work. I will check the wake-up log in detail when I go back.
Boss, I have another small question. Why does the rebuild_md.sh script prompt me when I execute it now:
bash /volume1/@userpreference/admin/rebulid_md.sh
Re-adding md0
mdadm: –re-add for /dev/sata1p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata2p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata3p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata4p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata5p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata6p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata7p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata8p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata9p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata10p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata11p1 to /dev/md0 is not possible
mdadm: –re-add for /dev/sata12p1 to /dev/md0 is not possible
Re-adding md1
mdadm: –re-add for /dev/sata1p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata2p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata3p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata4p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata5p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata6p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata7p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata8p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata9p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata10p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata11p2 to /dev/md1 is not possible
mdadm: –re-add for /dev/sata12p2 to /dev/md1 is not possible
All of this is not possible. The permissions are set, but the system partition can be repaired and restored in the system point. Is this a secret modification of the system?
Your device path is a bit strange, it's all "/dev/sataxp?", mine is normally in the form of "/dev/sdx". You mentioned a virtual disk before, is there any problem in this regard?
I don't know why,
cat /proc/mdstatThe device path viewed by the command is sataX. I guess it’s because I’m using pve virtual machine passthrough. But this shouldn’t be important. It can currently sleep. At worst, I just need to manually synchronize the array data every day.I also have QNAP and Synology White, QNAP hddstandby is very mature. White skirt is not perfect, timed on and off.
The white group isn’t perfect either, I thought it was just a black group, luckily my main player is QNAP.
The blogger's method is very good, but it will cause the storage to prompt that the system partition cannot be accessed. Is there any way to block this?
Indeed, I will get a prompt as well. In fact, I usually use QNAP as my main computer, and after similar operations, it can sleep normally without any prompt. I wrote this article because I saw that no one in Synology seemed to have written this at the time. However, I only have the black Synology, and QNAP is not quite the same as the black Synology I have when booting. I am not sure if it is a problem with the black Synology, and I am not sure if there is this problem on the white Synology. In addition, it is not the main computer that needs to be turned on 24 hours a day, so I did not spend energy to study it. I can confirm that it does not affect the use, but it looks a bit uncomfortable.