Archives / Search ›

SMART monitoring on USB/FireWire enclosures

As a followup to my prior post on external enclosures, a helpful commenter mentioned the OS X SAT SMART Driver, a third-party driver which provides SMART monitoring via USB/FireWire on OS X.  Other operating systems provide SCSI command pass-through support, meaning a separate driver is not required.

The installation instructions for the driver are confusing and contradictory in places, but you should be fine if you download a snapshot of the repository, install version 0.6 from the included disk image (SATSMARTDriver-0.6.dmg) and restart, then look in Disk Utility to see if SMART status appears for your drive (which may take a minute or two).  I had no problems on 10.6.8 or 10.8.4.

However, works just means the SMART driver is functional — the USB or FireWire enclosure/SATA bridge you’re using needs to support sending SMART commands to the drive as well. As is customary with “fringe” features of commodity hardware, reliable information about specific hardware support is hard to come by. The best I found was this list of USB devices supported by the smartmontools package (which also includes some notes on FireWire), but it doesn’t include most of the devices I have.

I originally used a Linux live CD with smartmontools preinstalled to test several of my USB 2/3/FireWire 800 enclosures. This provides more useful error information than OS X when SMART doesn’t work, but the set of devices supported by the OS X driver turned out to be identical.  (This is not necessarily the case.)

The results weren’t great — links point to smartmontools output:

Assuming the above is representative, if you're using a USB 2 or 3-only enclosure, chances are good that you'll be able to get SMART info. If you’re using an older FireWire 800 enclosure, you’re probably out of luck, even over USB. If you’re using a newish FireWire 800 enclosure, it might work!

The MB080USEB-1SB above is a nice toolless swappable FireWire 800/USB 2.0/eSATA enclosure with a large (quiet) fan up front. It is available until the end of August for as little as $38 after a $40 mail-in rebate, which is a pretty great deal if you still need FireWire 800, and it was the only enclosure I tested that does support SMART over FireWire.

Speaking of fans, OWC now sells replacement fans for the miniStack — mine seems to have fixed itself as I discussed in my prior post, but it’s good to see the option.

Growl and Pester repeating alarms

Back in October, a Pester user sent me this email:

I work in media and I like to set recurring Growl reminders to save my work. Why Growl? Because I don’t want to actually be interrupted to dismiss the Pester alarm window, only see a reminder so I can hit Command+S and continue on my way.

If I set a recurring alarm that repeats and notifies with Growl (screenshot 1), the alarm will be listed in the Alarms List (screenshot 2).  However, it will only display the alert once and then not repeat and the recurring alarm will not show up again in the Alarms List (screenshot 3).  If I quit Pester and then reopen the Alarms List, the alarm will be listed again (screenshot 4) but after it displays that one time, it will not show up again.

I have tried upgrading Pester’s Growl framework to 1.3.1 using the Growl Version Detective, but that did not work.

At the time I responded that I could not reproduce the problem and promised to get back to it. I received another similar email today and finally had a chance to investigate.

Unfortunately, the problem is a bug in Growl 2.0.x and 2.1 that affects repeating Pester alarms for which you have Notify with Growl selected but not Display message and time.

Pester’s repeating (periodic) alarms work somewhat uniquely: if you’ve got an alarm set to trigger every 5 minutes, the 5 minutes don’t start until the previous repetition of the alarm finishes expiring. An alarm can finish expiring in one of several ways:

  1. If Display message and time is selected, the user clicks Snooze or Dismiss.
  2. If Display message and time is not selected, the user chooses Stop Alerts from Pester’s Alarm menu or presses ⌘. (Command-period) (and #1, if necessary)
  3. If Display message and time is not selected, all of the alarm’s selected alerts (voice, media, speech and/or Growl) complete or are dismissed by the user. For images or movies, the user can close the display window.

Growl promises to inform clients, such as Pester, when the user clicks on a notification, and when a notification times out (e.g., disappears from the screen). But Growl 2.0.x and 2.1 don’t do this, so Pester waits forever for the notification to time out or be clicked, the Growl alert never completes, and the alarm never finishes expiring. Alarms which are in the process of expiring aren’t listed in the Alarms window, which explains the behavior described above in which alarms disappear from the list.

My apologies if you’ve experienced this problem.  If you have repeating alarms “stuck” which you can’t delete, you can force an alarm that is waiting forever for Growl to appear in the alarm list with Stop Alerts (⌘.).

Update: Pester 1.1b16 supports OS X notifications in 10.8 Mountain Lion and later, in addition to Growl notifications.  Unlike Growl, OS X notifications don’t even promise to provide any information about when they disappear from the screen, so Pester won’t wait for them. Pester 1.1b16 works around the problem by making Growl notifications behave the same way as OS X notifications when you are using Growl 2.0 or later — they won’t wait for you to dismiss them.  When a fixed version of Growl is available, I will revisit this issue.