What are these processes and how do I prevent them?

Question

Level 1

78 points

What are these processes and how do I prevent them?

For many years, many have complained of external drives that are in standby/sleep spinning up for no apparent reason. From the user's point of view this is unnecesssary, but to make matters worse, the system usually stops everything else while waiting for the drives.

I have a Mac mini that I use as a home theater pc. The media and backups are on a 5-bay enclosure (no RAID) attached by USB. While watching a video, the unused drives will go into standby mode, which is good. But then, with no user activity, they will spin up, freezing the video and everything else, which is not good. As these are slow drives and spin up sequentially, this can take 10-20 seconds. This may happen once or twice an hour, but sometimes more frequently.

In looking into the causes, I have turned off time Machine (after putting these drives into the Privacy section for good measure). I also prevented Spotlight and fsevents logging with the following:

mdutil -i off /Volumes/<drive1> /Volumes/<drive2> . . .

cd /Volumes/<drive1 and then repeat for other drives>

rm -rf .fseventsd .Spotlight-*

mkdir .fseventsd

touch .fseventsd/no_log .metadata_never_index

As far as I can tell this has worked to stop those processes from accessing the drives after they are mounted, but the problem persists. To find out what else might be causing them to wake up:

sudo fs_usage -w | grep -e Volumes/<drive1> -e /Volumes/<drive2> . . .

and here is what I found last night (actually didn't use the -w last night, thus it is cut off):

18:35:36 fsgetpath /Volumes/XBMC 0.000026 SSDragHelper

18:35:36 fsgetpath /Volumes/Stuff 0.000006 SSDragHelper

18:35:36 fsgetpath /Volumes/DatOptic_3 0.000005 SSDragHelper

18:35:36 fsgetpath /Volumes/MacBackUp 0.000003 SSDragHelper

18:36:15 fsgetpath /Volumes/XBMC 0.000026 System Prefe

18:36:15 fsgetpath /Volumes/Stuff 0.000004 System Prefe

18:36:15 fsgetpath /Volumes/DatOptic_3 0.000003 System Prefe

18:36:15 fsgetpath /Volumes/MacBackUp 0.000003 System Prefe

18:55:36 fsgetpath /Volumes/XBMC 0.000034 GoogleSoftwa

18:55:36 fsgetpath /Volumes/Stuff 0.000004 GoogleSoftwa

18:55:36 fsgetpath /Volumes/DatOptic_3 0.000003 GoogleSoftwa

18:55:36 fsgetpath /Volumes/MacBackUp 0.000003 GoogleSoftwa

After looking into the Google process, I was surprised to find the tentacles that Google puts into your system, and ripped every bit of it out that I could. But I have no idea about what's going on with SSDragHelper and System Prefe (presumable System Preferences). This must be OS X itself? What are these processes doing, and is there any way to prevent them from accessing these disks in this way?

MacBook Pro (15-inch Mid 2010), OS X Mavericks (10.9)

Posted on Feb 13, 2014 4:10 AM

Reply

Answer 1

Dessicator Author

Level 1

78 points

Feb 13, 2014 6:24 AM in response to Dessicator

Here are some more. It seems a lot of processes look at stuff even if it means waking up drives:

06:16:54.225682 fsgetpath /Volumes/Stuff 0.000005 System Preferenc.46839

06:16:54.225700 fsgetpath /Volumes/DatOptic_3 0.000004 System Preferenc.46839

06:16:54.225726 fsgetpath /Volumes/MacBackUp 0.000004 System Preferenc.46839

06:37:52.078926 fsgetpath /Volumes/Stuff 0.000004 ScreenSaverEngin.49148

06:37:52.078936 fsgetpath /Volumes/DatOptic_3 0.000003 ScreenSaverEngin.49148

06:37:52.078949 fsgetpath /Volumes/MacBackUp 0.000003 ScreenSaverEngin.49148

06:40:27.924551 statfs64 /Volumes/Stuff 0.000004 df.49559

06:40:27.924554 statfs64 /Volumes/DatOptic_3 0.000003 df.49559

06:40:27.924558 statfs64 /Volumes/MacBackUp 0.000003 df.49559

07:01:48.918749 getattrlist /Volumes/Stuff 0.000013 sharingd.52446

07:01:48.918775 getattrlist /Volumes/DatOptic_3 0.000009 sharingd.52446

07:01:48.918995 getattrlist /Volumes/MacBackUp 0.000207 W sharingd.52446

07:03:39.146214 getattrlist /Volumes/Stuff 0.000008 sharingd.52785

07:03:39.146241 getattrlist /Volumes/DatOptic_3 0.000009 sharingd.52785

07:03:39.146261 getattrlist /Volumes/MacBackUp 0.000008 sharingd.52785

Why in the world do System Preferences and the Screen Saver Engine need to look at external drives? What are these other things? Is there any way to stop them?

Reply

Answer 2

Dessicator Author

Level 1

78 points

Feb 16, 2014 12:51 PM in response to Dessicator

Here are some more processes that like to wake up external drives when I'm not even at the computer (e.g. just watching a movie).

RdMeta[S] /Volumes/Stuff/.metadata_never_index uTorrent (!!!!!!??????)

RdMeta[ST2] /Volumes/Stuff/.metadata_never_index systemstatsd

RdMeta[S] /Volumes/MacBackUp/Jims-MacBookPro.sparsebundle/bands/62 securityd

RdData[AT2] /Volumes/MacBackUp/Jims-MacBookPro.sparsebundle/bands/20d syncdefaultsd

RdData[AT3] /Volumes/MacBackUp/Jims-MacBookPro.sparsebundle/com.apple.TimeMachine.SnapshotH istory.plist spindump

RdData[AT3] /Volumes/MacBackUp/Misc/Software/DiskWarrior/DiskWarrior DVD Extras/DiskWarrior AppleScripts/Quit the Finder.app/Contents/Resources spindump

statfs64 /Volumes/Stuff df

This is starting to feel like catching raindrops to stop a flood. Most of it makes absolutely no sense and I have no idea how to prevent it. I've even found that some numbered files are being written to the .fseventsd folders, right next to the no_log file! The only thing that seems to work is ejecting the drives, which is a pain. But I have even seen them spin up when ejected (although that is when I messing with the Finder).

Reply

Answer 3

Hen3ry

Level 3

505 points

Feb 19, 2014 1:52 PM in response to Dessicator

I’m on a similar quest. Random (i.e., outside of the hourly backup) spin-ups of my single external USB drive, completely dedicated to TimeMachine, are definitely annoying. Yes, I’ve disabled Spotlight for this drive.

I’ve been looking at this for years, so the issue is not just with 10.9, but it makes sense to deal with the current version. Anyway, during this time, I’ve collected a surprisingly large number of mentions of this issue, none of which solved the problem for me.

I suggest we look for those fs_usage records that correlate with unnecessary spin-ups and the corresponding spin-downs. For this purpose, I set the menubar clock to display seconds. I also just found on the AppStore a utility called StorageStatus 1.0.1, which gives a little more detail on drive status.

Of course, our ability to discriminate by eyeballing is very coarse, but I think it is reasonable to try. Maybe it will be enough to overlook those records that clearly don’t happen anytime close to a spin-up/spin-down.

Will we find that all of these are all issued by the SystemUIServer process? Maybe.

I see you find other potentially worrisome records, and I encourage you to follow up on those, but I think these might best be considered as separate issues. I see far fewer worrisome records, it seems.

What about the three functions that we see commonly reported in connection with spin-ups and spin-downs: fsgetpath(), getattrlist(), and statfs64()? Why these?

I took a quick look at the descriptions of these three. fsgetpath() seems to be about referencing the drive, an apparently unexciting utility function, and the other two return current data and metadata about the drive. None I saw in the descriptions looks particularly interesting -- or dynamic. Why would MacOS check such information periodically, apparently waking up the drive to do it?

I don’t know. Mostly speculation:

Maybe this is a proactive means for MacOS to detect important changes in USB-attached drives earlier, so perhaps there’s more opportunity to recover. Seems to me USB-attached mass storage is a bit strange, as it can be detached —accidentally— at any time. Can any of the values returned by these functions change without any OS intervention? I guess that detecting some unexpected changes might be useful.

Another observation: I recently replaced the USB drive, as it was clearly failing. Seems that the random spin-ups occur less often now, and —so-far— only one at a time. With the old drive, I observed frequent instances of 2 or even 3 back-to-back spin-up/spin-down cycles. This isn’t occurring with the new drive.

Reply

Answer 4

Dessicator Author

Level 1

78 points

Feb 19, 2014 4:25 PM in response to Hen3ry

Thanks for the reply Hen3ry. Looks like you've done a lot of investigation. For me, fs_usage entries accompanying spindown are not problems - I'm happy if the drives spin down. My problem is the spinups. But still, I don't think it is necessary to time the fs_usage entries with spinups. If you grep for the drives you're concerned about, you will see any process that would potentially wake them up.

Because my understanding is limited, I also am more concerned with the process/application that is accessing the drives than with the functions or commands they are sending. And the values that are returned by those functions are way beyond what I can deal with.

It's interesting that you've found a difference between your old and new drives. Could you specify the enclosure and drives in each case?

The StorageStatus app looks interesting; thanks for the tip.

Here's a summary of what I've done so far, which I think is working. I need a few more weeks to know for sure.

How to prevent unwanted drive spin-ups

If you are actively using the computer that the enclosure is attached to, nothing on God’s green earth will stop OS X from waking them up after some user action, even ones that seem to have nothing to do with the external drives. But if you leave the computer alone while some application is running, like watching a movie or downloading a file, you have a fighting chance of coaxing OS X into leaving the uninvolved drives alone.

If the drives are shared with any other computers over a network, eject them on those computers

Otherwise, OS X (AppleFileServer) will poll them every 10 seconds. This might not be bad if you want to just keep the drives spinning and the other computer stays awake.

Third-party apps

Make sure no apps are running that might access your drives. Google runs some processes that do this (maybe I’m naïve, but I was so shocked I removed chrome and every other trace of Google from my Mac mini system). Another is iStat and any utility that monitors SMART status in the background.

Don’t let Spotlight index or search the drives

Spotlight is persistent, and it may be necessary to take a variety of steps to stop its various processes (mds, mdworker) from accessing the drives and waking them up. In other words, kill it, drive a stake through its heart, then burn the body:

In System Preferences > Spotlight, add the drives to the Privacy pane.
Add a file called .metadata_never_index to the root of each drive (note the leading period). The easiest way to do this is in Terminal
touch /Volumes/<drive1>/.metadata_never_index
Tell Spotlight AGAIN to keep away from the drive:
mdutil -i off /Volumes/<drive1> /Volumes/<drive2> . . .
Finally delete the Spotlight folder from the drive.
rm -rf /Volumes/<drive1>.Spotlight-*

Stop fseventsd from logging in the drive

This is easy, just putting a no_log file in its folder. I have found that rarely it still writes some files in there, but it doesn’t seem to do so when it causes problems, so . . .

rm –rf /Volumes/<drive1>/.fseventsd/*

touch /Volumes/<drive1>/.fseventsd/no_log

Finder sidebar

Some people say that if the drives show in the Sidebar of Finder windows, the Finder will be checking them. I’m not sure. But to be safe, in Finder Preferences > Sidebar, uncheck External Disks.

Just say no to Time Machine

On the home theater mac itself, regular backups shouldn’t be needed. You should be able to just turn Time Machine off. However, it is probably sufficient to simply open System Preferences > Time Machine > Options and add the drives to the list of locations to exclude from backup.

Second, local backups can be disabled with

sudo tmutil disablelocal

Look for other culprits

If the problem persists, use fs_usage, which generates a real-time log of filesystem activity. There is so much going on that you need to use grep to restrict the output to entries that involve your drives. The entries that accompany your drive spin-ups are the ones you really want.

sudo fs_usage -w | grep -e Volumes/<drive1> -e /Volumes/<drive2> . . .

Now leave the keyboard and mouse alone, as many things you might do will cause the drives to be accessed. You probably want to find what does it when you’re not actively interacting with the computer. It’s not really necessary to wait for your drives to sleep and see what wakes them. Any activity you see would probably wake the drives if they were asleep. When you see some activity and want to stop and examine, type Control-C to stop the output. On the far right of each entry is the process or application that accessed the disks.

I got pointers from http://system-log.tyr.org.uk/2012/01/31/how-to-stop-usb-drives-from-spinning-up- unnecessarily-on-os-x-lion/ and http://www.jackenhack.com/disk-that-refuses-to-sleep-in-mac-os-x-how-to-fix-it/

Reply

Answer 5

Hen3ry

Level 3

505 points

Feb 20, 2014 10:37 AM in response to Dessicator

Dessicator:

Thanks for your response!

The old drive was a 1.5Tb Seagate FreeAgent Desk. The new drive is a 3TB Seagate Backup+ Desk Media.

re: Spinups versus spindowns. They seem to come in pairs, so it seems at least mildly interesting to understand the entire cycle, though yes, it could be that spinups are triggered by possibly interesting events and spindowns are purely timeout-driven.

re: "...nothing on God’s green earth will stop OS X from waking them up after some user action, even ones that seem to have nothing to do with the external drives..." I really want to know why seemingly unconnected actions (or events) cause spinups. There must be a reason. If I can discover it, maybe I can do something to prevent or reduce the annoying spinups. Or at least I'll learn something about MacOS. Understanding the why might simply reduce my annoyance.

Discussion: Pre-OS X, Mac system drives would commonly spindown for long periods, and you could usually attribute spinups to tasks triggered by your input. It was well-known to me, anyway, that Unix is a whole different story. It is really easy to accept that the spinups under OS X won't follow a human-understandable pattern.

I've heard from a credible source that modern, high-capacity HDs commonly/routinely wake themselves to perform data maintenance. If this is so, in general, increasing random spinups may indicate a failing drive, which information would be Good To Know. In the case of my 1.5TB Seagate drive, which a few days later became officially DOA, seems to me that it has been indicating "failing" for most of its life, by this indicator. The replacement seems to be in a lot better shape, as it should be, and that's reassuring.

I'm going to try understand how the information provided by the StorageStatus utility correlates with the activity light on the USB drive. Also to the data provided by fs_usage(). Maybe it would be worthwhile confirming that invocation of getattrlist() or statfs64() for that drive always result in a spinup if the drive is in a sleeping state, either by finding the right docs or experiment. Maybe I can follow the pattern of StorageStatus to develop some instrumentation s/w that will help...

Another random observation: when for test purposes I kept multiple USB drives attached, the spinup patterns for the drives seemed to vary: signficantly more for the TimeMachine target. Could it be that the drive specified as the TimeMachine target gets different treatment? It might be useful for me to buy a second, identical replacement drive and attach it, too. Then alternate (say, for a day at a time) the two identical drives between selection as TimeMachine target and just another attached drive. Would the spinup patterns vary? Of course, even two identical, new drives might spin themselves up --for maintenance, as mentioned above-- at very different rates.

Reply