AIX LV Creation and the Zero-Byte Attribute

I found an interesting antidote about AIX recently. I can safely say I was surprised. Here is the lo-down. On AIX System when you create a Logical Volume you can specify that you want the device subtype to be either zero-byte attribute or 4K byte attribute. This attribute is used by oracle to determine where to start using the data. For RAW volumes this enables putting the first Oracle block at offset zero for optimal performance.

However, this feature is not available for all fo the VG types on an AIX system. On AIX systems, there are 3 Volume Group types:
* Original VG – Maximum of 32 Phyiscal Volumes within this VG
* BIG VG – Maximum of 128 Physical Volumes within the VG
* Scalable VG – Maximum of 1024 Physical Volumes within the VG

With AIX when you use the 4K byte offset, or the zero byte offset, it places a field within the LV, called the devicesubtype. Hence, when you do a lslv LVNAME it will inform you of what that field is:
example:

lslv iprod_0000302
LOGICAL VOLUME: iprod_0000302 VOLUME GROUP: oradatavg1
LV IDENTIFIER: 000ab42a0000d40000000129a8220114.205 PERMISSION: read/write
VG STATE: active/complete LV STATE: opened/syncd
TYPE: raw WRITE VERIFY: off
MAX LPs: 512 PP SIZE: 32 megabyte(s)
COPIES: 1 SCHED POLICY: parallel
LPs: 16 PPs: 16
STALE PPs: 0 BB POLICY: relocatable
INTER-POLICY: maximum RELOCATABLE: yes
INTRA-POLICY: middle UPPER BOUND: 8
MOUNT POINT: N/A LABEL: None
MIRROR WRITE CONSISTENCY: on/ACTIVE
EACH LP COPY ON A SEPARATE PV ?: yes
Serialize IO ?: NO
DEVICESUBTYPE : DS_LVZ


In this case the devicesubtype = DS_LVZ (this is a Zero Byte subtype). If it was a 4K offset, it would say DEVICESUBTYPE: DS_LV

Now as I have found out recently, this offset is only for BIG and Scalabe VGs. If you create a Volume Group in AIX, it will automatically create it as an “Original VG” unless specified at creation time. Hence the potential problem.

Here an an example:
/usr/sbin/mklv -y dtest_0000061 -t raw -T O -U oracle -G dba -P 600 oraclevg1 32

The above command will create the Logical Volume dtest_0000061 from Volume Group oraclevg1. It will set the user ownership to oracle, and the group ownership to dba. Then the permissions will be set to 600 (which means the user will have rw access to it, and no other users or groups will have any access). The LV type will be RAW. Note the -T O. This option is telling AIX to create this LV as a zero byte offset. In the case of doing thins on an ORIGINAL VG, one could expect the operation to fail. Sadly no. The above command will succeed, and the LV will be created. Upon verifying the LV with lslv 0000061 it will NOT have a devicesubtype field. Apparently AIX doesn’t have the proper checks in place to fail creating the Logical Volume if the Volume Groups is an “Original VG”. If this isn’t caught right away, one could end up using a VG which doesn’t have the proper layout. Due to oracle actively using the Logical Volumes (RAW), doing a chlv on the Logical Volume to change it may not be desirable. An outage would probably be the safest bet. According to one vendor, data corruption can occur if you attempt to “extend” the LV after converting oraclevg1 from “Original VG” to a “BIG VG”. IBM does not have any information confirming this speculation. If you convert the VG from an original to a BIG VG, the devicesubfield will NOT be created / ported either.

One can convert an original VG to a BIG VG on the fly, with no outage. Additionally, if you look at the man page for the chlv, you will note that one can add the Zero-byte attribute to existing LVs. However, when speaking with an IBM Service Representative (with oraclevg1 already converted to a BIG VG), they recommended against performing the chlv, and state you should convert the BIG VG to a scalable VG first, and then do the chlv -T O option to change the LV(s) to a zero byte attriubute. NOTE: To convert a VG from BIG to Scalable, an outage is required, as the VG has to be varyied off first.