Disk spin down in OMV.

Hi

I upgraded from OMV 4 to OMV5 some time ago using the community provided script. This all seemed to work ok, but since then my hard drives never spin down. I'm sure before the upgrade they used to. I don't want to actually spin down all my drives, just my USB external drives that I use for SnapRAID Parity and general data backup.

I tried the hd-idle installation that has been posted in the guides section of this forum.

This has not helped, but the log has shown me that approx every 1 minute the disks get written to, and this is why they don't ever sleep.

In the hd-idle log I get this sort of thing:

Jan 23 18:33:26 svr-nas-001 hd-idle[6585]: disk=sdb command=ata spunDown=false reads=3551960 writes=3336326 idleTime=1200 idleDuration=0 spindown=0001-01-01T00:00:00 spinup=2021-01-23T17:44:13 lastIO=2021-01-23T18:33:26
Jan 23 18:33:26 svr-nas-001 hd-idle[6585]: disk=sdd command=ata spunDown=false reads=1118967 writes=11560 idleTime=1200 idleDuration=0 spindown=0001-01-01T00:00:00 spinup=2021-01-23T17:44:13 lastIO=2021-01-23T18:33:26
Jan 23 18:33:26 svr-nas-001 hd-idle[6585]: disk=sdc command=ata spunDown=false reads=882345 writes=11374 idleTime=1200 idleDuration=0 spindown=0001-01-01T00:00:00 spinup=2021-01-23T17:44:13 lastIO=2021-01-23T18:33:26
Jan 23 18:33:26 svr-nas-001 hd-idle[6585]: disk=sda command=ata spunDown=false reads=7805837 writes=14767371 idleTime=0 idleDuration=1 spindown=0001-01-01T00:00:00 spinup=2021-01-23T17:44:13 lastIO=2021-01-23T18:33:25
Jan 23 18:33:26 svr-nas-001 hd-idle[6585]: disk=sde command=ata spunDown=false reads=89717 writes=5874 idleTime=1200 idleDuration=59 spindown=0001-01-01T00:00:00 spinup=2021-01-23T17:44:13 lastIO=2021-01-23T18:32:27
Jan 23 18:33:26 svr-nas-001 hd-idle[6585]: disk=sdf command=ata spunDown=false reads=1086374 writes=33610 idleTime=1200 idleDuration=59 spindown=0001-01-01T00:00:00 spinup=2021-01-23T17:44:13 lastIO=2021-01-23T18:32:27
Jan 23 18:33:26 svr-nas-001 hd-idle[6585]: disk=sdg command=scsi spunDown=false reads=93551 writes=2370 idleTime=0 idleDuration=58 spindown=0001-01-01T00:00:00 spinup=2021-01-23T17:44:13 lastIO=2021-01-23T18:32:28
Jan 23 18:33:26 svr-nas-001 hd-idle[6585]: disk=sdh command=scsi spunDown=false reads=432010 writes=1124 idleTime=0 idleDuration=58 spindown=0001-01-01T00:00:00 spinup=2021-01-23T17:44:13 lastIO=2021-01-23T18:32:28

Then this. i.e. They all get written to around the same time (60 seconds) and their idle duration reverts to 0:

Jan 23 18:33:27 svr-nas-001 hd-idle[6585]: disk=sdb command=ata spunDown=false reads=3551960 writes=3336326 idleTime=1200 idleDuration=1 spindown=0001-01-01T00:00:00 spinup=2021-01-23T17:44:13 lastIO=2021-01-23T18:33:26
Jan 23 18:33:27 svr-nas-001 hd-idle[6585]: disk=sdd command=ata spunDown=false reads=1118974 writes=11560 idleTime=1200 idleDuration=0 spindown=0001-01-01T00:00:00 spinup=2021-01-23T17:44:13 lastIO=2021-01-23T18:33:27
Jan 23 18:33:27 svr-nas-001 hd-idle[6585]: disk=sdc command=ata spunDown=false reads=882345 writes=11374 idleTime=1200 idleDuration=1 spindown=0001-01-01T00:00:00 spinup=2021-01-23T17:44:13 lastIO=2021-01-23T18:33:26
Jan 23 18:33:27 svr-nas-001 hd-idle[6585]: disk=sda command=ata spunDown=false reads=7805837 writes=14767371 idleTime=0 idleDuration=2 spindown=0001-01-01T00:00:00 spinup=2021-01-23T17:44:13 lastIO=2021-01-23T18:33:25
Jan 23 18:33:27 svr-nas-001 hd-idle[6585]: disk=sde command=ata spunDown=false reads=89736 writes=5878 idleTime=1200 idleDuration=0 spindown=0001-01-01T00:00:00 spinup=2021-01-23T17:44:13 lastIO=2021-01-23T18:33:27
Jan 23 18:33:27 svr-nas-001 hd-idle[6585]: disk=sdf command=ata spunDown=false reads=1086393 writes=33614 idleTime=1200 idleDuration=0 spindown=0001-01-01T00:00:00 spinup=2021-01-23T17:44:13 lastIO=2021-01-23T18:33:27
Jan 23 18:33:27 svr-nas-001 hd-idle[6585]: disk=sdg command=scsi spunDown=false reads=93569 writes=2374 idleTime=0 idleDuration=0 spindown=0001-01-01T00:00:00 spinup=2021-01-23T17:44:13 lastIO=2021-01-23T18:33:27
Jan 23 18:33:27 svr-nas-001 hd-idle[6585]: disk=sdh command=scsi spunDown=false reads=432010 writes=1124 idleTime=0 idleDuration=59 spindown=0001-01-01T00:00:00 spinup=2021-01-23T17:44:13 lastIO=2021-01-23T18:32:28

My setup is 4 X ata disks in Snapraid/Unionfs. 1 X ata disk as standalone. 2 X external USB drives (for backup & snapraid parity).

Seems like there is something writing but have no idea what this is.

I'm tempted to setup a new copy of OMV 5 from fresh and try that as I use docker-compose so wouldn't be a massive task, but would probably end up being a few hours messing around!

So just wondered if anyone has any ideas what could be writing to all the disks every 60 seconds or so? I've switched everything pff (schedules, SMART, monitoring etc) and tried shutting down my docker containers. Nothing seems to help!

TIA!

Will.

Thank you very much. Had a look and that looked like it would be just the ticket. At the time of the write and the idle duration resetting, I seem to have these writes (snipped from the larger logging), so nothing that is actually on all disks. These are system disk writes:

09:19:01.465886 rsyslogd(751): W /var/log/daemon.log

09:19:01.465886 tail(22516): R /var/log/syslog

09:19:01.466406 rsyslogd(751): W /var/log/syslog

09:19:01.466406 rsyslogd(751): W /var/log/daemon.log

09:19:01.466406 tail(22516): R /var/log/syslog

09:19:01.466785 rsyslogd(751): W /var/log/syslog

09:19:01.466785 rsyslogd(751): W /var/log/daemon.log

09:19:01.466785 tail(22516): R /var/log/syslog

09:19:01.467138 rsyslogd(751): W /var/log/syslog

09:19:01.467269 rsyslogd(751): W /var/log/daemon.log

09:19:01.467269 tail(22516): R /var/log/syslog

09:19:01.467575 rsyslogd(751): W /var/log/syslog

09:19:01.467575 rsyslogd(751): W /var/log/daemon.log

09:19:01.467575 tail(22516): R /var/log/syslog

09:19:01.468007 rsyslogd(751): W /var/log/syslog

09:19:01.468007 rsyslogd(751): W /var/log/daemon.log

09:19:01.468007 tail(22516): R /var/log/syslog

09:19:01.468366 rsyslogd(751): W /var/log/syslog

09:19:01.468366 rsyslogd(751): W /var/log/daemon.log

09:19:01.468366 tail(22516): R /var/log/syslog

09:19:01.468728 rsyslogd(751): W /var/log/syslog

09:19:01.468728 rsyslogd(751): W /var/log/daemon.log

09:19:01.634782 nginx(1103): W /var/log/nginx/openmediavault-webgui_access.log

09:19:01.727149 php-fpm7.3(22560): CW /var/lib/php/sessions/sess_lc508gsqhu9qv0s1ui3981825e

09:19:02.020970 php-fpm7.3(22560): CW /var/lib/php/sessions/sess_lc508gsqhu9qv0s1ui3981825e

09:19:02.159343 nginx(1103): W /var/log/nginx/openmediavault-webgui_access.log

09:19:02.229399 php-fpm7.3(22560): CW /var/lib/php/sessions/sess_lc508gsqhu9qv0s1ui3981825e

09:19:02.341083 nginx(1103): W /var/log/nginx/openmediavault-webgui_access.log

09:19:02.403795 php-fpm7.3(22560): CW /var/lib/php/sessions/sess_lc508gsqhu9qv0s1ui3981825e

09:19:02.465663 rsyslogd(751): W /var/log/syslog

09:19:02.465663 rsyslogd(751): W /var/log/daemon.log

09:19:02.465663 tail(22516): R /var/log/syslog

09:19:02.465778 rsyslogd(751): W /var/log/syslog

09:19:02.465778 rsyslogd(751): W /var/log/daemon.log

09:19:02.465877 tail(22516): R /var/log/syslog

09:19:02.465973 rsyslogd(751): W /var/log/syslog

09:19:02.465973 rsyslogd(751): W /var/log/daemon.log

09:19:02.466048 rsyslogd(751): W /var/log/syslog

09:19:02.466086 rsyslogd(751): W /var/log/daemon.log

09:19:02.487947 nginx(1103): W /var/log/nginx/openmediavault-webgui_access.log

And it's odd because one of the writes is onto the external USB disk that is used for SnapRAID parity. There is nothing much on there apart from the parity file. This is acutally the newest file, so this all makes no sense!

Thank you for your suggestion anyway, but looks like I will need to continue looking! It's not the end of the world but it's bugging me for sure now!

Thanks

Will

Still nothing useful. If I look at a disk that is being written to, it's not get reported. i.e I get this sort of thing.

15:17:00.251743 df(2586): O /srv/dev-disk-by-label-GENERALBACKUP
15:17:00.251918 df(2586): C /srv/dev-disk-by-label-GENERALBACKUP
15:17:17.212013 df(2834): CO /srv/dev-disk-by-label-GENERALBACKUP
15:17:33.543599 df(3126): CO /srv/dev-disk-by-label-GENERALBACKUP
15:17:49.464620 df(3346): O /srv/dev-disk-by-label-GENERALBACKUP
15:17:49.464755 df(3346): C /srv/dev-disk-by-label-GENERALBACKUP
15:17:59.825232 df(3602): CO /srv/dev-disk-by-label-GENERALBACKUP
15:18:00.266880 df(3772): CO /srv/dev-disk-by-label-GENERALBACKUP
15:18:09.841303 df(3990): CO /srv/dev-disk-by-label-GENERALBACKUP
15:18:19.852167 df(4193): CO /srv/dev-disk-by-label-GENERALBACKUP
15:18:29.862310 df(4391): CO /srv/dev-disk-by-label-GENERALBACKUP
15:19:00.215463 df(4614): O /srv/dev-disk-by-label-GENERALBACKUP
15:19:00.215609 df(4614): C /srv/dev-disk-by-label-GENERALBACKUP
15:20:00.301648 df(4917): O /srv/dev-disk-by-label-GENERALBACKUP
15:20:00.301802 df(4917): C /srv/dev-disk-by-label-GENERALBACKUP
15:21:00.283907 df(5230): O /srv/dev-disk-by-label-GENERALBACKUP
15:21:00.284177 df(5230): C /srv/dev-disk-by-label-GENERALBACKUP
15:22:00.262209 df(5541): CO /srv/dev-disk-by-label-GENERALBACKUP
15:23:00.232072 df(5854): O /srv/dev-disk-by-label-GENERALBACKUP
15:23:00.232319 df(5854): C /srv/dev-disk-by-label-GENERALBACKUP
15:24:00.245614 df(6153): CO /srv/dev-disk-by-label-GENERALBACKUP
15:25:00.325773 df(6480): O /srv/dev-disk-by-label-GENERALBACKUP
15:25:00.326041 df(6480): C /srv/dev-disk-by-label-GENERALBACKUP
15:26:00.260343 df(6840): O /srv/dev-disk-by-label-GENERALBACKUP
15:26:00.260343 df(6840): C /srv/dev-disk-by-label-GENERALBACKUP

So a disk space command being run against the disk but nothing to suggest an actual write.

Ah well, back to the drawing board. Thanks for your suggestions macom

Will.

Although thinking about it, a open and close will trigger the disk to wake of course! Mmmm.. I wonder what could be doing this!

So I've been looking at this.

1) I've found (as per above)... There is a regular df running (disk space usage) which opens and closes the disk mount point/location.

2) Looking at the hd-idle log, it appears that approx every 60 seconds, all disks have their 'idle' time reverted to 0.

3) Looking in the system information/report section on the OMV front end, there appears to be disk information reporting that is refreshed every 1 minute or so (and around the same time hd-idle is reverting to an idle time of 0).

Therefore I think whatever is running to report disk information is resetting my idle time!

i.e. In the OMV system information/report, there is this sort of thing. This being a snippet of some disk information:

Filesystem 'filesystem_srv_dev-disk-by-label-DATADISK4'
status OK
monitoring status Monitored
monitoring mode active
on reboot start
filesystem type ext4
filesystem flags rw,noexec,relatime,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group
permission 755
uid 0
gid 0
block size 4 kB
space total 3.6 TB (of which 0.0% is reserved for root user)
space free for non superuser 1014.0 GB [27.7%]
space free total 1014.0 GB [27.7%]
inodes total 244195328
inodes free 244179299 [100.0%]
read 0 B/s [2.6 TB total], 0.0 reads/s [11315889 reads total]
write 0 B/s [86.5 GB total], 0.0 writes/s [171689 writes total]
service time 0.000ms/operation (of which read 0.000ms, write 0.000ms)
data collected Thu, 28 Jan 2021 21:23:02

Program 'mountpoint_srv_dev-disk-by-label-DATADISK4'
status OK
monitoring status Monitored
monitoring mode active
on reboot start
last exit value 0
last output /srv/dev-disk-by-label-DATADISK4 is a mountpoint
data collected Thu, 28 Jan 2021 21:23:02

Filesystem 'filesystem_srv_dev-disk-by-label-GENERALDISK1'
status OK
monitoring status Monitored
monitoring mode active
on reboot start
filesystem type ext4
filesystem flags rw,noexec,relatime,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group
permission 755
uid 0
gid 0
block size 4 kB
space total 1.8 TB (of which 0.0% is reserved for root user)
space free for non superuser 1.6 TB [90.6%]
space free total 1.6 TB [90.6%]
inodes total 122101760
inodes free 121944586 [99.9%]
read 0 B/s [489.5 MB total], 0.0 reads/s [84266 reads total]
write 0 B/s [125.0 MB total], 0.0 writes/s [2722 writes total]
service time 0.000ms/operation (of which read 0.000ms, write 0.000ms)
data collected Thu, 28 Jan 2021 21:23:02

Program 'mountpoint_srv_dev-disk-by-label-GENERALDISK1'
status OK
monitoring status Monitored
monitoring mode active
on reboot start
last exit value 0
last output /srv/dev-disk-by-label-GENERALDISK1 is a mountpoint
data collected Thu, 28 Jan 2021 21:23:02

Filesystem 'filesystem_srv_dev-disk-by-label-GENERALBACKUP'
status OK
monitoring status Monitored
monitoring mode active
on reboot start
filesystem type fuseblk
filesystem flags rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096
permission 777
uid 0
gid 0
block size 4 kB
space total 5.5 TB (of which 0.0% is reserved for root user)
space free for non superuser 5.2 TB [95.5%]
space free total 5.2 TB [95.5%]
inodes total 5596869120
inodes free 5596701863 [100.0%]
read 0 B/s [969.4 MB total], 0.0 reads/s [54357 reads total]
write 0 B/s [6.5 MB total], 0.0 writes/s [35 writes total]
service time 0.000ms/operation (of which read 0.000ms, write 0.000ms)
data collected Thu, 28 Jan 2021 21:23:02

So what could OMV be using to 'snap' this disk information? Is it 'collectd'? I've switched off 'monitoring' in the OMV GUI... As can be seen the 'data collected' time is all the same. This changes every minute or so and doesn't seem to get refreshed when hitting 'refresh' in the information section in the OMV GUI.

Thanks for any help...

Will

Zitat von macom

Two things that came to my mind:

Do you have SMART enabled? Check the poll intervall and the power mode.

Do you have the browser open with GUI? AFAIK have the file system on the dashboard or opening the filesystem view will wake up your drives.

Thank you macom. Your suggestions pushed me in the right direction... Finally realised that my instance of Home Assistant (running on another server) has an Open Media Vault integration that was polling the OMV installation every minute for hard disk space information etc. This is what was waking it up! I deleted the Open Media Vault integration from Home Assistant and re-started my Home Assistant instance and the problem has gone away.... My external USB backup disks have gone to sleep finally. Thank you.

Will.