subdisk

Subdisk

• A subdisk is a subsection of a disk's public region and is the smallest unit of storage in Volume Manager.  

• A subdisk is defined by an offset and a length in sectors on a volume manager disk.

• A volume manager disk can contain multiple subdisks, but subdisks cannot overlap or share the same portions of a volume manager disk.

• Volume manager disk space that is not reserved or that is not part of a subdisk is free space. You can use free space to create new subdisks.

Creating a Subdisk

# vxmake –g <diskgroup> sd disk1-01 disk1,0,100m

This would create a sub-disk called disk1-01 at the start of disk disk01 and would be 100m long.

If you want to create another sub-disk on the same disk (disk01) the offset would be 100m as this is where the next freespace would be on the disk. So

# vxmake –g <diskgroup> sd disk01-02 disk1,100m,100m

This would create another 100m subdisk.

Removing Subdisk

# vxedit rm <sub-disk>

Moving sub-disk

# vxsd mv <old sub-disk> <new sub-disk>

Associating with a plex

# vxmake plex <plex> sd=<sub-disk>

# vxmake plex home-1 sd=disk02-01, disk02-00, disk02-02

Dissociating a Sub-disk

# vxsd dis <sub-disk>

Splitting a Subdisk

# vxsd –s<size> split sd<new sub><newsub2>

Joining a Subdisk

# vxsd join <subdisk1><subdisk2><newsubdisk>

VxVM Daemon

vxconfigd:

• Maintains the configuration database
• Synchronizes changes between multiple requests, based on a database transaction model.
• vxconfigd reads the kernel log to determine current states of VxVM components and updates the configuration database
• Kernel logs are updated even if vxconfigd is not running. For Example, upon start-up, vxconfigd reads the kernel logs and determines that a volume needs to be resynchronized.

The vxdctl Command

            Use vxdctl to control vxconfigd.

            # vxdctl mode                            Display vxconfigd status

           

# vxdctl mode

mode: enabled

            # vxdctl enable                                    Enables vxconfigd

                # vxdctl disable                                    Disabled vxconfigd

                # vxdctl stop                                         To Stop the vxconfigd daemon

                # vxconfigd                                          To start vxconfigd

# vxdctl license                                    display vxdctl license

# vxdctl license

All features are available:

 Mirroring

 Root Mirroring

 Concatenation

 Disk-spanning

 Striping

 RAID-5

 RAID-5 Snapshot

 VxSmartSync

 Array Snapshot Integration Feature

 FastResync

 DGSJ

 Site Awareness

 DMP (multipath enabled)

 CDS

 Dynamic LUN Expansion

 Hardware assisted copy

# vxdctl support  To see what are the thing vxdctl supports

Support information:

  vxconfigd_vrsn:   24

  dg_minimum:       20

  dg_maximum:       140

  kernel:           18

  protocol_minimum: 80

  protocol_maximum: 80

  protocol_current: 0

# vxrelocd Daemon

• vxrelocd is the hot relocation daemon that monitors events that effect redundancy. Data affected from mirrored or RAID-5 subdisk are relocated to spare disks or other free space within the disk group.
• vxrelocd notifies the system administrator by email of redundancy failures and relocation activities.

# vxiod Daemon

• Volume extended I/O daemon that allows for extended I/O operation without blocking calling processes.

# vxnotify Daemon

• Notifies of events relating to disk and configuration changes

# vxconfigbackupd (Veritas) dgcfgdaemon (HP)

• HP Specific automatic configuration daemon

How to change kernel parameters using CLI in HP-UX 11.0 and 11i

How to change kernel parameters using CLI in HP-UX 11.0 and 11i

The kernel rebuilding process is accomplished through the following steps:
1. Change directory to /stand/build
# cd /stand/build

2. Create a kernel parameter system file from the running system
# /usr/lbin/sysadm/system_prep -s system

A file called system will be created under /stand/build, and that will be the temporary system configuration file.

3. Make changes to the current system configuration using the kmsystem, kmtune or kmadmin commands.
#/stand/build # kmtune -S /stand/build/system -q semume
Parameter             Current Dyn Planned                    Module     Version
===============================================================================
semume                     10  -  10    

For example we will be changing the maxusers paremeter from a value of 10 to 256

#/stand/build # kmtune -S /stand/build/system -s semume=256
To verify that this new value has been included in the system file, by checking the difference from the original set:

#/stand/build # kmtune -S /stand/build/system -d
Parameter             Current Dyn Planned                    Module     Version
===============================================================================
semume                     10  -  256 

4. While you are in the /stand/build directory, build a new kernel using mk_kernel command:
#/stand/build # /usr/sbin/mk_kernel -s ./system
Generating module: krm...
Generating module: rng...
Compiling conf.c...
Generating module: emcp...
Generating module: emcpmpx...
Generating module: emcpcg...
Generating module: emcpsapi...
Generating module: emcpgpx...
Generating module: emcpgpx_dm...
Loading the kernel...
Generating kernel symbol table...
#/stand/build # 

5. Backup the old kernel and system files, just in case something goes wrong:
# cp /stand/system  /stand/system.old
# cp /stand/vmunix /stand/vmunix.old
# cd /stand
# cp -R dlkm dlkm.vmunix.old
6. Schedule installation of the new kernel using the kmupdate command. Copy the /stand/build/system file to the /stand/system file.
# kmupdate

 Kernel update request is scheduled.

 Default kernel /stand/vmunix will be updated by  newly built kernel /stand/build/vmunix_test  at next system shutdown or startup time.

# cp /stand/build/system /stand/system 

7. Reboot the system
# cd /
# shutdown -ry 0 
After the reboot make sure to check that the parameter has been changed successully with either kmtune or kmsystem commands.

After Reboot:
#/var/adm/crash # kmtune -q semume
Parameter             Current Dyn Planned                    Module     Version
===============================================================================
semume                    256  -  256

Intermittent disk failures

Intermittent disk failures

Intermittent disk failures are failures that occur off and on and involve problems that cannot be consistently reproduced. Therefore, these types of failures are the most difficult for the operating system to handle and can cause the system to slow down considerably while the operating system attempts to determine the nature of the problem. If you encounter intermittent failures, you should move data off of the disk and remove the disk from the system to avoid an unexpected failure later. However, intermittent disk failures are also very rare. With intermittent disk failures, you can sometimes observe disks being labelled by VxVM as failing as shown on the slide. If Volume Manager experiences occasional I/O failures on a disk but can still access the private region of the disk, it marks the disk as failing.

Note: If the failing flag is set on a disk, it is not turned off until the administrator executes the following command:

# vxedit -g diskgroup set failing=off dm_name

1.  List the disks under Veritas Volume Manager control to determine which disk is marked bad:

# vxdisk list 

DEVICE       TYPE      DISK         GROUP        STATUS

c0t1d0s2     sliced    disk01       rootdg       online failing

c0t3d0s2     sliced    rootdisk     rootdg       online

........(more)

2.  Clear the failing flag for the disk that is marked as failing:

# vxedit -g rootdg set failing=off disk01

 3.  Verify that the flag has been cleared:

# vxdisk list - to verify that the flag has been changed 

  

DEVICE       TYPE      DISK         GROUP        STATUS

c0t1d0s2     sliced    disk01       rootdg       online

c0t3d0s2     sliced    rootdisk     rootdg       online

........(more)