I have been struggling with this problem for years, I have been continuously trying to solve it: I spent quite a few days per year for reading articles, forums, investigating the apps, kernel of QTS etc., of course without success. Currently my QNAP NAS periodically (in every 5 seconds) writes something to the HDDs. Now it is very frustrating for me, so I decided to take a deep breath and try to solve the issue now and forever.
Here I would like to summarize what I found and how I took one step forward in this topic.
Finding the root of the problem
You need to find the problematic process which reads or writes files onto the HDD. I tried everything (iotop, inotify-tools, etc), none of these was the right tool for me, I used block_dump. It is a low level dumper for IO, the result is written into the linux kernel ring buffer, don't worry, as far as I know, it is just a buffer, no files are written during the dump.
1.
Clear the kernel ring bufferdmesg -c
2.
Start the dump, wait for some secondsecho 1 > /proc/sys/vm/block_dump
3.
List the result, you will get something like thisdmesg -c
kworker/u4:0(20597): the process and process id, 1377711520 is the block of the drive which is written (let's name it as X)[42942.425628] kworker/u4:0(20597): WRITE block 1377711520 on dm-0 (8 sectors)
4.
This returns a factor of block sizes (dmesg and debugfs), usually 8. For better understanding please visit this:echo $(( `sudo blockdev --getbsz /dev/dm-0` / 512 ))
https://stackoverflow.com/questions/520 ... -from-vm-b
5. Calculate the debugfs block number using a calculator: Y = X / 8, 1377711520 / 8= 172213940
6.
Start debugfs, and type "open /dev/dm-0". Then type "icheck 172213940", 172213940 is the new block number. This returns this:debugfs
117965700 is the inode number, then type "ncheck 117965700". Result:Block Inode number
172213940 117965700
Yes, we have the file name.Inode Pathname
117965700 /.qpkg/QVPN/qbelt_log/rated.log
7.
The dm-0 logical drive is mounted in /share/CACHEDEV1_DATA, so the full path of the file is: /share/CACHEDEV1_DATA/.qpkg/QVPN/qbelt_log/rated.log.df
Filesystem Size Used Available Use% Mounted on
none 400.0M 302.2M 97.8M 76% /
...
cgroup_root 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/mapper/cachedev1
3.5T 1.9T 1.6T 54% /share/CACHEDEV1_DATA
...
8.
Checking the access/modify/change fields you can see when the file was touched. In my case, it was written every 5 seconds.stat /share/CACHEDEV1_DATA/.qpkg/QVPN/qbelt_log/rated.log
File: /share/CACHEDEV1_DATA/.qpkg/QVPN/qbelt_log/rated.log
Size: 740875 Blocks: 1456 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 117965700 Links: 1
Access: (0666/-rw-rw-rw-) Uid: ( 0/ admin) Gid: ( 0/administrators)
Access: 2022-02-18 12:13:13.000000000
Modify: 2022-02-18 12:16:06.000000000
Change: 2022-02-18 12:16:06.000000000
9. Because this file is related to QVPN, I stopped the QVPN service and restarted from 1
Using this method I found some problems, e.g.:
Service, File
dhclient, /mnt/HDA_ROOT/.config/dhclient/wlan0.leases
Codecs Pack, /share/CACHEDEV1_DATA/.qpkg/CodexPack/sys/bus
ProxyServer, /share/CACHEDEV1_DATA/.qpkg/ProxyServer/opt/sbin/squid
CloudConnector, /share/CACHEDEV1_DATA/.qpkg/HybridBackup/CloudConnector3/lib/libsqlite3.so.0.8.6
Media Library, /share/CACHEDEV1_DATA/.system/log/myidbserver.log
...
After switching off the services above, more or less I managed to put my HDDs into standby mode.
Solving the issues one by one
Of course, we need to use all the services, so my idea is to move the problematic files (usually log files) to a ramdisk, and create a symbolic link from the original location to the ramdisk equivalent. Using this method I managed to solve the issue of dhclient (which writes the /mnt/HDA_ROOT/.config/dhclient/wlan0.leases file periodically). This is the method:
1.
Create a tmpfs ramdisk and mount itmkdir /mnt/ramdisk
mount -t tmpfs -i size=1m tmpfs /mnt/ramdisk/
3.
Copy the file to the ramdiskcd /mnt/ramdisk
mkdir -p /mnt/HDA_ROOT/.config/dhclient/
cd /mnt/ramdisk/mnt/HDA_ROOT/.config/dhclient/
cp /mnt/HDA_ROOT/.config/dhclient/wlan0.leases .
4.
Remove the original file and create the symbolic link.rm /mnt/HDA_ROOT/.config/dhclient/wlan0.lease
ln -s /mnt/ramdisk/mnt/HDA_ROOT/.config/dhclient/wlan0.leases /mnt/HDA_ROOT/.config/dhclient/wlan0.leases
By now the dhclient writes the file in every 4 minutes, not the original file but the other located on the ramdisk. This write does not start the HDD to spin up.
Before I go forward I wanted to share my experiences with you and I'm really interested in your opinion. Could this be a solution for the HDD standby problem in general? Can we, the community collect our experiences and write a script that automatically creates the ramdisk and moves all the problematic files to it with links during startup?