Too Busy For Words - the PaulWay Blog

I have just been configuring two machines at work for a SAN upgrade. The vendor has insisted we use their drivers and stick to particular kernel versions. Several delays have been encountered in their setting things up. E-mails and phone-calls were exchanged. Meetings were held, at which they explained how the upgrade would have to progress and I expressed my disbelief. Changes were raised.

The thing that I couldn't quite get past in the meeting was that the procedure for them to move from storage on one section of the SAN to another was as follows:

1. They create some new devices.
2. Reboot so that their driver can find the new devices.
3. Set up the sync process, one per device. You have to know implicitly which device you're going to be moving from and to. Enter 'yes'.
4. Start the sync progress, one per device. Enter 'yes'.
5. When that's finished, switch to the target device, one per device. Enter 'yes'.
6. Commit the changes, one per device. Enter 'yes'.
7. Complete the transaction, one per device. Enter 'yes'.
8. They then remove the old devices, which are now helpfully called the new devices.
9. Reboot again to make the old devices go away.

I think a WTF is called for at this point. Two reboots and a whole bunch of unscriptable manual commands to perform a change? An erudite friend of mine, wise in the ways of vendors, opined that they must do this for everything as part of some methodical procedure for making sure critical data was preserved at every stage. And I answered him with the words of the vendor, which were that Windows and Solaris can do this change automatically, and only Linux required this level of manual attention. I had questioned the process at the meeting and was told that it was all due to the drivers of the vendors of the fiber-channel cards and they would love to do it the intelligent way, really they would, but that those other vendors had made life too hard for them.

This gambit works successfully when the person the vendor is talking to is a manager or otherwise unfamiliar with the way Linux is developed. I at least pointed out that these drivers that they were complaining about were open source - they were freely available for the vendor to modify to support their esoteric requirements. At this the vendor's people shrugged and said that there was nothing they could do about this - which is true but useless. I don't know the details of how these things are constructed, so I really can't say how fiber-channel cards see their SANs or whether they can actually support hot-plug or not, so I can't really tell them source file and line to tell them otherwise. I know that SCSI wasn't designed for hot-plug, but then why is it using the SCSI bus if the devices support hot-plug? I don't know.

While I have been rebooting and waiting and rebooting on these servers for these devices to show up, I have meanwhile plugged a hard disk into my work machine, added its space to my main volume group, moved all the data off my old disk, reformatted the old disk, repartitioned it, put the /boot partition back and moved all the data back using LVM commands while the system was running. I thought I'd have to reboot at one point, but it turned out I still had /boot mounted and once I unmounted it I could rescan the partition table successfully. No reboots, no obscure proprietary binaries, no tainted kernels, no mysterious handwaves, nothing - just solid performance. And this is on commodity hardware! What is wrong with these people?

Oh, and in case you're wondering which vendor, there's a subtle clue somewhere in this document.