Notes on using logical volumes and the Logical Volume Manager (LVM)


New readers should see the warning at the end of this page.

This is a summary of experiences and information about logical volumes as implemented on Warp Server for e-business, on the various Convenience Packs, and on eComStation (eCS). I've been using logical volumes for a while and have been through quite a few scenarios. The term LVM strictly applies to the Logical Volume Manager (the replacement for FDISK) but it is commonly used as a name for the whole 'system' that implements logical volumes.


The first thing many people ask is: why do it? What does LVM give me? The main features are:

Like it or not, LVM is with us. Learn to love it.

Basic concepts

The first thing to understand is that LVM and JFS are completely separate issues. In principle, you don't need an LVM system to use JFS, although I personally haven't tried to do that. From the FP14/MCP/ACP kernels onwards, I suspect one could. Remember that you can't boot from a JFS volume.

The point about the LVM system is that it separates the concepts of 'partitions' and 'volumes'. A partition (whether a primary partition, or a logical partition within an extended partition) is a chunk of disk, and a volume corresponds pretty well to a drive letter (which is obvious if you think of VOL C: as a meaningful command). These two ('partition' and 'volume') are the same on non-LVM systems, of course.

With LVM, it is possible for a volume to be spread over several partitions. Moreover, those partitions don't have to be on the same disk. Additionally, you can add new partitions to the volume post facto to increase the size of the volume. Currently, multi-partition volumes are possible with FAT, HPFS and JFS at the very least. However, dynamic resizing of a volume (by adding a partition to an existing volume) is possible only with JFS (that's the only real connection between LVM and JFS). However, JFS volumes are not currently bootable (presumably because it adds complication to the boot code if it has to handle multiple partitions on the boot volume, and the micro-FS and mini-FS necessary for booting have not been written/completed).

There are two kinds of volumes:


So, what happens when you first install an LVM-aware system? It runs a utility (VCU, the Volume Conversion Utility; you'll see it in the root directory of the installation CD) to convert all volumes so that they are marked as compatibility volumes (single partition volumes, which is what they were, anyway). The conversion is benign and backwards compatible. The partition tables remain the same (you are not, after all, altering partitions in any way, only volumes). However, certain unused sectors on the first track of the physical disk, and on the first track of extended partitions too (actually, the last sector on such tracks) is filled in with information indicating the volume to which each partition belongs, and sundry other related information.

Note that this is not going to make any difference to other systems (Warp 4, 3, 2, 1, Windows, DOS, whatever) as they'll see exactly the same partition table and partitions they always did. So, this conversion is quite safe.

Boot Manager

If changing to an LVM system, it is probably wise to re-install Boot Manager. That is, use LVM to delete any existing Boot Manager, then install it again (thus updating the copy on your hard disk to the version embedded in LVM). It is reasonable to surmise that this is a newer copy that is more LVM-aware. In fact, I suspect that the Boot Manager update is automatic, but it is better not to take chances; there may be situations in which the update is not done automatically.

While you are at it, it's also probably a good idea (once installation has completed) to update the boot code in the Master Boot Record, as there are some enhancements in later versions. To do this, use the command:


This command is quite benign, updating only the boot code without touching the partition table.


When an LVM-aware system loads, it loads the LVM module, OS2LVM.DMD, which sits above the base disk access module (OS2DASD.DMD) and presents the 'volumes' to the layers above it (the FAT file system manager, also HPFS.IFS and JFS.IFS). In the immediately converted system, the drive letters will be the same as they were before conversion.

The nice thing about an LVM system is that any volume (not partition) can have a particular drive letter assigned to it, and it 'sticks'. It's written in the special information sectors, as mentioned above. Of course, other systems won't 'see' that information, so if you have a mixed boot system it's best not to assign drive letters explicitly or you'll get confused when you boot the non-LVM-aware systems (more about that below). You'll notice that you can't reassign CD drive letters; this fits, of course, because there is nowhere, on the read-only medium, to store the assigned drive letter! RESERVEDRIVELETTER still works, though.

I personally prefer the full screen non-GUI LVM utility. The GUI is supposed to be buggy and, being a Java app, it's a bit sluggish too.

Replacements for OS2DASD.DMD

Third party replacements for OS2DASD.DMD should not be used on LVM systems. As indicated above, OS2DASD.DMD communicates with OS2LVM.DMD and thus needs to be 'LVM aware'. Third party replacements (e.g. EZRAID) will thus not work (unless they are updated).

The LVM utility

LVM provides you with two 'views' of the system:

  1. A logical (volume) view (which shows drive letters).
  2. A physical (partition) view (which shows disks and partitions).

The various user-definable names assigned are a bit confusing; remember that one set of names defines volume labels (as in VOL x:), and the other set are menu names for Boot Manager. When you get asked if you want to make a partition bootable (or unbootable), all it's really asking is if you want it on the Boot Manager menu. That's how you manipulate the BM menu using LVM; there is no specific 'add to Boot Manager' menu item. You may also be concerned that the 'install Boot Manager' menu item doesn't appear to do anything; that's because Boot Manager is a partition, not a volume, and it is shown only when you display the physical (partition) view by toggling the F5 key.

Running LVM and non-LVM systems side by side

It is perfectly possible to run (say) Warp 4 and Warp Server for e-business on the same system, using Boot Manager to select between them. However, some caution is needed to ensure that drive letters stay the same on both systems. Note the following:

Why is it a problem if partitions are created at the end of free space? Well, Warp 4 seems to letter drives (partitions) starting at the beginning of free space. So, if you let LVM allocate partitions for (say) drives D, E and F, you might find that Warp 4 sees them as F, E and D respectively.


If you use PartitionMagic (for example) on a volume, the volume disappears from LVM! This causes consternation, panic and much more! However, the situation is recoverable as long as the volume is a compatibility volume. Note that PartitionMagic should NOT, repeat NOT, be used on an LVM volume; that is, a volume that has been created as a non compatibility volume. Such a volume may be made up of multiple partitions, and PartitionMagic will fail to understand it and will destroy it.

Here's a typical scenario. You boot an LVM aware system and set up volumes. You install stuff and then want to resize, say, volume F:. So you boot from diskettes and run PartitionMagic to do that. Let's also assume that F: is on the Boot Manager menu.

Reboot, and Boot Manager has an entry for F: that says something like: '--> LVM', which means quite simply, 'run LVM'. Boot a maintenance system or the install diskettes. (If using the install diskettes, LVM is not included on them; you need to insert the installation CD and change to the \OS2IMAGE\DISK_6 directory which contains all necessary files including LVM.EXE.) You'll see that F: has vanished off the map! Panic not. You'll be able to see the partition that really is F:, but it will have lost the information in the spare sector (well, it's probably there, but wrong and inconsistent and therefore ignored). Ask LVM to create a new volume, and when it asks if it's to use an existing partition, say yes and then tell it the partition that used to be drive F:. Assign the right drive letter if LVM doesn't. Reboot, and you're back in business.

I use PartitionMagic with impunity on LVM systems now. I tend to alter one partition at a time, which takes a bit longer but stops me getting temporarily confused about which anonymous partition is which volume.

Problems with extended partitions

This problem is not actually related to LVM, but a possible solution is; hence its inclusion here. It concerns a useful, but little known feature of the LVM utility.

Extended partitions have historically been assigned a partition type value of 05H; OS/2 understands this value and detects the extended partition correctly. However, later versions of Windows assign the value 0FH (15 decimal) to extended partitions; they call this an Extended X partition. Indeed this value may be set by later versions of PartitionMagic, as well as other programs.

Unfortunately, the 0FH value causes the extended partition to be hidden from OS/2, since it does not recognise the partition type. There seems to be no problem with changing the value back to 05H, and Windows appears to have no problem with using either value. However, there are unconfirmed reports of data corruption if the partition exceeds 8GB in size.

One appears to need a disk editor or some other utility to do the job of changing the partition type, which is necessarily error prone and dangerous with most of the available utilities.

The simplest way to proceed, on an LVM system, is to boot the install CD (or the install diskettes) and run LVM. As long as some change is made to the disk (an easy one is to change the disk name in the physical view), and saved, LVM will automatically correct the types of any extended partitions back to the OS/2-acceptable value of 05H. Indeed, the system booted by the install disks can see all of the partitions anyway.

Common pitfalls

This section is intended to answer questions about things which should be obvious (but aren't) as well as pointing out problems that again may not even be obvious as problems! Suggestions for new items in this section are welcomed.

Creating a new volume

To create a new volume, make sure that the LVM utility is displaying logical view (if it isn't, use the F5 key to switch). Make sure that the top pane is selected. If necessary, press the Tab key to switch between the two panes; when the top pane is selected, a single line in it will be highlighted, but if the bottom pane is selected, there will be one line highlighted in both panes. So, press Tab until no line is highlighted in the bottom pane. Then, press Enter and select the appropriate menu item.

Creating a volume in an existing partition

There will be situations where it is necessary to create a physical partition, then create a volume in that particular partition. A similar situation is where the partition already exists, and a volume must be created in it. First, follow the instructions in the section Creating a new volume, above. When you finally see the menu, select the item to create a new volume. Several selections later, you will select the disk to be used (the one on which the partition you are going to use actually resides); the following choice allows you to use an existing partition, and you can then select the chosen partition.

Hiding a volume

When creating a volume, one can do so either by creating one or more partitions for it, or by using one or more existing partitions.

It might be expected, therefore, that deletion of a volume might leave the partition(s) concerned intact, and that this might be the correct way of temporarily hiding a volume from view. It does not. When a volume is deleted, the associated partition(s) are deleted and the data are lost!

To hide a volume, simply select the option to Hide Volume from OS/2.


I hope this is useful; feedback and other information is welcome.


The information herein is provided without guarantee or warranty. Users should be aware that some of the procedures detailed here may not work for them, and may result in loss of data. Backups of critical data should be taken before attempting to use these procedures.

The information herein is not endorsed by IBM in any way whatsoever.

Back to the Introduction

Back to Tavi OS/2 main page

Last Updated: 8th January 2003
© 2003 by Bob Eager, Tavi Systems