Tim Foster's Weblog

Last week, when up at the in-laws' in Carrickfergus, I was given a Canon MV600 DV camera on extended loan - the idea being that Bananas' grandparents would get more videos of her doing the sort of stuff we see every day, but they don't get to see other than when we (or they) come to visit.

There was only one catch - there was only 1 video tape with the camera, and that contained a load of footage of recent vacations that Henry wanted to keep, so I promised I'd burn a DVD of it, and post it up.

As a computer-video newbie (I much prefer photography), I didn't quite realise the extent of what I'd promised - I'm still using a 2002 17" G4 iMac at home for media stuff, and converting 60 minutes of video to DVD takes up a lot of disk space, and an awful lot of processing power. Disk space that I didn't have, and processing power that meant my Mac has been on for much of the weekend crunching away on this task - which more modern hardware would no doubt laugh at.

I solved the disk space problem by storing the files on my Solaris box on ZFS, sharing to the Mac via NFS. The processing-power problem was more interesting though.

Last night, I checked in on my machine - looking to see how iDVD was getting on. Uhho - dreaded spinning beachball of death, and alt-apple-esc was showing iDVD (Application not responding). Generally a bad sign. It was about 50% through the task of encoding the video, and I didn't relish the thought of having to kill the app, and start all over again.

I had a poke around to see what sort of observabilty tools were on the Mac - ktrace. Hmm, not too useful, the application looked like it was spinning around some system calls, but that's about all I could determine. I found myself wishing for DTrace for OSX - which is on it's way, but I needed it now. However, since I'd saved the footage on a Solaris box, and was working over NFS, I had a better idea.

I was able to log in to that machine, and a quick utterance of dtrace -n 'fbt:zfs:zfs_read:entry {printf("%x",arg0);}' got me the address of the vnode being accessed, which I then passed into mdb -k to print the <addr>::print vnode_t vdev_path giving me the full path of the file being accessed. Popping in a call to the DTrace stack() function allowed me to verify that it was indeed the NFS server that was serving accesses to this file. With a bit more digging, I found that different parts of the file were being accessed, so I suspected that iDVD was still doing something useful. I decided to leave it running to see what would happen, and went to bed.

(btw. I've since found out that dtrace -n 'fbt:zfs:zfs_read:entry {printf("%s",stringof(((vnode_t*)arg0)->v_path));}' would have been more efficient here.)

Anyway - it's now Sunday morning, and iDVD has finally completed and I've now got a shiny DVD containing holiday footage from in-laws' vacations past. The problem was, iDVD hadn't hung, it was just really busy, but I wonder how many of the other 11,000 hits for "iDVD application not responding" on Google are just from either impatient people running old hardware or the system not being polite enough to tell you what the application was actually doing ? Having observability right into the application in future versions of OSX will be a god-send with DTrace coming in 10.5 - hope they get it working on PowerPCs as well. Damn, does this mean Apple gets another $129 from me :-(

Anyway, so there you go: DTrace - not just for developers or sysadmins, it's helps you score brownie points with the in-laws too!