Previous Table of Contents Next


For NT, use the Server Manager to show the files in use, as shown in Figure 18.3, by following these steps:

1.  Click the Start menu and then choose Programs|Administrative Tools|Server Manager.
2.  Right-click the server you’re interested in.
3.  Choose Properties.
4.  Click the In Use button.


Figure 18.3  The Server Manager can show files (and other resources) that are in use on an NT server.


UNIX doesn’t have a standard file lock finder. You can find out who’s using the file system by using the fuser command (see the man page), but this won’t work on an individual file level.


My favorite thing to do when I’m updating a program is to not update it. Let’s say that I’m updating the NETTERM program, which lives in my G:\NETTERM folder. I need to put the new version out there for users. One of the methods I like to use (which doesn’t apply to all cases, but this is a simple application in this case) is to rename the old folder, which means I’m not updating the old program. Rather, I’m installing the new program in the same location. To keep the older version, I drop to a command prompt, and type the following:
   G:\> move netterm netterm.old
   G:\> mkdir netterm

If something goes wrong, and I need to quickly put the old stuff back, I can always type this:

   G:\> deltree netterm
   G:\> move netterm.old netterm

You could also do this through the Explorer, of course, but you get the picture. The benefit in this case is that the file locks don’t apply—I’m not updating the old app; I’m installing a new app into an empty folder.

The only caution here is that you need to go and assign the new folder the same security attributes as the old folder; otherwise, none of your users will be able to see it, much less use it.


The Case of the Missing Space

No matter how much disk space you have, it’s never enough, is it? Even though hard drive sizes have gone up considerably in recent years, the amount of multimedia being stored online has gone way up, apps have grown in size, and so have their data files. Particularly if you run an enlightened system without file quotas (well, NT doesn’t have that ability without third-party software), users can quickly eat up any disk space you throw their way.

In general, when you have acute “diskitis,” work tends to grind to a halt. It’s important to be able to identify the blockage and excise it quickly. (Novell users: See Hour 13, “NetWare Networking Basics,” for a tip on how to use the Monitor to find out quickly who’s using the space.)


I know system administrators who always hedge their bets—they either keep a hidden file out there that’s a couple hundred megabytes (which they can quickly delete if they get into a full disk situation), or they simply don’t dole out all the disk space at once.

Check your operating system manuals; there are ways to add disk space where it doesn’t show up immediately. You can also add space on-the-fly. In a nutshell, you can allocate the storage and add bits of it later. Very cool. (Under AIX, see the Logical Volume Manager; under Novell, see INSTALL.NLM.)


On a day that starts out without a disk space problem, it’s likely that your remaining disk space has been eaten by any of the following items:

  Large files created that day
  Large numbers of smaller files accumulated over a couple of days
  Large files created in the last couple of days, recently pushed over the edge by normal user activity

How do you find these? If you’re like most shops, you have thousands of files and hundreds of directories and subdirectories—wading through these unaided is nuts. Fortunately, you have automation tools to assist you.

Find

The find command in UNIX is my best friend. When faced with a space problem, I might type the following:

cd /full filesystem
find . -mtime -1 -print | xargs ls -lad | more

This means “find everything with a modification date within one day and print out its name with the size, a screen at a time.”

Alternatively, I might type this:

find . -size +2048 -print | xargs ls -lad | more

This finds everything that’s over 2048 blocks (1,048,576 bytes, or 1MB).

If nothing turns up, I try the first command with mtime set to 3 instead of 1. Something will usually turn up.

The Find tool in Windows is also pretty cool (see Figure 18.4). It allows you to search by date and size. Does this take a long time? Yes. This is why keeping a little bit of hard drive space on the side is probably a good idea.


Figure 18.4  The Windows Find tool’s advanced settings can help you track down large files (and, thus, disk space hogs).

Hey! Stop That Runaway Program

Sometimes finding the individual files doesn’t do you any good. For example, our UNIX system administrator and I came in one Monday morning to find the /usr file system full on the main UNIX system. We saw that most of the files that had been generated over the weekend were print spool files, so we stopped the spooler, deleted the queue jobs, chalked it up to a crazy user, and restarted the spooler. Fifteen minutes later, the file system was full again.

We looked at the spooler control files and saw that they all belonged to one particular user. We did a process list for her:

         ps -fu mary

We killed the lp process that she had been running, stopped the spooler, deleted the queue files, chalked it up to a crazy spool job, and restarted the spooler. Fifteen minutes later…

Apparently, the application she had been using to run a report had lost its mind, and it kept repeatedly printing the report over and over again. Once we killed all her processes, we were okay, but that was a pretty fun half hour.

Here’s the lesson: Just finding the files isn’t always enough; sometimes you need to find out why they’re being generated.


Previous Table of Contents Next