Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Raw partitions on AIX
- Thread starter ranjank
- Start date
This procedure is used to define an area of physical and logical disk space that is under the direct control of an application rather than under control of the operating system and file system. The applications use character (raw) input and output rather than the block input and output of file systems, which require more software overhead. Bypassing the file system overhead enables applications to perform better. Raw logical volumes are most commonly used with database applications because of their need for high performance. While there is ordinarily a significant increase in performance, the actual amount of the increase depends on the database size and the driver provided by the application.
To prepare a raw logical volume, you simply create an ordinary logical volume without creating a file system on it.
Note: Do not be too concerned with the name of the application or how its documents use raw storage. The term used could be any one of the following: partition, slice, file system, raw access, raw disk, or logical volume. The important naming concerns are dealt with as follows:
Use the correct command to define and name the device for the operating system.
For a logical volume, use the mklv command to create /dev/rLVName and /dev/LVName (for example, /dev/rhdX and /dev/hdX).
Provide the application with the character or block special device file as appropriate. The application will link to this device when performing opens, reads, writes, and so on.
Attention: Each logical volume has a logical-volume control block (LVCB) located in the first 512 bytes. Data begins in the second 512-byte block. Take care when reading and writing directly to the logical volume, as is done with raw logical volumes, because the LVCB is not protected from raw-logical-volume access. If the LVCB is overwritten, commands that try to update the LVCB will fail and give a warning message. Although the logical volume will continue to operate correctly and the overwrite of the LVCB is an allowable event, it is not recommended that the LVCB be destroyed by raw-logical-volume I/O.
To find the free physical partitions (PPs) where you can create the raw logical volume, use Web-based System Manager (type wsm, then select lvm) or the SMIT fast path as follows:
Type:
smit lspv
Press Enter.
Type the volume group name, for example:
rootvg
Press Enter.
Move the cursor to the disk that is most likely to have free physical partitions (possibly a disk with a higher number such as hdisk2 or hdisk3). Press Enter.
Check the FREE PPs field and multiply this number by the PP SIZE field to get the total number of megabytes available on that disk for a raw logical volume.
Make sure the number of free partitions is adequate based on your site's needs and the application's requirements. If the free space is not adequate, return to the previous menu and enter the name of a different disk or add a new physical volume if the free space is still not adequate. Exit SMIT.
Create the raw logical volume typing the following on the command line:
mklv -y LVname VGName 38
In this example, -y indicates that you are going to name the logical volume instead of using a system name. The number 38 represents the number of 4 MB physical partitions. The raw volume capacity in this example is thus 152 MB. The raw logical volume you have created is now ready for your application to use.
Best Regards,
vivek
To prepare a raw logical volume, you simply create an ordinary logical volume without creating a file system on it.
Note: Do not be too concerned with the name of the application or how its documents use raw storage. The term used could be any one of the following: partition, slice, file system, raw access, raw disk, or logical volume. The important naming concerns are dealt with as follows:
Use the correct command to define and name the device for the operating system.
For a logical volume, use the mklv command to create /dev/rLVName and /dev/LVName (for example, /dev/rhdX and /dev/hdX).
Provide the application with the character or block special device file as appropriate. The application will link to this device when performing opens, reads, writes, and so on.
Attention: Each logical volume has a logical-volume control block (LVCB) located in the first 512 bytes. Data begins in the second 512-byte block. Take care when reading and writing directly to the logical volume, as is done with raw logical volumes, because the LVCB is not protected from raw-logical-volume access. If the LVCB is overwritten, commands that try to update the LVCB will fail and give a warning message. Although the logical volume will continue to operate correctly and the overwrite of the LVCB is an allowable event, it is not recommended that the LVCB be destroyed by raw-logical-volume I/O.
To find the free physical partitions (PPs) where you can create the raw logical volume, use Web-based System Manager (type wsm, then select lvm) or the SMIT fast path as follows:
Type:
smit lspv
Press Enter.
Type the volume group name, for example:
rootvg
Press Enter.
Move the cursor to the disk that is most likely to have free physical partitions (possibly a disk with a higher number such as hdisk2 or hdisk3). Press Enter.
Check the FREE PPs field and multiply this number by the PP SIZE field to get the total number of megabytes available on that disk for a raw logical volume.
Make sure the number of free partitions is adequate based on your site's needs and the application's requirements. If the free space is not adequate, return to the previous menu and enter the name of a different disk or add a new physical volume if the free space is still not adequate. Exit SMIT.
Create the raw logical volume typing the following on the command line:
mklv -y LVname VGName 38
In this example, -y indicates that you are going to name the logical volume instead of using a system name. The number 38 represents the number of 4 MB physical partitions. The raw volume capacity in this example is thus 152 MB. The raw logical volume you have created is now ready for your application to use.
Best Regards,
vivek
- Thread starter
- #3
ddlldd2000
Technical User
Hi,vivek,as you said "Take care when reading and writing directly to the logical volume", what kind of writing will cause directly to the logical volume? How to prevent this happening? If happened, how to correct it and get back the data in it?
There is also another question that how I know what kind of data stored in the LV just like getting information from file system? And I know that we can use dd to backup and restore the data, but how? I tried to get it from MAN, but a little bit confused.
Thanks in advance.
There is also another question that how I know what kind of data stored in the LV just like getting information from file system? And I know that we can use dd to backup and restore the data, but how? I tried to get it from MAN, but a little bit confused.
Thanks in advance.
The logical volume control block (lvcb) is the first 512
bytes of a logical volume. This area holds important
information such as the creation date of the logical volume,information about mirrored copies, and possible mount points in a journaled filesystem. Certain LVM commands are required to update the lvcb, as part of completeness algorithms in LVM. The old lvcb area is first read and analyzed to see if it is a valid lvcb.If the information is verified as valid lvcb information, then the lvcb is updated. If the information is not valid, then the lvcb update is not performed and the user is given the warning message:
Warning, cannot write lv control block data
Most of the time, this is a result of database programs
accessing the raw logical volumes (and thus bypassing the
journaled filesystem) as storage media. When this occurs, the information for the database is literally written over the lvcb. Applications that write to the raw disk can overwrite this section(common applications that do this are Oracle and Sybase). Commands that call getlvcb will generate a warning but succeed (since the control block exists in ODM. Don't run synclvodm unless you really want to erase the first 512 bytes replace it with the info from the ODM.
Although this may seem fatal, it is not the case. Once the
lvcb has been overwritten, the user can still:
1) Extend a logical volume
2) Create mirrored copies of a logical volume
3) Remove the logical volume
4) Create a journaled filesystem with which
to mount the logical volume
(note that this will destroy any
data sitting in the lvcb area)
However, there is a limitation caused by this deletion of the lvcb. The logical volumes with deleted lvcb's face possible,incomplete importation into other AIX systems. During an "importvg", the LVM command will scan the lvcb's of all defined logical volumes in a volume group for information concerning the logical volumes. Surprisingly, if the lvcb is deleted, the imported volume group will still define the logical volume to the new AIX system which is accessing this volume group, and the user can still access the raw logical volume. However, any
journaled filesystem information is lost and the logical volume and its associated mount point won't be imported into the new AIX system. The user must create new mount points and the availability of previous data stored in the filesystem is NOT assured. Also, during this import of a logical volume with an erased LVCB, some non-jfs information concerning the logical volume, which is displayed with the "lslv" command, cannot be found. When this occurs, the system uses default logical volume information to populate the logical volume's
ODM information. Thus, some output from the "lslv" will be inconsistent with the real logical volume. If logical volume copies still exist on the original disks, this information will not be correctly reflected in
the ODM database. The user should use "rmlvcopy" and "mklvcopy" to rebuild any logical volume copies and synchronize the ODM. Finally, with an erased lvcb, the output from the "lslv" command might be misleading or unreliable.
-------------------------------------------------------
Note: When you restore the database files onto the raw devices, you must skip the first 4 KB (that is, 4096 bytes) in each logical volume to avoid overwriting the logical volume control block. Therefore, when you use dd to restore the database files onto the raw devices, you must begin writing at the second 4 KB block on the raw device. Although the LVCB only spans the first few hundred bytes within the logical volume, Oracle skips the first 4096 bytes to prevent alignment issues on AIX platforms.
1. Shut down the database using SQL*DBA.
2. Back up all Oracle files on raw devices. This includes parameter, data, redo log, and control files. Any Oracle files not on raw devices are not affected.
3. Remove all logical volumes containing Oracle files on a raw device. Use IBM SMIT or the rmlv command.
4. For each logical volume, recreate the logical volume to create a new LVCB, and expand the logical volume if necessary using the mklv command.
Note: If the Oracle file on the raw device originally occupied the entire logical volume, you must expand the logical volume to accommodate the skipping of 4 KB in Step 5.
5. Restore the backed-up Oracle files onto the newly created logical volumes using the dd command. Skip the first 4096 bytes by beginning the write at the second 4 KB block.
Example
$ sqldba lmode=y
SQLDBA> CONNECT INTERNAL
SQLDBA> SHUTDOWN NORMAL
SQLDBA> EXIT
$ dd if=/dev/rraw_10_0 of=/usr/oracle/save/rawfile1 bs=blocksize count=size_of_file_in_specified_blocksize
$ rmlv name_of_logical_volume
$ mklv -yname_of_logical_volume name_of_volume_group
number_of_disks
$ dd if=/usr/oracle/rawfile1 of=/dev/rraw_10_0 bs=4096 seek=1 count=size_of_file_in_specified_blocksize
-------------------------------------------------------
In Sybase there is an option vstart ... setting vstart to 2 will skip lvcb. But I'm not very much sure about it.
-------------------------------------------------------
mksysb command only backs up rootvg, in order to save user volume groups, we use the savevg command.
The volume group you are trying to save must be varied-on, and the file systems must be mounted. All logical volume information in the volume group is archived and will be recreated. However, only JFS mounted file system data will be archived. Raw logical volume data will not be archived using the savevg command. In order to save a raw logical volume use the dd command and proceed with the following sequence of steps to save your raw logical volumes:
Check the block size of the tape using the tctl command:
tctl -f /dev/rmtxx status
Change the block size of the tape to your required block size using:
chdev -l rmtxx -a block_size=<tape block size>
Save the raw logical volume onto a tape device using:
dd if=/dev/lvname of=/dev/rmtxx ibs=512 obs=<tape block size>
This will create a back up of the raw logical volume on the tape.
Best Regards,
vivek
bytes of a logical volume. This area holds important
information such as the creation date of the logical volume,information about mirrored copies, and possible mount points in a journaled filesystem. Certain LVM commands are required to update the lvcb, as part of completeness algorithms in LVM. The old lvcb area is first read and analyzed to see if it is a valid lvcb.If the information is verified as valid lvcb information, then the lvcb is updated. If the information is not valid, then the lvcb update is not performed and the user is given the warning message:
Warning, cannot write lv control block data
Most of the time, this is a result of database programs
accessing the raw logical volumes (and thus bypassing the
journaled filesystem) as storage media. When this occurs, the information for the database is literally written over the lvcb. Applications that write to the raw disk can overwrite this section(common applications that do this are Oracle and Sybase). Commands that call getlvcb will generate a warning but succeed (since the control block exists in ODM. Don't run synclvodm unless you really want to erase the first 512 bytes replace it with the info from the ODM.
Although this may seem fatal, it is not the case. Once the
lvcb has been overwritten, the user can still:
1) Extend a logical volume
2) Create mirrored copies of a logical volume
3) Remove the logical volume
4) Create a journaled filesystem with which
to mount the logical volume
(note that this will destroy any
data sitting in the lvcb area)
However, there is a limitation caused by this deletion of the lvcb. The logical volumes with deleted lvcb's face possible,incomplete importation into other AIX systems. During an "importvg", the LVM command will scan the lvcb's of all defined logical volumes in a volume group for information concerning the logical volumes. Surprisingly, if the lvcb is deleted, the imported volume group will still define the logical volume to the new AIX system which is accessing this volume group, and the user can still access the raw logical volume. However, any
journaled filesystem information is lost and the logical volume and its associated mount point won't be imported into the new AIX system. The user must create new mount points and the availability of previous data stored in the filesystem is NOT assured. Also, during this import of a logical volume with an erased LVCB, some non-jfs information concerning the logical volume, which is displayed with the "lslv" command, cannot be found. When this occurs, the system uses default logical volume information to populate the logical volume's
ODM information. Thus, some output from the "lslv" will be inconsistent with the real logical volume. If logical volume copies still exist on the original disks, this information will not be correctly reflected in
the ODM database. The user should use "rmlvcopy" and "mklvcopy" to rebuild any logical volume copies and synchronize the ODM. Finally, with an erased lvcb, the output from the "lslv" command might be misleading or unreliable.
-------------------------------------------------------
Note: When you restore the database files onto the raw devices, you must skip the first 4 KB (that is, 4096 bytes) in each logical volume to avoid overwriting the logical volume control block. Therefore, when you use dd to restore the database files onto the raw devices, you must begin writing at the second 4 KB block on the raw device. Although the LVCB only spans the first few hundred bytes within the logical volume, Oracle skips the first 4096 bytes to prevent alignment issues on AIX platforms.
1. Shut down the database using SQL*DBA.
2. Back up all Oracle files on raw devices. This includes parameter, data, redo log, and control files. Any Oracle files not on raw devices are not affected.
3. Remove all logical volumes containing Oracle files on a raw device. Use IBM SMIT or the rmlv command.
4. For each logical volume, recreate the logical volume to create a new LVCB, and expand the logical volume if necessary using the mklv command.
Note: If the Oracle file on the raw device originally occupied the entire logical volume, you must expand the logical volume to accommodate the skipping of 4 KB in Step 5.
5. Restore the backed-up Oracle files onto the newly created logical volumes using the dd command. Skip the first 4096 bytes by beginning the write at the second 4 KB block.
Example
$ sqldba lmode=y
SQLDBA> CONNECT INTERNAL
SQLDBA> SHUTDOWN NORMAL
SQLDBA> EXIT
$ dd if=/dev/rraw_10_0 of=/usr/oracle/save/rawfile1 bs=blocksize count=size_of_file_in_specified_blocksize
$ rmlv name_of_logical_volume
$ mklv -yname_of_logical_volume name_of_volume_group
number_of_disks
$ dd if=/usr/oracle/rawfile1 of=/dev/rraw_10_0 bs=4096 seek=1 count=size_of_file_in_specified_blocksize
-------------------------------------------------------
In Sybase there is an option vstart ... setting vstart to 2 will skip lvcb. But I'm not very much sure about it.
-------------------------------------------------------
mksysb command only backs up rootvg, in order to save user volume groups, we use the savevg command.
The volume group you are trying to save must be varied-on, and the file systems must be mounted. All logical volume information in the volume group is archived and will be recreated. However, only JFS mounted file system data will be archived. Raw logical volume data will not be archived using the savevg command. In order to save a raw logical volume use the dd command and proceed with the following sequence of steps to save your raw logical volumes:
Check the block size of the tape using the tctl command:
tctl -f /dev/rmtxx status
Change the block size of the tape to your required block size using:
chdev -l rmtxx -a block_size=<tape block size>
Save the raw logical volume onto a tape device using:
dd if=/dev/lvname of=/dev/rmtxx ibs=512 obs=<tape block size>
This will create a back up of the raw logical volume on the tape.
Best Regards,
vivek
- Status
Similar threads
- Locked
- Question