The hashed shared disk must be defined before you can configure and use it. The data striping device information is stored in the System Data Repository (SDR). You can use either SMIT or a command to enter the information in the SDR.
The SMIT panels refer to the data striping devices as "hsd"
To define the hashed shared disk information in the SDR using SMIT:
The fastpath invocation for this menu is:
smit vsd_data
We will define our hashed shared disk, called hsd1, with four virtual shared disks at the same node and a stripe size of 4096 bytes. The virtual shared disks are named vsd1vg1n1, vsd2vg1n1, vsd3vg1n1, and vsd4vg1n1.
The hashed shared disks were defined:
defhsd hsd1 4096 vsd1vg1n1 vsd2vg1n1 vsd3vg1n1 vsd4vg1n1
We have 16384 bytes (four 4KB blocks) of data to write. The first 4096 bytes are stored in vsd1vg1n1. The second 4096 bytes are stored in vsd2vg1n1, the third 4096 bytes are stored in vsd3vg1n1, and the last 4096 bytes are stored in vsd4vg1n1.
Assume now we have two striped devices defined, hsd1 and hsd2. Our stripe size is 4096.
We had identified the virtual shared disks to be included in the hashed
shared disks. Assume there are four nodes in the system and two
physical hard disks per node. We wanted to stripe across all the four
nodes and all the disks. We defined a logical volume on the disks and
nodes. Then we defined the virtual shared disks:
| hsd name | node | virtual shared disks in the hashed shared disk |
|---|---|---|
| hsd1 | node1 | vsd1vg1n1 |
| node2 | vsd1vg1n2 | |
| node3 | vsd1vg1n3 | |
| node4 | vsd1vg1n4 | |
| hsd2 | node1 | vsd2vg1n1 |
| node2 | vsd2vg1n2 | |
| node3 | vsd2vg1n3 | |
| node4 | vsd2vg1n4 |
We defined the hashed shared disk with the following commands:
defhsd hsd1 4096 vsd1vg1n1 vsd1vg1n2 vsd1vg1n3 vsd1vg1n4 defhsd hsd2 4096 vsd2vg1n1 vsd2vg1n2 vsd2vg1n3 vsd2vg1n4
To list hashed shared disk definition information in the SDR do one of the following:
From the SP Configuration Database Management menu:
You can use the fastpath invocation for this menu :
smit list_vsd
At this point, you can select options for listing defined hashed shared disk information.
To view defined hashed shared disk information using SMIT:
You can also display defined hashed shared disk information using the hsdatalst command:
hsdatalst
To delete hashed shared disk definition information
From the SP Configuration Database Management menu:
The fastpath invocation for this menu is:
smit delete_vsd
At this point, you can select options for undefining a hashed shared disk.
To undefine a hashed shared disk using SMIT:
You can either type in the hsd_name or select an hsd_name from the list function. The hsd_name must be in the unconfigured state.
You can also undefine a hashed shared disk using the removehsd or undefhsd commands:
undefhsd -v hsd_names [-f]
removehsd -v hsd_names [-f]
If the hsd_names are configured, you can use the -f parameter of removehsd to force the system to unconfigure and remove them.
To manage hashed shared disks using SMIT:
The fastpath invocation for this menu is:
smit hsd_mgmt
Configuration makes a defined hashed shared disk available.
From the HSD Management menu,
cfghsd hsd_name ...
Unconfiguring a hashed shared disk makes it unavailable. It does not, however, undefine or change the definition information for the hashed shared disk in the SDR. You must do this on each node.
From the HSD Management menu,
ucfghsd hsd_name ...
You can display managed virtual shared disk and hashed shared disk characteristics for all configured hashed shared disks.
From the HSD Management menu,
You can also display managed hashed shared disk characteristics using the lshsd command. To display information for a specific hashed shared disk in your system, enter:
lshsd -l [ hsd_name ... ]
Configuration information displayed for a hashed shared disk includes:
You can display managed usage statistics for all configured hashed shared disks.
From the HSD Management menu,
You can also display managed hashed shared disk usage statistics using the lshsd command. To display usage information for a specific hashed shared disk in your system, enter:
lshsd -s [ hsd_name ... ]
Usage information displayed for a hashed shared disk includes:
You can display and, in some cases, set virtual shared disk parallelism level, as well as reset the device counters and statistics. Operational parameters include:
From the HSD Management menu,
You can also display and set hashed shared disk operational parameters using the ctlhsd command. Refer to the PSSP: Command and Technical Reference for more information.
After you install the Hashed Shared Disk software and define and configure several hashed shared disks, you can use the verification test. Do this before you store data on these devices.
Caution:
The hsdvts command writes data to the configured
hsd_name. Do not use the command after you have put real data
on that hsd_name or the underlying virtual shared disks.
Refer to the hsdvts command reference page. Follow these steps:
hsdvts hsd.name
You should get the message:
HSD verification test successful!
You can use the hsdvts command to verify all of your hashed shared disks. Use it to verify both local and remote hashed shared disks. Issue the cfghsd command on all client and server nodes.
You can define, configure, unconfigure, and undefine hashed shared disks, using the defhsd, cfghsd, ucfghsd, and undefhsd commands.
Configuring a hashed shared disk creates the special device file /dev/rhsd_name, which loads the hashed shared disk device driver into the kernel and makes the device available for use by user applications.
Use cfghsdvsd and ucfghsdvsd to configure and unconfigure hashed shared disk's and their underlying virtual shared disks on multiple nodes at once.
Unconfiguring a hashed shared disk makes the device unavailable to applications.
Defining a hashed shared disk creates a hashed shared disk object in the SDR.
Undefining a hashed shared disk deletes the hashed shared disk object from the SDR and removes the special device file /dev/hsd_name.
The Hashed Shared Disk software provides interfaces to application programs through the open, close, read, write, and related system calls. A read or write first uses the offset in the data file to figure out which virtual shared disk the request is for. The Hashed Shared Disk software then passes the request to the IBM Virtual Shared Disk software to do the I/O. Usually the ioctl call is device-dependent. The ioctl call for the hashed shared disk provides minimum information about the device.
The hashed shared disk is a character (raw) device which must be opened as /dev/rhsd_name; all the data addresses must be at 512 block boundaries.