What's thrashing my Macbook disk?

Oct 28, 2007 20:36 · 468 words · 3 minute read

So far, my MacBook Pro has been running really well, with one or two very minor niggles. One of these was the speed of going to sleep - there would be a good 30 seconds elapsed between closing the lid and the sleep light “snoring”; and the other problem was that the disk seemed to be getting thrashed to bits for no apparent reason. Even when sitting quietly apparently doing nothing, the disk would be churning away. For all I knew, this might be something normal, but constant disk activity seems a bit odd.

The first step was to find out what was thrashing the disk. The built-in OS X Activity Monitor will show you the volume of disk activity, but there’s no way to work out what is doing the read/writing. So the next port of call is to work out which process is the cause. The easiest way of doing this is to use the fs_usage command, that monitors disk access and captures details of the process that’s doing the accessing.

If you run this on the command line, the data scrolls past until you stop it with ctrl-c - but that’s generally too fast to be useful, so you’re better piping the output into a file like this: sudo fs_usage -w > file1.txt The fs_usage command needs to run with root permissions, hence the sudo command.

Then you can open the file in a text editor, e.g. mate file1.txt and analyse at your own pace. The -w switch forces wide output, so you get all the data being reported - but you’ll need to widen your text editor window in order to be able to see this. In the right-hand column you’ll see the application names reading and writing to the disk.

In my case, the problem was obvious - at least 95% of the data being recorded in the file was caused by Google Desktop. I don’t know exactly what it was doing - indexing, presumably - but it was enough to thrash the disk and also as it turns out, slow down the process of going to sleep. I don’t know whether this constant disk activity is normal for Google, but I don’t use Google Desktop enough to make it worth while - so It Had To Go.

That turned out to be slightly less than straight-forward, due to the non-standard way that it gets installed. After several false starts where the same process would reappear after a reboot despite apparently uninstalling the software itself, I came across this set of instructions at Daring Fireball which outlines exactly what gets installed where. After working through this list and zapping the files, a final reboot resulted in peace and quiet, and a sleep as quick as I’ve been used to with a G4 Powerbook.