In a recent podcast recording (coming out in a couple weeks… will link here when it’s done), I spoke with Andrew Klosterman of NetApp’s Advanced Technology Group about some of the things he’s worked on over the years. One of those things is something called “Ethernet Monitoring Unit (EMU)” – a new feature in OnCommand Insight that allows a client to act as a packet sniffer in an attempt to monitor NFS traffic and do useful things like map client IP addresses to volumes in ONTAP. I plan on writing up a blog post on that once I sort out all the details, but this blog is more about context switching and what happens when we run into hard problems…
Why can’t we focus on one task?
If you Google “context switching productivity,” you’ll find plenty of articles on this topic.
Simply put: humans tend to multi-task. It’s not necessarily a function of ADHD or some other ailment. Rather, it’s how we are. We’re curious – when something piques our curiosity, we tend to follow it. Then, it can lead to other paths and tangents, and before we realize it, we’re off on a completely different task than we started with. This blog, for instance, is an example of a context switch.
This context switching, for me, is usually spurred on when I’m bored with a task or have reached a point where I’m not making progress and need to step away from it for a bit. This OnCommand Insight feature was a prime example. I’m not familiar with the product. And rather than read the docs first, I like to try to figure it out as I go and then return to docs to see what/if I missed anything, as that actually helps me learn the ins and outs of things a little better.
For example, this was the flow of my OnCommand Insight EMU journey…
- Build the OCI server; realize the version is out of date
- Upgrade OCI; realize the Windows server needs to update
- Work on other stuff while it updates
- Figure out that the EMU is a separate client that feeds into OCI
- Build the Linux VM with the defaults
- Install EMU; watch it break spectacularly
- Fix the first error (increase the hugepage value); get a second error (/var/crash isn’t large enough)
- Try to fix the 2nd error by making /var an NFS mount – watch the entire VM blow up (lol)
- Re-build the VM with a large enough /var partition
- Re-install OCI EMU
- Get a new error about unsupported NICs; find out there’s an undocumented requirement for something called DPDK
- Start trying to figure out how to get DPDK to work
- Mind explodes
In the midst of this process, I had a context switch (aside from this blog). In this case, it was when you run the oci-install.sh script for EMU. When it’s done, you get a banner that looks like this:
Well, isn’t that fun!
In my context switch, I thought it’d be cool to split out the big blue NetApp N and turn it into it’s own script. So I stripped out the OCI-specific stuff and did this:
if [ "X$myterm" == "X" ]; then
local color_count=`/usr/bin/tput -T $myterm colors 2> /dev/null` || true
# if the terminal supports it, draw a blue NetApp logo
if [ "X$color_count" != "X" -a $color_count -gt 0 ]; then
blue=`/usr/bin/tput setab 4`
So now, you can take that code snippet and add it to your own banners for login, such as if you have an SSH host that controls NetApp logins. You can also find the code here:
The finished product looks like this:
Is it simple and stupid? Sure. But while I worked on that, I came up with a few ideas to try to fix my DPDK issue!
All the articles about context switching and productivity point to reduction in how much work you get done. But for me, taking a break and working on other stuff when I get stuck can be a good way to get back on track.
Stay tuned for more on the OCI EMU module!