It may be the pwd command doing it. It works like this:
if something runs pwd when its cwd is under say /var/log then pwd goes
through all files in /var/log until it finds .. then it goes up a
directory and repeats, until it gets to /.
Assuming that is the case your solution would be expected to work, if
you put it under /mnt/backups then any other pwd anywhere under mnt
may also cause the spinup. On nfs mounts an nfs mount that is hanging
of say /mnt/host1 can hang everything else in /mnt even coming from
other responding hosts. the trick there is to
/mnt/host1/host1mntpoint and put each separate host in a separate top
level directory to isolate them from each other. You may not need to
do that so long as you don't have other things in /mnt being used that
may cause a pwd.
if you run ls -l /proc/*/cwd | more it will show you everything
running's cwd. I see /var/spool/at (atd process) with that as a home
dir, so atd doing a pwd would cause a spinup.
I don't actively use atd for anything and strace does not show atd
doing anything on my machine. If you use atd then it may be what is
doing it. nfs's statd also its cwd under var and is used on nfs
servers.
On Wed, Feb 12, 2020 at 1:11 PM Dave Ulrick <d-ulrick@xxxxxxxxxxx> wrote:
>
> On 2/12/20 7:53 AM, Dave Ulrick wrote:
> > Interesting thought. I can envision how a lookup for /var/xyz could
> > cause everything under /var to be looked up, and I can see how
> > /var/cache or /var/run would be frequently read. I'll try mounting a
> > green USB drive's file system at a third-level directory (e.g.,
> > /var/backups/0) or under a less popular directory (e.g., /mnt/backups)
> > and see if that behaves any differently.
>
> I ran 'strace' on 'ls' but nothing interesting showed up. Then, I ran
> 'strace' on 'bash'. I ran 'ls' from 'bash' and then exited. The strace
> log shows two connect()s to a socket file under /var/run:
>
> socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
> connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) =
> -1 ENOEN
> T (No such file or directory)
> close(3)
>
> /var/run/nscd/socket appears to be related to the 'nscd' DNS cache which
> I am not running on my PCs.
>
> So, it looks likely that reading /var/run caused the contents of /var to
> be read. This would have triggered a wakeup of the device hosting
> /var/backups which would be a cause of its hard drive spinning up.
>
> In addition to one PC that mounted a green USB drive under /var I had
> several other PCs that mounted a NAS under /var. That NAS is intended to
> store backup files so its hard drive is configured to spin down after 10
> idle minutes.
>
> In view of these findings, I've reconfigured my PCs to mount the backups
> directory under /mnt instead of /var. So far since doing so I've not
> noticed any spin-up delays related to a USB hard drive or the backup NAS.
>
> Thanks, Tim!
>
> Dave
>
> _______________________________________________
> users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
