fighting the lack of good ideas

storage strategies – part 2

Continuing my series on storage strategies and options (see part 1), today I want to briefly look at SAN and NAS options.

First, storage area networks. SANs are “dedicated network[s] that provides access to consolidated, block level data storage”. Storage presented to a target server appears to the machine as if it is a “real” drive (ie, as if it were DAS) – which means it behaves exactly the same from the OS’s point of view.

Second, network-attached storage. A NAS is “file-level computer data storage connected to a computer network providing data access to heterogeneous clients”. Storage presented by a NAS host can be mounted on a target server, but won’t support being installed-to*, since the space is presented at a Samba or NFS share. A NAS device differs from a “mere” file server that happens to be publishing NFS or Samba mounts in that there are dedicated management interfaces for handling quotas, publishing policies (eg which protocols should be used for different network segments), etc.


  • flexibly-deploy storage “on-demand” to target machines
  • the storage appliance can be serviced – typically – while servers are utilizing it
  • with technologies like vMotion from VMware, storage can be migrated “live” from one device to another based on load


  • most expensive – though pricing varies widely depending on manufacturer, protocols exposed, size, redundancy, management interfaces, etc
  • dedicated storage technologies require dedicated storage admins over-and-above dedicated system admins to utilize and maintain properly

*The caveat here is if a NAS share has been mounted as a storage device for virtual machines through a hypervisor like VMware – then the vmdks could be stored on a NAS device, and the VMs will be running off the remote mount.

fixing copyrights

ars technica has a great article on some short-term, easy-to-implement fixes to the current copyright fiasco in the United States.

I have a bevy of thoughts on this myself, but not quite enough time today to write them down.

storage strategies – part 1

In follow-up to my previous article about bind mounts, here is the first in a series on storage strategies (while everything contained in this series is applicable to desktops and laptops, the main thrust will be towards servers). Today we’ll look at local/simple storage options (DAS – both the spinning and solid-state varieties).

The most basic form of utilizable storage is the direct-attached (or DAS) variety. In short, DAS covers any drives that are physically connected to a computer – hard drives, SSDs, etc.

Spinning disks, aka hard drives, are the most common form of DAS – and are extremely similar between consumer and professional levels (the only main differences are price* and guaranteed reliability): they’re a very mature, stable technology, and, excepting recent problems in Thailand, have been pretty cheap for a long time.

Depending on the server, there will be anywhere from 2-12 (or more) disk slots. If the disks are sized equally, they can be either added to a RAID (a topic for a future post on fault-tolerance), or used individually.

A more recent alternative to hard drives have been solid-state storage. SSDs use flash memory – which can be more fault-tolerant than disk drives because there are no moving parts. While, as with all devices, there is a failure rate with flash storage, it [generally] fails more gracefully than a spinning disk, as individual cells of the flash will wear-out/become inaccessible, rather than a platter  physically crashing.


  • “traditional” storage, which makes installation simple
  • storage performance can be easily isolated
  • generally-speaking, it’s the fastest storage option
  • cheapest storage option


  • if storage needs have been predicted too low, it can be costly and time-consuming to increase
  • if storage needs have been predicted too high, a server could be “wasting” lots of space
  • when failures happen, recovery can be a very time-consuming process

*There is an excellent question and answer on Server Fault that covers why costs of enterprise/professional storage are high, and I won’t rehash much of that information in this series.

professional lying – or is it laziness?

I have noticed an unusual percentage of professional CVs/work histories/resumes on LinkedIn (specifically) that have some fairly blatant errors in them.

For example, I have seen people list multiple full-time jobs that they could not have had at the same time (eg, both at one employer and also at the company that acquired their old employer).

I’ve also seen people claim to have accomplished things or be in a role that is either flat-out wrong, or worded in a weaselly way that looks like they’ve accomplished a lot more than they really did (eg showing only their current title at their current employer, but listing the start date as their initial hire date, and only listing their current accomplishments/roles (or listing all of them, but implying they did something that other individuals were actually responsible for)).

I’ve also seen LinkedIn profiles that are spartanly-populated – which is cool, that kinda follows my personal philosophy of never putting anything on my resume I don’t want to be asked about. But the ones that are full of – at the very least – questionable entries on their work history seem very troubling to me.

binding your mounts

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.

what are the odds

This morning I got stuck in an elevator for about 20 minutes during a power failure in the building.

The ironic part? It’s the elevator that my colleague and I had thought would be most likely to screw up because it makes funny noises, doesn’t always know what floor it’s on, etc.


groupon is no good!

I think I might have to boycott Groupon: a few months back they had a deal for an introductory flight, first ground school time, and pilot log book for about 50% off the normal rate from the local flight training company, NexGen Aviation.

I arrive at the airport a little before 1400 for my flight on Sunday. Adrian, my instructor, is an intensely friendly man. He’s originally from Zimbabwe, though has spent enough time in Kentucky that now his family think he has an accent 🙂

NexGen has a Piper Warrior – a four-place, low-wing, single engine airplane they use for lessons.

Things I did not know about operating an aircraft – you steer while you’re on on the ground with your feet.

Adrian opened the door and told me to get in first. That was not what I expected – that put me in the pilot’s seat. After doing a quick preflight, he started the engine, and we started taxiing… more accurately, while he radioed the tower for clearance, he had me taxi us out onto the runway.

So that was pretty cool .. but it got better: when we got to the runway, and the tower had cleared us, I got to take off =D

Adrian ran the throttle, and he took care of the trim tabs and explained to me what I had to do, but otherwise he let me fly for the about 30 minutes we were up – the only time he took over was for our landing. We toured around Lexington at ~2500 feet (buzzing up to nearly 3000 as I tried to maintain our heading, steer, look around, and keep us flying level-ish.

I got to see our house from 2500 feet, and a variety of other parts of Lexington that I think may help when it comes to driving, too.

Now for the bad news: I’m hooked. And the total time and outlay that getting my license will entail will be at least 40 hours of flying time (including different type of solo time), along with several hours of ground school. And all of that combined with needing to take a written test so the FAA will eventually be willing to give me a check ride so I can get my license.


That’ll run ~$6650 … if I go as quickly as I can. Taking too much time between lessons will help to reduce retention, so I’m probably more realistically looking at about $10k to complete my license.

I’m accepting donations, though 😉