Disk layout planning is still a good idea. The trick is making sure your applications respect your plans.

In spite of a growing trend against the practice, I still partition servers. I carve out allocations for swap, /var, /opt, /usr, and so on. In some cases I will even specify exact cylinders that I want a filesystem to occupy. The layout is specified in the early planning stages, and then plugged into whatever automated installation mechanism I need to use.

I won’t plan partitions for workstations with limited local disk use, or non-critical hosts that are virtualized in some form or another. In those cases, it may not make a difference to the longevity of the host, and if necessary I can always make changes later on without affecting critical services.

The whole point of partitioning is trying to make the best use of the space that I have available. Another benefit of partitioning is preventing applications from treating the disk like an endless playground of free space. If I don’t partition filesystems, I run the risk that an out of control application could affect other applications on the host, or even the OS.

I also follow the SVR4 filesystem filesystem standard. According to that standard, unbundled applications should go in /opt. Configuration files should go in /etc/opt. Spoolfiles, logs, and miscellaneous datafiles should go in /var/opt.

Despite my efforts in planning, I installed an application last week that gave me problems with my partitioning layout. I won’t name names, because the issue is mostly resolved, and this isn’t the only application out there that has this problem.

The installer asked for filesystem directories to store the application and data; and it asked for a throttle limit to prevent the data from growing too large. I had a 30+ gig /var partition, and a 4 gig /opt partition. I told the application to build the application in /opt, stick the datafiles in /var/opt, and set the throttle limit to 6 gigs.

The installation completed without errors, but the application didn’t run correctly. After some debugging with a support tech, I learned that the application didn’t respect my wishes to place the data in /var. It created a /var/opt/appname directory during installation, but the internal configuration still expected the datafiles to be stored in /opt/appname/var.

I had to edit the configuration file to set the correct directory, and I also had to reset the throttle limit to 2 gigs. Even through the data was being written to /var, the disk utilization routine would only check the free space remaining on the /opt filesystem. And since /opt was only 4 gigs in size, it could never have 6 gigs free. So, the application never wrote any data at all.

Unfortunately, that means my /var filesystem could still fill up, because the application is not checking in the right place. The application also writes logfiles to /opt/appname/var which means I run the risk of having two partitions fill up.

I consider the matter to be fixed, or at least working for now. The developer said the problem would be addressed in a future release, so I’ll keep checking for updates.