dd if=/dev/random of=/dev/blog

It still amazes me to see storage administrators bringing the same Microsoft Windows mentality to the UNIX and Linux environments. That is, after changes to a configuration are made “reboot the console to view all changes.” Now while Microsoft Windows does a fairly decent job of updating any changes made to the SCSI Subsystem, UNIX and GNU/Linux still handle it somewhat differently. Rebooting the console should be the LAST thing anybody does. These operating systems are so modular that in most cases there is absolutely no need to reboot; unless you have made changes to the kernel. If you are working in a production environment, down time can mean lost time which results in lost revenue. So when you update your SAN, how do you manage your storage configuration changes on your GNU/Linux 2.6 and Sun Solaris hosts?

GNU/Linux

There is a noteworthy variable in the SCSI Subsystem designed on the Linux 2.6 kernel, which some may find it to be problematic. Although I believe that this is how it should be. That variable lies in the Lower-Layer of the Subsystem where the Host Bus Adapter (HBA) modules reside. While it is true that the Linux 2.6 kernel supports hotplugging which includes SCSI devices, the HBA modules are designed in such a way which would lead a novice storage administrator to believe otherwise.

For example, let us say I am working with Fibre Channel (FC) devices and I use a Qlogic, Emulex or LSI FC HBA. I have Logical Units (LU) mapped to the Fibre Channel Node Ports on the host’s HBA. So when I insert my modules for a Qlogic qla2340 (qla2300/qla2xxx), all Logical Unit Numbers (LUN) are recognized by the SCSI Subsystem and immediately udev assigns them the appropriate node names (/dev/sda, /dev/sdb, etc.). At least through the FC HBA, if the LUN mappings change and I add/remove devices, the HBA will not report any changes to the host and therefore the SCSI Subsystem is not updated. There are a few methods to getting the HBA to report changes to the GNU/Linux host, one of which is a reboot (which provides the same functions as the next method). The second is to reload the module and have it report the latest LUN mapping(s) to the SCSI Subsystem while the third, being the most appropriate of methods, does not require any downtime. It takes a simple command. To add a device:

And to remove it:

Where 1=host; 2=channel; 3=id; 4=lun.

In the SCSI portion of the kernel source, the file drivers/scsi/scsi_proc.c has a function routine that takes these inputs and after parsing them, it will eventually verify that the target being added/removed is a valid one and the action is then performed. That function routine is:

Sounds simple, right? It is. No reboot or re-insertion of the module is necessary. Now I mentioned earlier about how I would prefer this method over a more dynamic approach as is seen in Microsoft Windows. Allow me to explain. When your hosting storage for an enterprise environment, anything outside of a static configuration can produce hazardous results. A great example was when I was working with LSI Logic to correct an unimplemented functionality which allowed for the disabling of hotplugging in their Serial Attached SCSI (SAS) HBA device drivers. To my knowledge those patches I submitted are still implemented to this day. Without the administrator’s knowledge, whevener the storage configuration gets updated even with flaky symptoms (i.e. a drive drops offline and back online again), it can bring down an entire server. Let us say I have 2 LUNs mapped which udev desingated as /dev/sda  and /dev/sdb. I mount these devices as /mnt/mnt1 and /mnt/mnt2. Now let us say that the hotpluggable feature incorporated into the HBA’s device driver is enabled and for some reason something happens and the LUN that has been allocated to /dev/sda drops offline for a few seconds. Who knows the external storage controller may be acting up. It happens all too frequently which is why Multipathing with Failover capabilities is a must. The mount path associated with that device (/mnt/mnt1) is still mounted and holds /dev/sda, preventing udev from removing the node. Meanwhile the SAS HBA realizes that a “new” drive (i.e. the drive that momentarily dropped offline) has been recognized and goes through the usual process to make the device accessable by the host. Now, wait a minute, /dev/sda is still taken and mounted to /mnt/mnt1. What happens now? A new device node is allocated: /dev/sdc and the path to the drive changes. The /mnt/mnt1 mount must be removed and /dev/sdc would have to mount to it instead. But the administrator still does not have any knowledge of the change. At least not until he/she reviews the kernel logs and notices nothing but SCSI Disk I/O errors when the original node was attempted to be written to.

Now there are ways around this, that is by working with udev and making specific devices with specific attributes lock to a specific device node. When hotplugging is not a feature or it is disable and a device drops offline for a quick moment, no changes to the configuration are reported to the SCSI layer and when it comes back online, it resume its original role.

Sun Solaris

Now working with Solaris is a bit different. Let us now say that you changed your SAN configuration and whatever has been mapped to your Sun box’s FC HBAs has been modified. Sometimes it is as simple as running 1 command. At the command prompt you would first type:

This will update all changes in the SCSI layer. So now when you type format, your new devices will appear. And what if they don’t? The very handy utility luxadm comes into play. First list all of your HBA ports and their status:

The function traverses through the /devices path (this is similar to the Linux /sys path of sysfs) and produce a list of results that look similar to this:

Now what you would want to do is force a lip (FC terminology) through each FC node.

Type format again, and now you SHOULD see the added disk device(s).

Earlier today I came across a blog entry from an employee of Sun Microsystems. He addressed the frustrations of the many worldwide when it came to running much needed applications that were built only for a Microsoft Windows environment. As some of you may already know, the reality is that not everyone runs Microsoft Windows as their operating system and in other cases, some of those same people may have a dual boot set up but rarely if ever boot up into the Windows partition unless it is absolutely necessary.

The author spoke specifically about a topic I too had many problems with and it related to protocol analyzers. Working in the storage industry, a SCSI, Fibre Channel or SAS analyzer is a must have tool. The problem lies with the fact that the providers of such solutions (Lecroy, Finisar, etc.) develop the hardware management and trace viewing interfaces for Windows ONLY! No Mac OS X. No BSD or Linux versions. No Solaris. Why!?! As I had mentioned in numerous earlier posts, IDC reports show that UNIX + Linux combined own more of the enterprise market than Windows. Are these companies just too lazy or do they lack the skill-set to provide something on anything else other than Windows? Do they not see any money in it? If I work for a UNIX only solutions provider, the last thing I would want to do is install a Microsoft Windows console to do any work.

Well, rants like this make me all the more happier in being able to provide the solutions that people like this author are looking for; that is, SCSIGen v2.0, which is still in development and coming to a POSIX compliant platform near you!

It pains me to write this post but being in the storage industry I have had a significant exposure to Microsoft operating systems. If you have read any of my previous posts, you would know how I feel about Microsoft in the enterprise arena but if you are in the unfortunate situation of having to work with Microsoft Windows on top of your storage equipment, here is some helpful pointers to aid in tuning that node. Also please reference my earlier post on tuning your Linux 2.6 host for detailed information on some storage concepts. The following Windows variables are accessed through the Windows registry.

The SCSI target timeout value can be viewed and modified at HKLM\System\CurrentControlSet\Services\Disk\TimeoutValue. It takes a value of 1 to 255 seconds. Off of the top of my head I cannot recall what this value is defaulted to, but believe me when I say this: there are times when you may need to go as high as 255; for the return of an I/O transfer. When I used to work for Xyratex, their latest series of storage RAID controller (based on the nStor Wahoo technology) did not have an appropriately implemented cache. It was more of an intelligent buffer which temporarily stored data contiguously until the schedular made its way to the scene. So when you were configured with multiple LUN devices mapped to your host and initiated I/O to those same targets, it could have take as high as 255 seconds for the I/O to return to the SCSI laye thus eliminating the countdown to the timeout. If it were to timeout, as is the case with any OS, an Abort Sequences would be initiated to abort the I/O transfer.

I mentioned the MaximumSGList in a comment to an earlier post. This is found at HKLM\System\CurrentControlSet\Services\ [HBA Name] \Parameters\Device\MaximumSGList. The supported values are 16 to255. Setting it to 255 sets the maximum of 1MB and if you go over 255 (like 256) it will default to 64KB.

If you are a developer and need more bytes allocated for sense data (on the return of the SCSI command), you would have to modify the following field: HKLM\System\CurrentControlSet\Enum\ [Bus] \ [ DeviceID] \ [Device] \DeviceParameters\ScsiPort\TotalSenseDataBytes. According to Microsoft, the supported values are: “Between 18 and 255 for SCSI Port. Storport always uses 255.”

Some other extremely important variables are actually tuned on the HBA itself. For example, the queue depth which is sometimes referred to as throttling (by Qlogic) controls the amount of outstanding I/O transfer a LUN is limited to. Other variables include various retry counts and more. So please review the documentation to the HBA you are using.

Caution needs to be taken when modifying all of these values. You will need to understand the environment the host is being configured in and that also includes the I/O profile coming from that same host(s). If you set the queue depth too high and the host is sending out more I/O transfer than the storage controller can handle, the storage controller will either abort those commands or depending how it is configured send a BUSY status back to the initiator.

So there! I did it. <sigh>

Not too long ago, I was assisting someone by configuring a few Sun Solaris nodes to resolve to a DNS server. It dawned on me that this could be a nice tutorial to discuss here. Note that I have only used this method on Solaris 8, 9 & 10 and have yet to attempt it on OpenSolaris. When that has been tried, I will update this post with the appropriate information. In my experience, I have yet to see OpenSolaris deployed on an enterprise level. It may still be too new for adoption. The mentality is usually, “if it is not broken, then there is no reason to fix it.”

The OpenBoot PROM:

I am more accustomed to working from a Sun SPARC system utilizing a Sun Microsystems keyboard but the same can be done without it as long as one knows how to enter the OpenBoot PROM. Using a Sun keyboad, you simply press “Stop + A” and let us say you are in the ALOM (Advanced Lights-Out Manager), you would type “#.” and if you are booted into the OS, open up a command terminal and type “halt”. There are numerous ways to access the OpenBoot PROM, so please reference the user’s guide to verify which method you must invoke.

If the OS is not installed:

Place the first disc in the series into the CD-ROM drive and type “boot cdrom” at the OpenBoot PROM. The host will start reading the CD-ROM drive.  Follow all necessary steps until the installation process scans system disk information.  This is where the OS attempts to find a location to accommodate a temp copy of the installation software.

After this, the host will reboot and when it does continue with a Networked installation, using DHCP and a DNS Name Service ONLY under the desired domain name. Continue with the installation until it is completed.

After the OS is installed:

Boot into the OS and edit the following files:

1.  /etc/nodename: edit or create this file - it should contain the hostname only      ex) sunbox
2. /etc/hostname.<interface>      ex) /etc/hostname.hme0 - this file should contain “inet <hostname>” only without the quotes and the hostname should be the same as the hostname in /etc/nodename file. So in this example it would read: inet sunbox
3. /etc/hosts: edit the line where it says unknown next to the IP address of your host to the hostname.domain hostname.
   ex) 10.96.42.1        sunbox.hydrasysllc.com sunbox

Reboot the host and it should resolve to the server properly.

According to recent IDC reports Microsoft does not own the enterprise market; favoring UNIX and Linux Operating platforms (read below). Although one needs to be reminded that it is not Microsoft’s primary market. It is the end-user that Microsoft is concerned with and it has been that same market that has helped Microsoft get to the position it is currently in. But does that really matter?

Thanks to the many pioneers out there, such as Google, modern day computing had experienced a paradigm shift; and away from locking the computer down from outside threats and installing and running every application/service locally. Everything is slowly moving towards the cloud. In all reality, the only tool that is really needed is the web browser. Almost everything is done or can be done on the internet. What matters of course is what is running behind the cloud.

Lately I have been paying careful attention with how the economy has impacted the data storage industry and I have tried to understand why certain technologies have remained somewhat unaffected during these times of trials and tribulations. I have also been attending technical seminars and summits to realize what the focus has been directed toward: Virtualization + Consolidation + Reduced Cost = a lean, mean and GREEN machine.

For example, the Red Hat Road Tour literally focused its Operating platform presentations on nothing but virtualization and simplicity. The simplicity included the ability to manage all node from a centralized service to even (at a click of a button) configure, update and enable all nodes within a cluster. It is amazing at what the Linux Operating Platform has turned into. I started using Linux back in 2002 (Red Hat 7.3) and back then the focus was more on stability and security rather than user-friendliness. Well, now the tables have turned and I can admit that the Linux Operating System has gotten it right in terms of being graphically appealing and user-friendly. It has even forced Microsoft to redefine their graphical environment in both Windows Vista and Windows 7. Although I have heard of recent problems in Microsoft keeping these new Operating Systems stable. Who knows if it will enter into the enterprise market anytime soon.

In a previous post I had mentioned:
———————————————————————–
…recent reports have shown that year-after-year the Linux Operating System has taken a firm hold in the overall enterprise market. As of 2008 it had been holding a share of at least 13.4% (according to recent IDC reports). UNIX Operating Systems on the other hand report 32.7% usage in the same market. Combined (46.1%), Linux and UNIX out-weigh Microsoft’s share of 36.5%. I am filled with joy when I see that every year Linux increases its share by an average of 10%. With leaders such as Red Hat, Novell and Canonical, I see an even stronger future for the Linux Operating System.
———————————————————————–

I feel confident that we will continue to see the influence of Linux rise. In recent articles it has even been noted how interoperability with other platforms including Windows is still a concern for Linux vendors. The focus to providing a complete enterprise class solution is there on the one side but what is really happening on the other? Do we know?

Microsoft has also recently begun to show a more humble side (maybe with some sneaky motivation behind it) by admitting how superior Apache is to its IIS web server and sponsoring the project. And face it, a significant number of applications have moved towards the usage of open-source and freely distributed variants. I see Apache over IIS and mySQL & postgreSQL over SQL Server. End users are now aware of Mozilla Firefox and choose it over Internet Explorer. In the end, the only thing that truly matters is what is serving those clouds. The Operating Platform utilized by the average end user may eventually become transparent where there will be absolutely no reason to care about which operating system someone is running. This can create a great future for Linux. The recent adoption of the sub-notebooks and other related forms of computing have gained more grounds for Linux. This new form of computing has even threatened Microsoft by forcing them to rebuild Windows Vista into Windows 7 which is now faster, less power and memory hungry and a lot more lightweight than its predecessor while also extending the life of Windows XP.

As for consolidation, the only storage-based vendors to truly survive the market have been the providers of affordable Storage Appliances (i.e. EMC, Netapp, etc.). On the back-end you are managing your SAN while on the front-end you are serving HTTP, FTP, NFS and CIFS shares all from a couple of decent performing nodes. In smaller environments, this reduces the overhead of cost, space and power to run multiple blades in order to accomplish the same task(s). These NAS solutions in turn utilize a FreeBSD or Linux embedded Operating System.

So in the end, does Microsoft even matter?

There are certain topics that never cease to amaze me when I work closely with storage administrator to even developers and QA engineers. Some of those topics are very specific to host side storage tuning. That is, there have been many occasions when certain knowledge in the storage industry has never been acknowledged and taught. Eventually bad practices develop which can eventually lead to disastrous results. It becomes even worse when you get into operating platforms that many may not necessarily be accustomed to such as Linux and UNIX. This blog entry focuses on some SCSI Subsystem details for the Linux platform.

A Closer Look at the Linux 2.6 SCSI Layer:

In Linux, the SCSI Subsystem exists as a multi-layered interface divided into the Upper, Middle and Lower layers. The Upper Layer consists of device type identification modules (i.e. Disk Driver (sd), Tape Driver (st), CDROM Driver (sr) and Generic Driver (sg)). The Middle Layer’s purpose is to connect both Upper and Lower Layers and in our case is the scsi_mod.ko module. The Lower Layer is for the device drivers for the physical communication interfaces between the host’s SCSI Layer and end target device. Here is where we will find the device driver to the HBA. Reference image below:

Whenever the Lower Layer detects a newer SCSI device, it will then provide scsi_mod.ko with the appropriate host, bus (channel), target  and LUN IDs. Depending on what type of media the devices are would determine what Upper Layer driver will be invoked. If you view /proc/scsi/scsi you can see what each SCSI device’s type is:

The Direct-Access media type will utilize the sd_mod.ko while the CD-ROM media type will utilize the sr_mod.ko. Each respective driver will allocate an available major and minor number to each newly discovered and properly identified device and on the 2.6 kernel, udev will create an appropriate node name for each device. As an example, the Direct-Access media type will be accessible through the /dev/sdb node name.
When a device is removed, the physical interface driver will detect it from the Lower Layer and pass  the information back up to the Upper Layer.

Tunable Components:

There are multiple approaches to tuning a SCSI device and the more complex approach involves the editing of source code and recompiling the device driver to have these variables hard-coded during the lifetime of the utilized driver(s). That is not what we want, we want a more dynamic approach. Something that can be customized on-the-fly. One day it may be optimal to configure a driver one way and the next another.

Optimizing the Disk Device Variables:

The 2.6 Linux kernel introduced a new virtual file system to help reduce the clutter that became /proc (for those not familiar with the traditional UNIX file system hierarchy, this was originally intended for process information) with a sysfs file system mounted at /sys. To summarize, /sys contains all registered components to the Operating System’s kernel. That is, you will find block devices, networking ports, devices and drivers, etc. mapped from this location and easily accessible from user space for enhanced configuration(s). It is through /sys that we will be able to navigate to the disk device and fine tune it to how we wish to utilize it. After I explain sysfs, I will move onto to describing modules and how a module can be inserted with fine-tuned and pseudo-static parameters.

Let us assume that the disk device that we want to view the parameters to and possibly modify is /dev/sda. You would navigate your way to /sys/block/sda. All device details are stored or linked from this point for device node named /dev/sda. If you go to the device you can view time out values, queue depth values, current states, vendor information and more (below).

To view a parameter value you can simply open the file for a read.

Here we can see that the timeout value for the SCSI labeled device is 60 seconds. To modify the value you can echo the new value into it.

You can perform the same task for the queue depth of the device along with the rest of the values. Modifying the disk device values in this way is unfortunately not maintained statically. That means that every time the device mapping is refreshed (through a module removal/insertion, bus scan, or a reboot) the values restore back to their defaults. This can be both good and bad. A basic shell script can modify all values to all desired disk devices so that the user does not have to enter each device path and modify everything one by one. On top of the basic shell script a simple cron job can also validate that the values are maintained and if not it can rerun the original modifying shell script.

Another way to modify values and have them pseudo-statically maintained is by inserting those values within the module itself. For example if you do a modinfo on scsi_mod you will see the following dumped to the terminal screen.

The appropriate way to enable a pseudo-static value is to insert the module with that parameter:

Or modify the /etc/modprobe.conf (some platforms use an /etc/modprobe.conf.local) file by appending an “options scsi_mod max_luns=255” and then reinsert the module. In both cases you must rebuild the RAM Disk so that when the host reboots it will load max_luns=255 into the insertion of the scsi_mod module. This is what I meant by pseudo-static. The value is maintained only when it is inserted during the insertion of the module and must always be defined during its insertion to stay statically assigned.

Some may now be asking, well what the heck is a timeout value and what does queue depth mean? A lot of resources with some pretty good information can easily be found on the Internet but as far as basic explanations go, a SCSI timeout value is the maximum value to which an outstanding SCSI command has to completion on that SCSI device. So for instance, when scsi_mod initiates a SCSI command for the physical drive (the target) associated with /dev/sda with a timeout value of 60, it has 60 seconds to complete the command and if it doesn’t, an ABORT sequence is issued to cancel the command.

The queue depth gets a little bit more involved in which it limits the total amount of transfers that can be outstanding for a device at a given point. If I have 64 outstanding SCSI commands that need to be issued to /dev/sda and my queue depth is set to 32, I can only service 32 at a time limiting my throughput and thus creating a bottleneck to slow down future transfers. On Linux, queue depth becomes a very hairy topic primarily because it is not adjusted only in the block device parameters but is also defined on the Lower Layer of the SCSI Subsystem where the HBA throttles I/O with its own queue depth values. This will be briefly explained in the next section.

Other limitations can be seen on the storage end. The storage controller(s) can handle only so many service requests and in most cases it may be forced to begin issuing ABORTs for anything above its limit. In turn the transfers may be retried from the host side and complete successfully, so a lot of this may not be that apparent to the storage administrator. It becomes necessary to familiarize oneself with these terms when dealing with mass storage devices.

Optimizing the Host Bus Adapter:

An HBA can also be optimized in pretty much the same fashion as the SCSI device. Although it is worth noting that the parameters that can be adjusted to an HBA are vendor specific. These are additional timeout values, queue depth values, port down retry counts, etc. Some HBAs come with volume and/or path management capabilities. Just simply identify the module name for the device by doing an lsmod or even traverse through /sys/class/scsi_host (it may also be useful to first identify it usually attached to your PCI bus by executing an lspci). And from that point you should be able to either navigate the /sys/module path or just list all module parameters to that device with a modinfo.

Additional Topics to be Aware of:

First and foremost, dependent on the method of connection between host(s) to target(s), load balancing becomes a big problem. How do you balance the load to all Logical Units (LU) making sure that all can get serviced within an appropriate time frame? Fortunately enough, there exists some great tools for the Linux platform that many utilize for both volume management, multipathing/load balancing and failover/failback needs. One such tool is a device-mapper used in conjunction with multipath-tools. In the past I have always used this and it has always served me extremely well, but be aware, that this set of modules must also be fine tuned to accommodate the type of storage you are utilizing.

It also becomes quite necessary to understand file system basics; that is basic structures and methodologies. For each file system is unique and can offer many positives and/or negatives in a production environment. Some things to consider with the file system are journaling methods, data allocation (block-based or extent-based on top of a B+ tree), write barriers and more. In regards, to journaling methods some file systems contain more than one method for journaling, some more reliable than others but they come at a cost with significant performance drops.

In order to fully and appropriately optimize all of these variables, the administrator must fully understand the I/O profile to which they are catering to. What limitations is our storage leaving us? Would I need to increase my SCSI timeout values in order to make sure that all I/O requests are fully serviced with little or no problems? What limitations does my HBA give me? How is the host accessing the end storage device (directly or in a SAN)? What about redundancy (path failovers), to make sure that there will be little to no down time on failures? How much traffic should I expect? How do the application work with the disk device(s)? What performance gains or losses do I obtain with Volume Management? These are just a few of many pressing question that an administrator must ask themselves when configuring and placing storage into production.

Conclusion:

Unfortunately this covers a fraction of what needs to be known to manage storage systems. Not too long ago I had written and published a PDF covering much more including the I/O subsystem, performance and development tips; please reference this PDF. Also here is a link to an excellent IBM article discussing the Linux SCSI Subsystem.

For the past couple of weeks I have been focusing my free time on continuing the development of scsigen v2.0. I am currently working on the Linux 2.6 version and it will be followed by Sun’s Solaris/OpenSolaris. Microsoft Windows and FreeBSD will come afterward.

From experience I have learned to always find out what the user wants or desires in features and functionality. I am not here to introduce a new industry but provide easy-to-use solutions that are contained in simple packages.  Project details are listed in the link provided above.

Now, to all storage administrators, developers and QA engineers out there: What features are you looking for in storage management solution?

Not only will this solution be provided across multiple operating platforms and architectures, it will provide the admin with (locally or remotely from either a CLI or GUI) the following features/functionality (listing of some of the major ones):

• Generate a detailed listing of SCSI initiator and targets
• View/edit host-side initiator and target parameters
• Generate raw Command Descriptor Blocks (CDB)
• Choose from a set of predefined commands to send to selected device(s): such as TUR, Inquiry, Sync, etc.
• Rescan/update the SCSI Bus and add and remove device(s)
• View Vital Product Data (VPD), Log Sense Pages, SES/SAF-TE information, etc.
• View/modify Mode Pages
• View/modify Persistent Reservations
• Flash device(s)/SES firmware
• View host-side SCSI related kernel logs
• Utilize the SCSITrace Bus Analyzer Module for problem isolation (host installed SCSI protocol analyzer/viewer)
• Replay captured I/O traces for reproducibility
• Generate automated environments (for both SCSIGen and SCSITrace)

If you have any ideas or suggestions on what you may need in a storage management solution, please share and if it is possible to integrate it within the scsigen suite, then you will not need to look any further (or at least when the initial stable versions are released).

In the beginning, there was ed.
Ed is the standard text editor.
Then there was vi, and it was good.
Then came emacs, and disharmony.
               -Extract from intro to Word War vi

In 1976 one man changed the face of text editors. That man is Bill Joy who developed vi for BSD UNIX. To those who are a bit unfamiliar with command line UNIX/Linux, vi (short for Visual) is a screen-oriented text editor that operates in two modes: insert mode and normal mode. Please reference here for a deeper explanation of its design and implementation.

I was first introduced to vi when I started working with FreeBSD back in 2001 and continued to work on it when I started to play around with Red Hat Linux 7.3 in 2002. Once I started to understand and get more comfortable with vi, there was no turning back. Seriously! All those vi/emacs fanatics out there know exactly what I mean. Even in a Microsoft Windows environment I have to install Cygwin to get all of my much needed tools, which includes vi.

Today I utilize vim (Visual IMproved) but when I think about it, it constantly throws me back to what has been dubbed “the Editor War.” It was after vi that emacs came rich with its own features and functionality and then a “holy war” broke out. You were either on the side of vi or the side of emacs.

Just recently I had to go on-site to the campus of Fermi National Accelerator Laboratory (Fermilab) and when speaking with an applications development manager who knew I was extremely comfortable with POSIX-like platforms and architectures, he had asked me, “Emacs or Vi?” I simply replied, “Vi and grep, all the way.” He had a look of brief disappointment as he turned to a colleague of his next to him. She commented how she was on my side. That look of disappointment quickly turned to a look of betrayal. That passion still courses through the veins of many.

Now I ask you, which text editor would you prefer? Vi, Emacs, or other? And do you still feel the war in your daily life?

For the past many months I have been obtaining a lot of requests to pursue my development in my scsigen and scsitrace projects. Well, here is some good news for the new year, to all that are still interested: I have given in and I will be continuing to add more features and functionality to my previous projects. I am currently in the process of finalizing the architectural specs and development will start as soon as I finish gathering equipment.

To recap, scsigen was a low-level utility that allowed the user to directly access and communicate with the SCSI Subsystem of the OS. Original supported platforms were the Linux 2.6 kernel and Solaris 10. The functionality was limited to raw CDB generation along with start/stop drive and reset host/bus/target/all. I wish to not only extend the feature list but I also wish to support openSolaris and Windows platforms. I will be posting the v2.0 specification guide shortly.

As for scsitrace, I am trying to merge this into the scsigen suite. Its purpose is to provide software based protocol tracing and analyzing/replay capabilities. This project was supposed to grow above and beyond its current state and be ported into a pass-through external module. A few set backs with LSI Logic put it on hold. As for the external module, that is still on hold. I still plan to grow the local host software based solution though. Again, I will be posting a v2.0 spec for this entire solution suite shortly.

All this will be licensed under the GPLv2 and its source will be freely provided. Support and additional services is another story.