Wednesday July 13, 2005 Weblog
Wednesday July 13, 2005 A customer would never do that...
Not too long ago I was in a briefing where our marketing folks were providing data generated from visits to current and potential Sun customers. One of the items that was brought up elicited a response of 'A customer would never do that!" when I related it to a fellow engineer. Never mind that several customers had specifically told us they do exactly that, it was hard to believe because it didn't match up with this engineer's experience. Unfortunately most of us in development don't really have a good idea of how customers use (or would like to use) our products.
I won't go into detail on this specific instance because I'm not sure if that customer data can be shared outside of the company. However, I will use an example from a previous company I worked at to illustrate the point:
A previous employer of mine was also a UNIX systems shop, doing both the hardware and software. Loadable kernel modules hadn't come to this company yet, which meant that you had to build kernels specifically for the hardwdare you had installed in the machine. For a given machine you would install the OS with a generic kernel, then install the packages that contained the drivers for the specific hardware options present in the system. Once all the necessary packages were installed, you would build a new kernel on the machine and then reboot onto the new kernel to make all of your hardware functional. If you added a new piece of hardware later on, you would need to install the associated software package, rebuild, and reboot.
Installing the required packages was somewhat tedious, as the full set of packages spanned several 9-track tape reels. You didn't want to install packages you didn't need (due to the time required and limited disk space) so quickly identifying the correct reels was a big time saver. The order and number of packages per tape could vary quite a bit depending on what options were chosen when the tape was created, so installation could be a pain. We talked to the release folks to determine if there was something we could do to simplify life with the tape packages. Several options were discussed, but because "Customers get pre-installed systems and re-installs are very rare" the decision was made not to expend the effort to improve the process.
Sometime after that I was sent out to a customer site to assist the field engineers in the first installation of some brand new hardware. Once the system was physically put together, one of the field engineers proceeded to start a new install. "You don't need to do that," I told him, "It was preinstalled at the factory."
"I know," he replied, "but we've seen so many misconfigured systems that we never trust the factory install. When we put in a new system, we always reinstall from scratch."
And it got even worse. In talking to the site manager, I found that much of the time they loaded the machines with test versions of their database to run sanity checks to satisfy themselves that the new system was working properly. Once they were done, they would then typically re-install again from scratch to be certain that they'd purged all of the test setup before putting the machine into production.
So, while back in the R&D part of the company we thought that re-installs in the field were extremely rare, in reality many of the machines were installed twice at the customer site before going into production. And we didn't even have to go to a customer site to learn this, our own field support people could have told us. We thought we had a reasonable grasp on what customers did and good communication with our field folks but we were wrong.
One of the things I hope the OpenSolaris community can provide us with is a better connection to how people in the real world use or would like to use our products. We have a policy of "Eating our own dog food", or using our own machines to act as our mail servers, home directory servers, etc. While helpful, we've learned the hard way that how we set things up in a development environment is often very different from how it's done "out in the wild". The more channels we have for learning the customer reality the better, so hopefully comments from the OpenSolaris community will supplement and reinforce the information that gets fed back through marketing so that we can better design products that work the way people need them to.
Solaris ( Jul 13 2005, 01:15:47 PM PDT ) Permalink Comments [0]
Tuesday July 12, 2005 A bit of SVM history (answering Francis' question)
I finally realized I should check for comments on my blog and found that Francis Liu asked the following question back on June 19th (with regards to my RAID 0+1 vs. RAID 1+0 and SVM blog):
One question, is the desciprion true for all versions of DiskSuite. Or is it only true for SVM (ie Solaris 10 or OpenSolaris)? I've seen documents that say that this sort of thing only applies to SDS 4.2.1 with patches and later.
While I started working with DiskSuite for the 4.2.1 release, I know that the convoluted mirror/stripe interaction dates back to well before then. I arrived on the SDS scene in 1999 when development was ramping back up after a period of inactivity. Several years earlier Sun had closed down the Rocky Mountain Technical Center (RMTC) in Colorado Springs. One of the casualties was the SDS development group. At the time upper management seemed to think that continued development of SDS wasn't a good investment and so while the product continued to be available there wasn't ongoing development. This decision was reversed some time later, but as the vast majority of the RMTC engineers had left Sun an SDS development group needed to be restarted mostly from scratch.
I know that current mirror/concat/stripe paradigm existed in the SDS 4.1 release (which dates to before the dissolution of RMTC) and I suspect its roots go back much further than that. The mirror and concat/stripe devices are so intertwined that my guess is that they were designed together in the very early days of the code base that eventually became SVM. My understanding is that mirror/concat/stripe devices are the earliest ODS/SDS/SVM devices, followed later by trans devices (since discontinued in favor of logging ufs) and RAID5. Soft Partitions are a relatively late addition, being made after I joined the SDS team.
A bit more SVM history: The earliest references I've seen to the product refer to it as ODS (for "Online: DiskSuite"). At some point the name was changed to SDS ("Solstice DiskSuite"). In both cases the volume manager was an "add on" product rather than being built into Solaris. One of the major disadvantages of this was that upgrade didn't understand SDS metadevices, so if your system had a mirrored root you had to eliminate the mirror before upgrading and then recreate the root mirror after the upgrade. The decision was made to integrate SDS into base Solaris for the S9 release and the initial name chosen was Solaris Logical Volume Manager (SLVM, pronounced "sliv-em"). Before S9 actually shipped the decision was made to shorten the name to Solaris Volume Manager (SVM, or "siv-em"). While all the release docs were changed to show SVM instead of SLVM, a few references to SLVM persisted in error messages and comments in the code for some time after the S9 release before finally being eradicated.
I've heard that original base code for ODS/SDS/SVM was bought by Sun from another company back in the late eighties or early nineties but have never seen any confirmation of that.
Solaris ( Jul 12 2005, 05:02:09 AM PDT ) Permalink Comments [0]
