{"id":1268,"date":"2009-11-02T08:51:32","date_gmt":"2009-11-01T22:51:32","guid":{"rendered":"http:\/\/nsrd.wordpress.com\/?p=1268"},"modified":"2009-11-02T08:51:32","modified_gmt":"2009-11-01T22:51:32","slug":"why-nsrtmp-is-wrong","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2009\/11\/02\/why-nsrtmp-is-wrong\/","title":{"rendered":"Why \/nsr\/tmp is wrong"},"content":{"rendered":"

On both Windows and Unix platforms, NetWorker maintains a “tmp” directory within nsr.<\/p>\n

This directory contains a variety of information, from output received by savegroup completion notifications to lock\/state files for certain NetWorker resource.<\/p>\n

To first explain why \/nsr\/tmp is wrong, let me first tell you a little story about the first system administration team I joined. They rigorously followed RFC-1178<\/a>, and it’s ever since then that I’ve also done my best to follow that RFC \u2013 I’ve even written an article here on the blog about choosing appropriate names for backup servers. Sometime before I joined the team, they were in the process of setting up a replacement DNS server for local datacentre. There was either a dispute about what to name it, or it was only meant to hang around for a short while, but for whatever reason, it was named tmp<\/em>.<\/p>\n

I worked in the group from 1996 through to 2000, and from what I heard, it wasn’t until several years after I left that tmp<\/em> was decommissioned.<\/p>\n

One of the most valuable lessons I took away is name things appropriately<\/em>. The DNS server tmp<\/em> was not named appropriately. Thus, the name tmp<\/em> or temp<\/em> should be used only for transient<\/em> data or systems. (To this day I never give machines names along the lines of ‘tmp’; the closest I’ll go is naming them after synonyms to do with trash or garbage \u2013 meaning that I’m fully aware that at any moment they can be blown away.)<\/p>\n

To return to our topic, \/nsr\/tmp is wrong<\/em> because it’s misnamed. Temporary files only make up some of its content. Other files, state files, can hang around between restarts of NetWorker and (particularly if NetWorker was incorrectly shutdown) give backup administrators really bad days<\/em>. In fact, the “magical random” nature of \/nsr\/tmp is so well known that it’s actually started to really bug EMC engineering. My understanding is that engineering want the contents of \/nsr\/tmp captured any<\/em> time an EMC support representative tells some to shutdown+delete+restart so that if it does<\/em> fix the problem, they can try to debug why<\/em> and remove the need.<\/p>\n

The problem with shutdown+delete+restart is that in doing so, you clear out other information as well. Selectively deleting “the right file” can sometimes be a bit of a needle in a hay stack operation, and I suspect that debugging these deletes post-event will either be frustratingly slow or a bit like whack-a-mole.<\/p>\n

Architecturally, to include both state and temporary files in the same common directory structure is silly. Having a few extra directories in the ‘nsr’ base directory on the other hand is a minor change. I’d suggest that more improvements might be made by first actually splitting \/nsr\/tmp into:<\/p>\n