Hard Disk wake up very frecuently

[serram]

Ok, I understand now what I should do before... :hammerhead

Code: Select all

root@fvdwsl-base:/ # debugfs -R "ncheck 22428" /dev/sda5
debugfs 1.43.4 (31-Jan-2017)
Inode   Pathname
22428   /usr/samba/private/msg.sock


[Jocko]

So you have the same behaviour than me.

I assume you use samba4 and it seems samba makes regularly I/O on these sockets even if there is no activity. Need to test if by moving it in tmpfs that solves the issue.

[serram]

Yes, I'm using samba 4.9.4

Need to test if by moving it in tmpfs that solves the issue.

Ok.

[Jocko]

Hi

So I fixed all issues detected but I need to make a full test next night before sending you a patch.

However you can fix the noatime option on the fw system partition with this command (at each booting)

Code: Select all

mount -o remount,rw,noatime  /

[serram]

Hi Jocko

However you can fix the noatime option on the fw system partition with this command (at each booting)

Code: Select all

mount -o remount,rw,noatime  /


Do you mean using a boot job?

I would like to ask you something: in the web interface at the section Spin-down guard internal Hard Disk, I see that the current setting is enabled, and I can change the inactivity period from 5 to 30 minutes, but I can't see an option for disable it. I've seen that the new NAS disks like WD Red or IronWolf Seagate are designed for enviroments of 24/7 access. So how could I change that setting for the disks be always spininng?

In my case, I don't have a new network disk, the internal disk of my Lacie cloudbox is the original.. a Seagate Barracuda 7200.14 (ST2000DM001-1CH164)
But A few years ago, or maybe many years ago... In year 2000, I had a UK TiVo series 1, and the internal disk was always spining, 24/7, and that disk in his useful life never died, my TiVo become an obsolet device in 2012 and I retired it from my system in 2015, but I remember the internal disk was ok.

I'm not sure If I want that my internal disk to be always spining, but I think It could be interesting to be able to do it.

[Jocko]

Do you mean using a boot job?

it is not worth it because I will send you the patch tomorrow. So just run manually the command.

I can't see an option for disable it. I've seen that the new NAS disks like WD Red or IronWolf Seagate are designed for enviroments of 24/7 access. So how could I change that setting for the disks be always spininng?

Indeed from the web interface, you can not do it.
Only a boot job may do it: create a short shell script which runs

Code: Select all

killall noflushd

Now I do not know if we had this option on next version, if yes we have to handle the case where some disks are 24/7 access and the others not. So run noflush daemon for monitoring only this last disks

[Jocko]

Hi serram

My test on last night is OK : I got no I/O for 4 hours and disk stayed down
Now We go to see if it is also the case with this patch on your nas or there is something else

To install the patched files, do:

Code: Select all

plugout download 6523
tar -xf /tmp/fvdw-sl-18-x-fix-noatime-samba-21sep2020.tgz -C /

Then you have to reboot the nas for fixing the issues about system partition and samba.
After restarting, please to post the outputs

Code: Select all

mount
ls -al /usr/samba/private/

(You should see all fs is now mounted with the option 'noatime')
So you can run again a full test with diskmon for at least two or three hours after the disk spinning down :
-

Code: Select all

 diskmon 5

,
- unplug the lan wire
- wait at least two or three hours after the disk spinning down
- kill diskmon daemon

Code: Select all

killall diskmon

Post the file log1 (and log2 if it is not empty), location : /tmp/usr/var/diskmon
If the disk stays down logs size should be small :whistle

[serram]

Hi Jocko, thanks for your work.

I have installed the patched files, and rebooted.

Then run these comands with theses outputs:

Code: Select all

root@fvdwsl-base:/ # mount
/dev/sda2 on / type ext3 (rw,noatime,stripe=4,data=ordered)
none on /proc type proc (rw,noatime)
none on /sys type sysfs (rw,noatime)
none on /dev/pts type devpts (rw,noatime,mode=600,ptmxmode=000)
/dev/sda5 on /rw_fs type ext3 (rw,noatime,data=ordered)
tmpfs on /rw_fs/tmp/usr/var type tmpfs (rw,noatime,size=5000k)
nfsd on /proc/fs/nfsd type nfsd (rw,noatime)
/dev/sda8 on /share/1000 type ext3 (rw,noatime,data=ordered)
/dev/sda7 on /lacie-boot type ext3 (rw,relatime,data=ordered)

root@fvdwsl-base:/ # ls -al /usr/samba/private/
total 0
drwxr-xr-x  3 root root 200 2020-09-22 20:10 .
drwxr-xr-x  3 root root  60 2020-09-22 20:09 ..
lrwxrwxrwx  1 root root  33 2020-09-22 20:09 hkcr.ldb -> /rw_fs/usr/samba/private/hkcr.ldb
lrwxrwxrwx  1 root root  33 2020-09-22 20:09 hkcu.ldb -> /rw_fs/usr/samba/private/hkcu.ldb
lrwxrwxrwx  1 root root  33 2020-09-22 20:09 hklm.ldb -> /rw_fs/usr/samba/private/hklm.ldb
lrwxrwxrwx  1 root root  32 2020-09-22 20:09 hku.ldb -> /rw_fs/usr/samba/private/hku.ldb
drwx------  2 root root 300 2020-09-22 20:10 msg.sock
lrwxrwxrwx  1 root root  36 2020-09-22 20:09 secrets.ldb -> /rw_fs/usr/samba/private/secrets.ldb
lrwxrwxrwx  1 root root  36 2020-09-22 20:09 secrets.tdb -> /rw_fs/usr/samba/private/secrets.tdb
lrwxrwxrwx  1 root root  34 2020-09-22 20:09 smbpasswd -> /rw_fs/usr/samba/private/smbpasswd


Now I'm going to run diskmon for several hours, and I will post the log1 file.

[serram]

Here it is more than 6 hours of log with diskmon.
20:32h is the time when the disk spin down at the beginning.
And I think the disk only wakes up one time!! so this is a great!
Congratulations Jocko!

The disk do a spin up at 22:37h or 22:40h...
Is this spin up totally necessary? or it can be also suppressed?
Anyway, thanks for your work.

:applause

[Jocko]

Hi serram

Yes all seems to be ok now :thumbup

Anyway, thanks for your work.

And also Mijzelf, without his suggestions and his tool I do not think I would be able to detect the noatime issue

About the I/O at 22:37:05, I think the event occurs because you had a shell session when you unplug the lan wire. Then after a timeout value utmpx (which allows to get a login history) has been updated with your session closed but not properly when you unplugged the lan wire. (need to check the timeout values used by dropbear)