the back burner

The Google TechTalk on the subject of Scrum, given by Ken Schwaber, contains one of my favourite quotes. You can see the whole thing here; and if you haven’t, it’s worthwhile devoting an hour to watching it. Can’t be bothered? Then don’t bother reading on. And the quote? To paraphrase,

our discipline has a tried and tested way of going faster. Cut corners, cut quality. That way you can produce more crap.

So, how does this relate to the DFS?
Read the rest of this entry »

Although ZFS seamlessly will support synchronous mirrors over multiple backend storage arrays, there are some advantages in keeping the mirror process asynchronous.
Read the rest of this entry »

I’m now using default zpool paths (which implies an automatic import and mount on reboot).

I just imported the bb-archive.isys zpool onto the first host, then rebooted it. After it had shut down, I forcibly imported the zpool onto the second host. Now waiting for the first to come back up. It should, perhaps, complain that the zpool is owned by someone else, but should not do a forcible reimport…

And alas, that’s not what happens. So:

I’m going to use altroots for all zpools. Unfortunately, this forces the subdirs to appear only mounted under the altroot. Not quite the combination I was after.

OK, so nsr picks up the filesystems to try to save from /etc/vfstab. Fine, except that (a) that means it tries to back up the contractfs(!) and (b) ZFS doesn’t use vfstab entries for its filesystems.

Solution: specify the service IP address explicitly together with a bunch of paths under the networker configuration.

OK, so MPxIO “Just Works”. I exposed a small number of LUNs (four, to be precise) from each of a pair of SataBeasts. One of those had something on it: to wit, a prototypical “bb-archive” zpool.

zpool status etc. will show the MPxIO devices that comprise the particular zpool in question - but what about the other seven LUNs? And what about when it comes to stiching LUNs together, and so on? This is going to turn into a cross-referencing nightmare!
Read the rest of this entry »

# mpathadm list lu
/dev/rdsk/c7t6000402001FC19CA6E9E7EFE00000000d0s2
Total Path Count: 2
Operational Path Count: 2

… and so on :-)

OK, so we’ve been waiting for these for weeks. D*ll kept on pushing the dates back. For a pair of HBAs, FFS!

Order went into Redstor last night at 4pm. They were here this morning by 9am.

Spot the difference.

I’ve decided to bring this forward a bit. This is somewhat motivated by the need to get spam[34] up and running so that Adam can start to move his build scripts to target the MBS deployment infrastructure.
Read the rest of this entry »

And by default it’s worse than that. Lesson is, if you want it configuring, do it yourself.

Personally, I don’t want it configuring, so it can sit and rot. Fuggit.

I’ve just physically plumbed in to the deployment & management network two new boxes, spam3 & spam4. These will be targeted by an MBS instance for deploying SpamAssassin (& co) configurations onto.

There’s finally a light at the end of the tunnel with the filestore work. Once the HBAs turn up I’ll be putting a new NFS server in place. This impacts on the appinf work in two major ways:
Read the rest of this entry »