Over the past several years, I have grown quite fond of the ability to do bind mounts on Linux.
First, a little background. Most applications have specific directory structure requirements. Many have wildly varying space requirements depending on how a given install is utilized. For example, HPSA can use anywhere from 40-400-4000 gigabytes of space for its deployable Software Library, depending on a given customer’s individual needs. Likewise, the database can be quite small (under 15GB), or massive (exceeding 1TB) – again depending on usage patterns and use cases. Because of varying space and directory requirements, an old sysadmin trick is to use symbolic links to create fake directories so that an application can take advantage of the structure it needs, but the admins can keep their file systems structured they way they prefer (sometimes this is a side effect of various corporate IT standards).
This is cool because it allows all logs for all non-standard applications to be housed in a common locale.
The drawback is that if the application checks on the location of its logs and they’re not *really* at /var/log/appname, it may fail to start. When you look at the details of a symlink, it shows that it is merely a pointer to a different place, and is not, in fact, a directory. Eg, if you have a symlink at /var/log/appname that really points to a directory at /apps/logs/appname, a symlink does not have the first bit set to ‘d‘, because it is not a directory, is is set to ‘l‘. That can be a problem.
Without creating separate partitions for each application’s logs, after all that was why we have /apps/logs created, how can the dilemma be solved?
Enter mount --bind. Bind mounts take an existing directory path (which might be a mount point itself), and remounts it to a new location. Like this: mount --bind /apps/logs/appname /var/log/appname.
This also effectively treats the ‘from’ path as a partition.
And, since it *is* a directory, when the application checks on the location of its logs, it will not fail.
When combined with growable space (the subject of a future post) at /apps, this provides a very flexible approach to varied storage requirements for applications.
The final component of properly utilizing bind mounts is to add the bind to the file system table, fstab (/etc/fstab):
/path/to/orig /path/to/new bind rw,defaults 0 0
Specifically in the context of the tool I run on a day-to-day basis, HP’s Server Automation, here is what I will tend to do for a simple install, as it allows the flexibility to have any given sub-set of the product use as much space as it needs, without being overly tied to specific partitions and mounts points:
/dev/{device-name} /apps/hpsa ext3 defaults 0 0
/apps/hpsa/u01 /u01 none bind 0 0
/apps/hpsa/u02 /u02 none bind 0 0
/apps/hpsa/u03 /u03 none bind 0 0
/apps/hpsa/u04 /u04 none bind 0 0
/apps/hpsa/varoptoracle /var/opt/oracle none bind 0 0
/apps/hpsa/etcoptopsware /etc/opt/opsware none bind 0 0
/apps/hpsa/varlogopsware /var/log/opsware none bind 0 0
/apps/hpsa/varoptopsware /var/opt/opsware none bind 0 0
/apps/hpsa/optopsware /opt/opsware none bind 0 0
/apps/hpsa/media /media/opsware none bind 0 0
Next time I’ll cover strategies for storage allocation.