I'm going to do this on the server and save the power for the build for later. By server, I mean the machine which hosts the parent workspace. I start this by getting a new ZFS fs for the parent workspace (not shown) and then making a zfs snapshot and clone:

[th199096@aus1500-home th199096]> zfs snapshot pool/ws/th199096/spe-gate@base
[th199096@aus1500-home th199096]> zfs clone pool/ws/th199096/spe-gate@base pool/ws/th199096/spe-zfs-clone

Note the lack of being root or using sudo. Someone has setup an RBAC role which allows me to do these zfs operations.

Let's see how nice the clone is for us:

[th199096@aus1500-home th199096]> ws spe-zfs-clone/

Workspace                    : /pool/ws/th199096/spe-zfs-clone
Workspace Parent             : ssh://aus1500-home//pool/ws/nfs41-clone
Proto area ($ROOT)           : /pool/ws/th199096/spe-zfs-clone/proto/root_i386
Root of source ($SRC)        : /pool/ws/th199096/spe-zfs-clone/usr/src
Root of test source ($TSRC)  : /pool/ws/th199096/spe-zfs-clone/usr/ontest
Current directory ($PWD)     : /pool/ws/th199096/spe-zfs-clone

Very nice, it has the correct parent. I think a lot of this stems from the fact that Mercurial parents have no notion of the children. Which is unlike TeamWare.

I could then start making changes down here and keep my original copy safe.

A real power here is if I have the workspace already populated with object files and such after a build. I could make a clone, do a couple of minor changes, and eliminate a lot of recompilation.

In the time it took for the workspace to build, I had pulled the spe userland code into a stand-alone executable and resolved all of the bugs. I think I had one or two nasty runtime errors and more compilation errors. Going to the new versions of the data structures was a bit of a stretch. But most of the issues I had with hand rolling went away. I'm happy this stuff is automated.

I finished up the code to extract the pool ids out of the NFS4 kernel databases and it is now building. I ran into a really weird workspace issue. I had committed the changes on the child and pushed them to the parent. I then synced the parent with the gate and tried to pull them back to the child. I then got stuck in an endless loop:

[th199096@aus-build-x86 nfs]> hg update
abort: crosses branches (use 'hg merge' or 'hg update -C' to discard changes)
[th199096@aus-build-x86 nfs]> hg merge
abort: outstanding uncommitted changes

I didn't panic and I sure as all did not do the 'hg update -C'. A quick sanity check showed that I had my changes in the child, but not the parent. I copied my changes off to the side and started investigating with the help of Master Class Gate Keeper Dave Marker. He had me run 'hg verify', with no luck. 'hg heads' showed I was hosed:

[th199096@aus-build-x86 nfs]> hg heads
changeset:   7544:9db4010e4721
tag:         tip
parent:      7541:b22d9d40cc1b
parent:      7543:ec0365b1794e
user:        Thomas Haynes 
date:        Tue Sep 23 14:50:18 2008 -0500
summary:     Merge

changeset:   7542:858bacc2f179
user:        Thomas Haynes 
date:        Tue Sep 23 14:42:48 2008 -0500
summary:     Okay, getting guids out of REPORTAVAIL

And I took a clone of the child and it did not have my changes. What I think happened was that I did a commit, but never the push back to the parent.

Dave had several good points:

1. Don't build in the parent (kills 'hg stat -mard')
2. Clone the child for building, not making changes
3. If you are making changes in the child, clone it for the actual building
   • Rich Brown, a co-worker, uses rsync to do this
4. 'zfs clone' and snapshot are your friends.

I guess there is more, but I'm pretty zoned on most of this. Last week was busy and I worked through the weekend.

I am though thinking of doing a simple debug utility to walk through the REPORTAVAIL output to tell the admin what data sets there are. With the work I've had to do to get at this programatically, it should be easy.

By the way, on the subject of hand rolling or automatic generation of XDR code, this came out of a trip report by Dean Hildebrand from the BAT [pnfs] bakeathon wrapup:

On my end, my testing with Sun revealed a few interesting items.
...
c) We *almost* got device notify (linux server, sun client) working, but 
there were still some xdr issues before I had to leave.  Man, it would 
be great if  linux used some form of rpcgen, our bakeathon testing is 
not exercising all corner xdr scenarios, and I'm sure there are some 
errors here and there from our hand creation of the xdr.

My last GPS died on me the last time I was in Austin. On one trip for whoich I hadn't rented a car, I had to drive back from Austin for a family emergency. Sun rents from Avis, so I got what was basically a Garmin StreetPilot c550. And I loved it. So when the old one died, and since I hated it, I got the Garmin.

I was in Austin last week and it did everything I wanted the older one to have done. And then it also died in Austin. Friday morning it wouldn't turn on.

I figured out the 30 day period was over with Amazon, so I finally got around to calling up Garmin Tech support. Turns out there is a hidden reset button under the front bezel. I reset it and it still wouldn't power up. Aaron, the Garmin Tech Support guy, had me plug it into a USB port on my PC. It started up.

I let it charge for 4-5 hours and now it turns on like a charm. I'm also finally getting LEDs lit on the power cable. I figure it wasn't connecting fully.

Anyway, I'm back to loving it and I also had a really smooth tech support experience.