On 2/12/20 7:09 PM, Roger Heflin wrote:
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 /.
That makes sense. Just occurred to me: a typical shell prompt displays the cwd, so 'pwd' or something like it must get run just before a shell prompt is displayed. This likely explains why I'd sometimes experience the spin-up delay after running a command: it wasn't the command itself necessarily that triggered the spin-up but the pwd afterwards.
Assuming that is the case your solution would be expected to work,
It seemed to work earlier today when I fired up the green USB hard drive in that I experienced no spin-up delays, but...
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.
That's a great idea. I've gone ahead and implemented it on my PCs.
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.
There certainly are a lot of processes on my PC running cwd. Interesting...
Thanks! Dave