This topic discusses the benefits of storage space linking.
Another benefit of storage spaces is that they are independent. This means that when you create a new storage space, it is not tied to any particular Linux® server. A storage space must be linked to an NWSD before the Linux server can “see” it. Even after you link a storage space you can unlink it and link it to another Linux server. Note that a storage space can only be linked to one server at a time. However, you could use this virtual connectivity to move a data drive among different Linux servers at the touch of a mouse.
Links can be either static (also known as fixed) or dynamic. Each IXS or IXA NWSD can have up to 16 fixed links and 16 dynamic links:
A storage space can only be linked as fixed when the integrated Linux server is shut down. You should always link storage spaces as fixed where possible, saving dynamic links for times when you need to add a drive while the server is active.
For IXS/IXA, the system and installation drives are linked as fixed when the server is created. Do not try to change these links to dynamic.
A storage space can be linked as dynamic when the integrated Linux server is started or shut down. However, you would normally save your dynamic links for adding drives when the server is active. If you use up all your dynamic links, and you need to add more drives, the server must be shut down. Note that it is possible to change the link type from dynamic to fixed by varying off the NWSD, unlinking the storage space and relinking it as fixed.
After a storage space has been linked, you must format it under Linux before Linux can use it.
You might want to unlink a storage space in order to delete the storage space or to relink it to another Linux server. Storage spaces can be unlinked in two ways:
This is the method you would normally use to unlink a storage space from a Linux server. You can use this method regardless of whether the storage space was linked with a fixed or dynamic link. In this case, you shut down the Linux server and then perform the unlink operation.
The link sequence is the order in which storage spaces are presented to the Linux server by i5/OS™. Statically linked drives are always presented before dynamically linked drives in the link sequence. The link sequence corresponds to the order in which Linux sees its disk drive devices: /dev/sda, /dev/sdb, /dev/sdc, and so on.
The easiest way to determine the link type and sequence number for a storage space is to use the WRKNWSSTG command which shows a set of storage spaces linked to Linux server Redhat1. Some storage spaces are linked statically (*FIX); others are linked dynamically (*DYN). You can also view the link sequence graphically through iSeries™ Navigator.
Notice that the link sequence for statically linked drives (*FIX) starting at 3. The equivalent iSeries Navigator display shows the link sequence for statically linked drives (Fixed) starting at 1. Therefore, a statically linked drive that has a link sequence number of n on the WRKNWSSTG green screen display is shown with a link sequence number of n - 2 on the equivalent iSeries Navigator display.
Be careful about unlinking storage spaces from Linux servers. If you unlink a drive from an integrated Windows® server (other than the system or installation drives), Windows tolerates the missing drive and boots up normally, assuming that there are no application errors. Linux, however, detects the missing drive and halts the boot sequence. In this case, you need to sign on as root and go into maintenance mode to remove the file system entry for the drive you unlinked before the server can continue the boot process. If you relink the storage space, you need to add back the file system entry you previously deleted.
When you unlink a storage space, i5/OS optionally compresses the link sequence. For example, if you have four statically linked drives (link sequence numbers 3, 4, 5 and 6), and three dynamically linked drives (link sequence numbers 1, 2 and 3), when you boot the Linux server, these drives appear to Linux in the same order, but with the statically linked drives preceding the dynamically linked drives:
If you unlink the storage space corresponding to the third statically linked drive (link sequence 5), the link sequence is compressed so that there are now three statically linked drives (3, 4 and 5) followed by the three dynamically linked drives (1, 2 and 3). When you restart the server, Linux issues an error for /dev/sdg because it allocates a device handle to the remaining drives in order. This can create a problem if you have applications accessing data through a specific mount point because, in the example given, after you unlink the storage space with fixed link sequence number 5, a different drive is mounted to each mount point (except for the system and installation drives).
It is possible to unlink a drive without compressing the link sequence. However, this has no effect because Linux still allocates a device handle to the drives it sees in order. That is, it does not leave a “hole” in the list of allocated devices. Therefore, in the previous example, Linux again issues an error for /dev/sdg.
It is recommended that, if you do need to unlink storage spaces, you compress the link sequence unless you are planning to relink the drive later on, in which case the link sequence should not be compressed.