Slashdot Mirror

You mean like this ambient device: http://www.mcternan.co.uk/MAD/

Here's a link to my lightbulb on the internet: http://mcternan.co.uk/MAD/

It's an ambient device, and while only IPv4, but it does run on a lovely ATmega168 and support DHCP, AutoIP, NMNS and has a HTTP tiny client.

That's no fun, I wanted to see the click boxes on the web page so I could turn your light on and off.

Check this: http://mcternan.co.uk/MAD/

Here's a link to my lightbulb on the internet: http://mcternan.co.uk/MAD/

It's an ambient device, and while only IPv4, but it does run on a lovely ATmega168 and support DHCP, AutoIP, NMNS and has a HTTP tiny client.

I consider most of the code I write to be pretty.

Here's a link to some source: http://www.mcternan.co.uk/ArmStackUnwinding/wind.t ar.gz

The write up of what I do is here: http://www.mcternan.co.uk/PerforceBackup/

Interesting! I'll have to look it over more later.

For comparison, I've put the latest (not yet deployed) version of our offline checkpoint process here. (It's a NetVault backup script; pre locks and does the checkpoint, post touches a file signalling success to our monitoring and releases the lock). It's a procedure outlined by Perforce, though they didn't mention error handling...

> Not that it's all roses with Perforce. My impression is that it doesn't scale
> very well. Most operations simply lock the entire database.

I agree - the backup solution described and recommended by Perforce works well for small installations, but doesn't scale very well in my experience. It's disappointing given that Perforce use scalability as a selling feature (http://www.perforce.com/perforce/products.html).

I went on a limb and made an alternative way to do checkpoints/backups for exactly the reason you describe - it's difficult to get right and seriously bad if you get it wrong. The write up of what I do is here:

http://www.mcternan.co.uk/PerforceBackup/

In my opinion it would be simple for Perforce to implement some simple changes to help large scale backups (e.g. make p4d -jj -c "cmd" work), and I've suggested it to their support staff, some of whom I've met in person at various times. However, I haven't heard or seen any indication that they are going to do this... I'm still hopeful, but less so these days.

I also believe that Perforce only does locking at the table level (using flock()), which is most likely why the server often sees poor concurrency, especially with write operations as you describe. The more recent versions of the server are apparently better (2006.x), although I'm yet to upgrade. The server itself is based on SleepyCat Berkley DB tables, which Oracle recently took over and look to have improved (http://www.oracle.com/database/berkeley-db/db/ind ex.html). So maybe future versions of the Perforce server will benefit too. I hope.