154 lines
9.2 KiB
HTML
154 lines
9.2 KiB
HTML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE html
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html lang="en-us" xml:lang="en-us">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2005" />
|
|
<meta name="DC.rights.owner" content="(C) Copyright IBM Corporation 2005" />
|
|
<meta name="security" content="public" />
|
|
<meta name="Robots" content="index,follow" />
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
|
<meta name="DC.Type" content="concept" />
|
|
<meta name="DC.Title" content="Understanding storage space linking" />
|
|
<meta name="abstract" content="This topic discusses the benefits of storage space linking." />
|
|
<meta name="description" content="This topic discusses the benefits of storage space linking." />
|
|
<meta name="DC.Relation" scheme="URI" content="rzau9mandrives.htm" />
|
|
<meta name="DC.Format" content="XHTML" />
|
|
<meta name="DC.Identifier" content="rzau9storagespacelink" />
|
|
<meta name="DC.Language" content="en-us" />
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
|
<!-- US Government Users Restricted Rights -->
|
|
<!-- Use, duplication or disclosure restricted by -->
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
|
<title>Understanding storage space linking</title>
|
|
</head>
|
|
<body id="rzau9storagespacelink"><a name="rzau9storagespacelink"><!-- --></a>
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
|
<h1 class="topictitle1">Understanding storage space linking</h1>
|
|
<div><p>This topic discusses the benefits of storage space linking.</p>
|
|
<p>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<sup>®</sup> 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. </p>
|
|
<p>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:</p>
|
|
<ul><li>Fixed links<p>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. </p>
|
|
<p>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.</p>
|
|
</li>
|
|
<li>Dynamic links<p>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.</p>
|
|
</li>
|
|
</ul>
|
|
<p>After a storage space has been linked, you must format it under Linux before Linux can
|
|
use it.</p>
|
|
<div class="section"><h4 class="sectiontitle">Unlinking storage spaces</h4><p>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:</p>
|
|
<ul><li>Linux server
|
|
is shut down<p>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.</p>
|
|
</li>
|
|
<li>Linux server
|
|
is up and running<div class="p">At V5R3 or later, you can unlink a storage space while
|
|
the Linux server
|
|
is up and running. This is referred to as dynamic unlinking. Before you dynamically
|
|
unlink a storage space you must ensure that:<ul><li>No users are using the Linux drive to be unlinked.</li>
|
|
<li>The drive was linked dynamically.</li>
|
|
<li>If the disk is part of an active logical volume group, it cannot be unlinked.</li>
|
|
</ul>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
<div class="section"><h4 class="sectiontitle">The link sequence</h4><p>The link sequence is the order
|
|
in which storage spaces are presented to the Linux server by <span class="keyword">i5/OS™</span>.
|
|
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. </p>
|
|
<p>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.</p>
|
|
<p>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.</p>
|
|
<div class="important"><span class="importanttitle">Important:</span> You
|
|
must retain the correct link sequence for the Linux system and installation drives.
|
|
The system drive must be statically linked with sequence number 3; the installation
|
|
drive must be statically linked with sequence number 4. Otherwise the server
|
|
does not start. Therefore, you should never unlink the system or installation
|
|
drives.</div>
|
|
<p>Be careful about unlinking storage spaces from Linux servers.
|
|
If you unlink a drive from an integrated Windows<sup>®</sup> 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. </p>
|
|
<p>When you unlink a storage space, <span class="keyword">i5/OS</span> 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:</p>
|
|
<ul><li>/dev/sda = fixed link sequence number 3 </li>
|
|
<li>/dev/sdb = fixed link sequence number 4 </li>
|
|
<li>/dev/sdc = fixed link sequence number 5 </li>
|
|
<li>/dev/sdd = fixed link sequence number 6 </li>
|
|
<li>/dev/sde = dynamic link sequence number 1</li>
|
|
<li>/dev/sdf = dynamic link sequence number 2 </li>
|
|
<li>/dev/sdg = dynamic link sequence number 3</li>
|
|
</ul>
|
|
<p>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). </p>
|
|
<p>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. </p>
|
|
<p>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.</p>
|
|
</div>
|
|
</div>
|
|
<div>
|
|
<div class="familylinks">
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzau9mandrives.htm" title="This topic describes information and advice on how to manage iSeries disk storage allocated to integrated Linux servers.">Managing Linux drives</a></div>
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html> |