During the initial setup of a gFiler, you are required to specify one LUN that the gFiler is to own, but you can specify more. During the setup process, the system automatically creates a root volume and chooses one LUN (if you entered multiple LUNs) to be in the root volume. (Typically, the system chooses the smallest LUN.) Because that LUN was assigned to a volume through this process, the gFiler can read from and write to the LUN.
Until the LUN that a gFiler owns is configured to be part of a volume, it is a spare LUN.
During initial setup, the system adds one LUN that you specified in the disk assign command (in item 5 Maintenance on the boot menu) to the root volume. The system specifies any additional LUNs in item 5 as spares. After initial setup, you can also add spare LUNs to the gFiler, as described in About adding LUN ownership after initial setup.
For a LUN to be used for storage, you must add it to a NetApp volume. You can include the spare in the vol create command for a new volume (see Creating a volume.) Alternatively you can include the spare in the vol add command for an existing volume. See Adding LUNs (disks) to a volume by using the disk add command.
Each head of a GF270c must have one spare LUN of 1.5 GB or more assigned to it at all times, in case a problem occurs that results in a panic. The system can then dump core to the spare LUN and NetApp can analyze the core dump to determine the cause of the problem.
You can specify additional LUNs that a specific gFiler is to own anytime after Data ONTAP is installed. Circumstances in which you would add gFiler ownership of a LUN on a storage subsystem include the following:
LUN name format is shown in the following list:
<adapter>.<id>L<lun-id>
where
<adapter> is the adapter on the gFiler.
<id> is the channel adapter port on the storage subsystem.
<lun-id> is the full LUN ID
Example: 8a.0L4
<switch-name>:<port>.<id>L<lun-id>
where
<switch-name> is the name of the switch.
<port> is the switch port.
<id> is the device ID.
<lun-id> is the LUN ID.
Example: s2:4.126l4 or s2:4.127l4 (depending on the type of switch)
You use the disk assign command for assigning ownership of LUNs on a storage subsystem to a gFiler. To assign LUN ownership, complete the following steps.
| 1 |
If you are not going to be deploying SyncMirror, from the CLI prompt enter the disk assign command in the form disk assign fullLUNname1 fullLUNname2 ... You do not need to enter the pool parameter (-p) with the disk assign command. The pool parameter defaults to 0 (zero). |
| 2 |
If you are going to be deploying SyncMirror, enter the disk assign command with the pool parameter. You must use the pool parameter with the disk assign command, and you must enter the pool parameter correctly. See Planning for RAID mirroring for data protection for details so that you can plan your configuration correctly. For example:
disk assign storeAlun1 storeAlun2 -p 0 Typically, pool 0 is assigned to the local pool and pool 1 is assigned to the remote pool. |
| 3 |
ResultThe Local System ID is shown and the LUNs (disks) exported on the port are shown. |
| 4 |
Review the list of LUNs (disks) to confirm that all disks (LUNs) that you expected to be assigned to this gFiler (the local system) are shown with the ID of this gFiler. |
| 5 |
Note
A LUN cannot be used for storage until it becomes part of a volume, as described in How to enable a LUN to be used for storage.
To add new disks to a volume by using the disk add command, complete the following steps.
Note
You can also add LUNs while creating a volume, as described in Creating a volume.
Note
When adding LUNs to a volume by using automatic selection (that is, without using the -d option), Data ONTAP attempts to distribute I/O loads, such as alternating host adapters, to improve reconstruction performance. You can override this behavior by using the -d option to specify the LUNs you want.
If you want to change the ownership of a spare LUN from one gFiler to another within the same neighborhood, use the procedure in this section instead of using SnapMover. To change the ownership of a spare LUN, complete the following steps.
A gFiler must cease all the input and output operations to a LUN for you to do the following on the storage subsystem:
You can use the disk remove -w command to change the "state" of a LUN to unused. After the state is unused, the LUN can no longer be used by any neighborhood participants. (In contrast, if you want to remove disk ownership of a LUN but you want to preserve the ability for neighborhood participants to own it, you use the disk assign -s unowned command.)
The disk remove -w command does the following:
After you use the disk remove -w command on a LUN (from the gFiler), you can make the LUN unavailable to the gFilers (from the storage subsystem).
To prepare the LUN to be physically removed, complete the following step.
| 1 |
From the CLI prompt of the gFiler, enter the following command: disk remove -w <LUNfullname> |
The gFiler supports LUN size or composition changes only for unused LUNs. If a LUN is assigned as a spare LUN or an owned LUN (through the gFiler ownership scheme), you cannot change the size or composition of the LUN from the storage system management tool. Therefore, if you want to change the LUN size or composition, you must first make the LUN unused on the gFiler.
To change the size or composition of an unused LUN, complete the following steps.
| 1 |
On the gFiler, make a LUN unused by specifying the full name of the LUN in the disk remove -w command from the CLI command prompt (as described in About making a LUN unused). For example: |
| 2 |
On the storage subsystem, make the LUN invisible to the gFilers. |
| 3 | |
| 4 |
Make the LUN available to the gFiler again. Result |
| 5 |
Assign the LUN ownership by a gFiler (by using the disk assign command). |
If a LUN is mapped to a gFiler and you want to unallocate the LUN from the gFiler and map it to another host, use a LUN that is a spare. Make the LUN unused by using the disk remove -w command, as described in About making a LUN unused.
The gFiler formats LUNs in a special way to store checksum information that is used for data integrity checking on reads. One eighth of the space of the LUN is used for this purpose and is not available to the user.
For gFiler models other than the GF270c, one percent of the space on each LUN is reserved for core dumps. A minimum capacity of 272 GB results in 2.5 GB of core dump space (accounting for loss of space due to checksum formatting). Typically, this 1 percent allocation should be enough for core dumps.
Each head of a GF270c must have one spare LUN of 1.5 GB or more assigned to it at all times, in case a problem occurs that results in a panic. The system can then dump core to the spare LUN and NetApp can analyze the core dump to determine the cause of the problem.
Copyright © 1994-2004, Network Appliance, Inc. All rights
reserved.
Part No. 210-00661
File: manage4.htm
Last updated: 04/13/04 09:26:46