Mac OS X writes too much data to disk, or does it?

This is just an observation I made a couple of days ago. I had my new Macbook Air 11″ on for some 13hrs during which all I did was light use of Google Chrome to look up things once in a while, chat with people in Skype and Adium, listen to radio streams in iTunes, work in a terminal, of course, had Mail.app running which is configured not to save anything to disk, and by the end of the day Activity Monitor reported some 5GB worth of disk writes. 5 gigs, really?

Why would I be concerned? Well, I’m generally speaking curious, but also there’s a legitimate concern because SSD drives, which are of MLC type in Macbook Air’s, on average are guaranteed to last 5 years with average 40GB disk writes per day. So, you can see that 5GBs per day in that context isn’t really a small number.

So, I set out to figure out to see distribution of those disk writes but I haven’t found a solution yet. dtrace looks like the tool that could pull out this data but it falls short of showing accumulated values over time. What I’m talking about is Linux equivalent of iotop -o -a, which is just amazing, simple and user-friendly compared to dtrace.

Which reminds me to say that Mac OS X is a funny OS. It makes it really easy to use a computer in GUI department, but Apple seems to have applied their philosophy of radically simplifying things to command line applications as well. Less of output (otherwise useful and detailed) seems to be characteristic of Apple’s version of such tools as iotop and sar, to name a few.

This I find a little frustrating and limiting. By and large, though, I really like Mac OS X and the whole experience of running Macbook Air.

I’d highly recommend it.

Keep Linux Console From Dimming The Screen

There are many ways to do it depending on your context, i.e. whether you’re working with headless setup that doesn’t need to run X server – plain old console – or with an X-based setup.

In my particular case I had  a CentOS box that ran without X server and experienced some obscure, intermittent lockups. So, I needed to hook up the display, hoping to see some output like kernel call trace or maybe some error messages the box locks up the next time. The problem was that the system would dim the screen and when the box locked up I couldn’t see anything that might had been printed on stdout.

After quite a prolonged session of error and trial, what I learned was that simply issuing setterm -blank 0 in a terminal over ssh session (didn’t try to directly enter this command, let me know if this works for you) wasn’t working.  So, what I ended up doing was adding

% echo “/usr/bin/setterm -blank 0” >> /etc/rc.local

to the end of /etc/rc.local and rebooting the box.

That did it for me (finally! lol)