This project is dedicated to giving the Logical Volume Manager a new user interface, something that it desperately needs.
The public part of this project mainly consists of the objectives and proposals outlined below. I originally wrote these several years ago, in the hope of attracting qualified developers to work on the project. It soon became obvious, however, that it was going to be incumbent upon me to do the lion's share on my own. I managed to implement objective #1 myself, but I lacked the necessary programming skills to continue on with the remaining objectives. I am hoping, however, that this will soon change; if so, this project may return to life in the reasonably near future.
Other information and resources about the Logical Volume Manager, including the developer's toolkit, are available on my main OS/2 LVM page.
IBM's interfaces to LVM are full of problems. Here's an overview of some of their particular offenses.
The interface is separated into two modes, "Physical View" and "Logical View". Each presents a sub-set of information about the disk drives, partitions, and volumes on the computer. However, this design makes it impossible to view all of the important information at once.
In order to understand the current layout (let alone manipulate it), the user must constantly toggle back and forth between the two modes.
The console version's clumsy visual highlights make it difficult to tell, just by looking, which panel is currently active.
This interface also pops up vast numbers of cascading window boxes when performing operations. Not only does this turn most operations into a torturous path of poorly-explained questions, but it creates needless visual clutter as well.
Worst of all, the interface does not produce any error messages if an operation is unsuccessful. The user is left futilely repeating the same command over and over, wondering why on earth nothing is happening.
The GUI LVM (written, for no apparent reason, in Java) is not only slow, inconsistent and unattractive, it also manages to completely ignore all the CUA user interface guidelines for OS/2 graphical applications. It uses custom controls which provide no advantage at all over the standard controls which they attempt to mimic, and which shouldn't be necessary even in Java.
And, as the icing on the cake, it is 100% exclusively mouse driven -- you cannot operate this program with a keyboard in any manner whatsoever!
The console interface to LVM (LVM.EXE) and the graphical interface (LVMGUI) have radically different user interfaces. So, not only must the user spend a great deal of time and effort in learning how to use the console version (which is necessary in order to install the operating system), he or she is then confronted with a graphical interface which looks, feels, and behaves in quite a different manner.
The first obvious difference is that LVM.EXE always starts in Logical View. This makes a certain amount of sense, since operations within LVM are supposed to be volume-centric. Unfortunately, LVMGUI always starts up in Physical View, for no apparent reason.
This problem is compounded by the fact that, while the Logical View in LVMGUI is roughly similar to that of LVM.EXE, the Physical View is completely different. So, the first thing the user sees when starting LVMGUI is a totally alien interface.
Even worse, LVMGUI corrupts the clear separation of physical and logical data that characterizes LVM.EXE. The Physical View displays logical volume data mixed right in with the physical disk layout, something that the user, presumably coming off LVM.EXE, has just trained themselves to move away from.
The central concept of Logical Volume Management is that logical data (drive letters and file systems) are exclusive properties of volumes. Physical data (the physical layout of the partitions on the disk) are exclusive properties of partitions.
But the LVM GUI displays file systems and drive letters in Physical View, in a manner which implies that they are characteristics of partitions, when they are not.
Worse still, LVMGUI allows operations on partitions while in Logical View, and operations on volumes while in Physical View, via the menu-bar. However, LVM.EXE strictly segregates physical and logical operations.
The real problem, of course, lies in having two entirely separate views in the first place.
It almost seems as though the designers deliberately set out to confound and frustrate their users as much as they possibly could.
The console version, LVM.EXE, is confusingly designed. However, once the user has navigated the rather steep learning curve, it is at least usable. The same cannot be said for the graphical interface: LVMGUI is a badly-conceived and poorly-designed mess which should be put out of its misery at the earliest opportunity.
Any redesign of LVM should have the following priorities, in order:
A graphical interface with a split layout; it uses a list of volumes with a "details" panel, together with a graphical representation of disk layout.
This interface shows volumes at the top, and physical disk layout at the bottom.
![[LVMPM: selecting a volume]](lvmpm_2a.gif)
The top area shows volumes in a container control on one side. Next to this is a 'details' area which displays full information about the current volume in a document-like format.
The lower area shows all the physical disks in the system, using a visual representation of disk layout.
The disk layout graphics appear superficially similar to the Physical View of IBM's LVMGUI interface, but are actually quite different. Since volume-specific information is displayed in the top area, the disk diagrams show only partition-specific information. The partitions which belong to volumes are, however, tagged with the volume's drive letter, for reference purposes.
Each partition is coloured according to its type: blue for primary partitions, cyan for logical partitions; red for Boot Manager (being a special type of primary partition). Free space uses dark grey. The size of each area (relative to the disk as a whole) is roughly representative of the actual partition size.
The partition(s) belonging to the currently-selected volume are hatched. If the disk viewport has the current focus, then the currently-selected partition is also highlighted with a border.
![[LVMPM: selecting a partition]](lvmpm_2b.gif)
When a partition is selected, its details are displayed at the bottom of the window.
Notice that the misleading terms 'compatibility volume' and 'LVM volume' have been replaced by 'standard volume' and 'advanced volume', respectively.
An an extension to this design, the user could be allowed to customize the interface. Possible options include:
A console-mode interface which could act as a suitable counterpart for the graphical design above.
Like the graphical design, this interface has an area at the top which shows volumes, and another at the bottom which shows disk layout.
![[LVMVIO]](lvmvio_1.gif)
Unlike IBM's LVM.EXE, you can see which panel is currently 'active' (i.e. has keyboard input), since it has a double-line instead of a single-line border.
The blue selection bar indicates the currently-selected item in the active panel. The cyan bars in the inactive panel indicate the 'connected' items in the other panels. So, in the example, a volume is selected in the top panel (highlighted in blue), and its corresponding partitions are shown highlighted in cyan in the bottom panel.