How to Set Permissions on Raw Logical Volumes

In this tip, I'll take a look at raw logical volumes (LVs) on AIX and show you how to set their permissions. But first, what is a raw LV, and why would you use it instead of a file system? The AIX 7.1 Information Center has the answer:

A raw logical volume is an area of physical and logical disk space that is under the direct control of an application, such as a database or a partition, rather than under the direct control of the operating system or a file system.

So why would you choose a raw LV instead of creating a journaled file system? After all, with a file system, you can navigate into directories and sub-directories, do file system backups, and run commands that are simply not available on a raw LV. Journaled file systems also offer a neat recovery in the event of a system crash, and you can display used and free file system space using df. With the benefits in manageability and recovery of journaled file systems, why would you opt for a raw LV?

Raw Performance

The primary reason people occasionally choose raw LVs over file systems is to yield better performance from the controlling application. This might especially be a consideration for database applications. However, as the AIX Information Center says, the amount of improvement depends on factors such as the size of a database or the application's driver.

I very rarely come across raw LVs these days. Most sites find that they get the performance they need from a well-designed and optimized AIX system running journaled file systems. (When I mention journaled file systems, I really mean enhanced journaled file systems, also known as JFS2, and not the older JFS).

One of the areas where file systems really come into their element is permissions. Raw LVs don't give you as much granular control over permissions at the OS level, but that doesn't mean all raw LVs need to be owned by the root user.

Default LV Permissions

When a logical volume is used by a file system, the LV's default permissions (root/system and mode 0432) are usually fine, because permissions are customized within the file system, right down to individual directories and files. The LV permissions will probably remain at the default they were set to when you created the LV using the mklv command:

However, with raw LVs, the situation is a little different. If the application is controlling raw LVs, you might need or want the application user to own the LV, rather than root.

Customized Permissions

You can set LV permissions on the LV special file (in /dev directory) when you create the LV using the mklv command. Use -U to set the user ID and -G for the group. You can also use -P for the mode, just as you would use for the chmod command.

If you want to change the permissions on an existing logical volume, you can use the chlv command with the same permissions flags as the mklv command:

Volume Groups and Raw LVs

You could have made these permission changes using the standard permissions commands that you'd use with any other files (chown, chgrp, and chmod). But there's a good reason not to do it that way: If the volume group the raw LVs belong to is exported and imported again, the LV special files will revert to default permissions (root, system, and mode 0432). This means your application might be unable to access its raw LVs until you change the permissions again. However, if you’ve set the LV permissions using mklv or chlv (as shown above), you can reinstate the ownership, group ID, and permissions mode when you import a volume group. To do that, use the '-R' flag when you run the importvg command:

This will work for volume groups that are either big or scaleable, but not for the older Original Volume Group.

Raw Challenge

It can be a bit challenging managing raw LVs when you're used to working only with journaled file systems. Still, if you have a good reason for opting for raw LVs for your database, it's nice to know the database can control LVs without requiring root permissions.