Comment Ben Rafanello responds (Score 5) 195
First the easy ones:
I wonder if this is some pie in the sky vision or if they have any code to back this up?"
Yes, we have code. IBM has a prototype of this LVMS on at least one of its platforms that I know of.
As long as it's released under a liscense like the GPL, we don't need to trust them
We are currently releasing the technology to the Linux Community. The current white paper provides a high level view of the basic architecture. As the architecture is discussed with the Linux Community, additional white papers will be produced to explain, in greater detail, various aspects of the architecture. Should things progress to the point where we are actually releasing code for some or all of it, then any code we release will be under the GPL.
Heinz Maulshagen and team have already written an LVM for Linux. This LVM is already in the 2.3.x series of kernels. What is IBM's reasoning for this duplication of effort? Might it not be more effective to assist in the current LVM implementation instead of bringing additional complexity? Or are there advantages in IBM's approach to logical volume management?
Heinz and his team have done an excellent job with their LVM. However, we feel that our design has some advantages, and that we are looking at the problem from a different perspective. Let me explain.
IBM's initial concept of a logical volume management system was not all that different from what we find in the Linux Community today. However, over the years, IBM's concept has evolved based upon input from our customers, as well as usability studies performed on our customer base. Our current concept of a logical volume management system integrates disk partitioning and management, bad block relocation, software RAID, encryption, filesystems, logical volume creation, deletion, and management, etc. into a single, coherent, open ended architecture. All of the components of this architecture communicate with the Logical Volume Manager, who co-ordinates their activities and handles all interactions with the user. The Logical Volume Manager is a single program with three interfaces: a command line interface, a text mode interface, and a graphical user interface. Thus, there is a single place for the user to turn to for any aspect of logical volume management. This makes logical volume management easier for the user to learn and use, and it reduces the chances for user error and data loss.
As an example of IBM's concept, lets examine the case where an encrypted volume is to be shrunk. We will assume that the user has already been through any authentication process which may be required to access the encrypted volume and has been granted full access. The user would start the LVM. The LVM would allow the user to select a volume. Once selected, the user would indicate that the volume should be shrunk. The LVM would examine the volume, find which features are in use on the volume (encryption, in this case), find what filesystem is in use on the volume, and then ask each feature that would be affected by the shrink if that feature can handle having the volume shrunk without data loss. If a feature indicates that it can NOT handle having the volume shrunk, then the LVM informs the user that the volume can NOT be shrunk without data loss. If all of the features indicate that they can handle having the volume shrunk, then the LVM would ask the filesystem on the volume how much the filesystem can be shrunk without data loss. If the filesystem indicates that it can't be shrunk without losing data, the LVM will inform the user appropriately. If the filesystem can be shrunk, it will indicate how much it can be shrunk before data loss begins. The LVM will then present this value to the user and allow the user to specify how much to shrink the volume by, limiting the user's choice to only those values that prevent data loss. Once the user has specified how much the volume is to be shrunk by, the LVM will then notify the filesystem to shrink itself. Once the filesystem is done shrinking itself, the LVM will notify the features on the volume that the volume is about to be shrunk. After this, the LVM will actually shrink the volume. Once the volume has been shrunk, the LVM will notify the features on the volume that the shrink has been completed. The filesystem will also be notified that the shrink has been completed. Once all of this has been completed, then the user will be notified that the volume has been successfully shrunk.
The above example is quick and dirty, and it leaves out quite a bit, but I hope it gives you an idea of what we are trying to accomplish. Basically, we are trying to bring together all of the various aspects of logical volume management into a single, cohesive, seamless entity. Furthermore, we are trying to do this in a way which is as flexible and expandable as possible. Consider the following:
The LVMS architecture uses logical disks. Logical disks are created and controlled by plug-in modules called "Device Managers". Thus, anything that can be made to appear as a logical disk through the use of a plug-in "Device Manager" module can be used by the LVMS. As an example, lets say we have a "Device Manager" plug-in which can access a Storage Area Network (SAN). By just adding this plug-in to an existing system, the LVMS would be able to allocate storage on a SAN, make it appear as a logical disk, and then use any of the LVM capabilities that could be used on a local disk. No code in the LVMS, existing plug-in modules, or LVM utilities needs to be modified or changed.
The LVMS Architecture uses logical partitions. Logical partitions are controlled by plug-in modules called "Partition Managers". If you wanted to access a drive that was partitioned for use with a Mac, you would just need a "Partition Manager" plug-in module that understands the partitioning scheme used by the Mac. No LVMS, existing plug-in module, or LVM utility needs to have its code changed. All that needs to be done is have the Mac "Partition Manager" plug-in added to the system.
The LVMS Architecture employs something we call "Feature Plug-ins". Feature Plug-ins control how logical partitions are combined into logical volumes, such as through drive linking, the various forms of mirroring, or software RAID. They can also be used to filter I/O to a volume, as would be the case for encryption. They can also be used to redirect I/O, as in the case of bad block relocation. Furthermore, Feature Plug-ins can be stacked to produce a volume, so that multiple Feature Plug-ins can be used on a single volume (encryption combined with software RAID and bad block relocation, for example). Every volume in the system can employ different Feature Plug-ins, and volumes which do use the same Feature Plug-ins can have them stacked differently. Thus, the user has an enourmous amount of flexibility. One final point to make here is that, since all of the plug-in modules communicate with the LVM, the LVM can coordinate their activities to ensure that the user doesn't do something which will result in the loss of data (at least without adequate warning).
Given all of the above, I hope everyone understands why we think the LVMS Architecture we are releasing has some advantages over other approaches.
Well, this post has gotten excessively long, and I apologize for that. I will try to address additional questions/comments/concerns later, hopefully with smaller posts!
Ben Rafanello
IBM Linux Technology Center
