0

I have a ZFS raid with two disks. The homeserver is running 24/7 and the disks too. So I'd like to set them to standby after some idle time. Several posts recommend to test this with the -C param

# hdparm -y /dev/sda

/dev/sda:
 issuing standby command
# hdparm -C /dev/sda

/dev/sda:
 drive state is:  standby
# hdparm -C /dev/sda

/dev/sda:
 drive state is:  standby
# hdparm -C /dev/sda

/dev/sda:
 drive state is:  active/idle

I re-run the hdparm -C /dev/sda command every second. Why the disk got waked up after a few seconds? I stopped all applications accessing those disk (its not the OS disk). And using fatrace I could not find any io operations. And I also tried this kernel workaround followed by reloading the rules, which should avoid waking the disk up by hdparm.

Additionally, I tried smartctl -i -n standby /dev/sda |grep "^Power mode". This seems to wake up the disk on the second run

# hdparm -y /dev/sda

/dev/sda:
 issuing standby command
# smartctl -i -n standby /dev/sda|grep "^Power mode"
# smartctl -i -n standby /dev/sda|grep "^Power mode"
Power mode is:    ACTIVE or IDLE

The /dev/sda disk is a WD Red 8TB:

# smartctl -i /dev/sda
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.41-1-pve] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Red
Device Model:     WDC WD80EFZX-68UW8N0
Serial Number:    xxx
LU WWN Device Id: 5 000cca 263c7a3f7
Firmware Version: 83.H0A83
User Capacity:    8,001,563,222,016 bytes [8.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sat May 30 09:41:56 2020 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

I'm running Proxmox, so it's a debian based distribution with Debian Buster (10).

Edit: Trying hd-idle

I tried hd-idle but the disk went not in standby. Since there were no entries in the logs, I executed it manually with the debug flag

hd-idle -i 0 -a /dev/sda -i 120 -l /var/log/hd-idle.log -d

This showed me increasing reads on every check

probing sda: reads: 12760648, writes: 3174104
probing sda: reads: 12763720, writes: 3174104
probing sda: reads: 12765256, writes: 3174104
probing sda: reads: 12766792, writes: 3174104

I'd expect no reads at all, like described in this blog post (its for the RPI, but I think this is not relevant here). Most of the software runs on Docker containers, so I stopped the daemon but the reads continues. There is currently just one Proxmox VM. It's located on the system SSD, so it couldn't cause reads.

Lion
  • 309
  • 1
  • 4
  • 14
  • 1
    1) A few years ago, Western Digital Green drives had an [extra idle counter](https://wiki.archlinux.org/index.php/Hdparm#Power_management_for_Western_Digital_Green_drives) that would park the head. Possibly your red drive also has additional idle counters. 2) Current Western Digital Red drives have been found out to use Shingled Magnetic Recording (google for the story). This means additional tracks will need to be written if you do other writes. Possibly it wakes up to do those writes. – dirkt May 30 '20 at 10:01

2 Answers2

0

The problem was caused by the pvestatd service: It collects status information like CPU usage, disk usage and other data displayed in the web ui. According to Proxmox, it only applies to storeage configured in /etc/pve/storage.cfg. I hadn't it configured the ZFS pool there any more, but it was there previously. It seems that this make pvestatd still scanning those pool, which wakes up my disks.

To fix this, I need to exclude the devices in /etc/lvm/lvm.conf. There is a filter in global_filter where I applied "r|/dev/sda" for each disk. r means that this disk is excluded from scanning.

After a reboot, the disks went to standby as expected.

Lion
  • 309
  • 1
  • 4
  • 14
-1

ZFS normally does a filesystem sync every 2 seconds. If any information changed since the last time, this causes several write operations.

For this reason, it is common to disable atime updates for Laptops and SSDs via:

zfs set atime=off <datasetname>

Did you try that? It is documented as:

 atime=on | off

     Controls whether the access time for  files  is  updated
     when  they  are  read.  Turning this property off avoids
     producing write  traffic  when  reading  files  and  can
     result in significant performance gains, though it might
     confuse mailers and other similar utilities. The default
     value is on.
schily
  • 18,806
  • 5
  • 38
  • 60
  • I tried that, but it makes no difference. – Lion May 30 '20 at 18:11
  • But I noticed reads on every `hd-idle` check, as I edited in the question. So it seems something reads here, but I can't find out what. I also don't know why we got downvoted. The `atime` seems something that could be a cause of such problems. – Lion May 30 '20 at 18:16
  • Did you disable atime updates for every `zfs` dataset in that pool? Check `zfs list` for all datasets. – schily May 30 '20 at 19:04