diff --git a/LDP/guide/docbook/EVMSUG/accelerator-ug.xml b/LDP/guide/docbook/EVMSUG/accelerator-ug.xml new file mode 100644 index 00000000..a6219fc8 --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/accelerator-ug.xml @@ -0,0 +1,103 @@ + + +Accelerator Keys in the GUI + +You can avoid using a mouse for navigating the EVMS GUI by +using a series of key strokes, or "accelerator keys," instead. +The following sections tell how to use accelerator keys +in the EVMS Main Window, the Selection Window, and the Configuration Options +Window. + + +Main Window Accelerator Keys +In the Main Window view, use the following keys to navigate: + +Left and right arrow keysNavigate between the notebook tabs of the different views. + +Down arrow key and Spacebar keyBring keyboard focus into the view. + + + +Once in a view, use the following keys to navigate: +up and down arrow keysAllow movement around the window. + +"+" keyOpens an object tree. + +"-" keyCollapses an object tree. + +ENTER keyBrings up the context menu (on a row). + +Arrow keysNavigate a context menu. + +ENTERActivates an item. + +CANCELDismisses the context menu. + +TabGets you out of the view and moves you back up to the notebook tab. + + + + +To access the action bar menu, press the Alt key and +then the underlined +accelerator key for the menu choice (for example, "A" for the +Actions +dropdown menu). + + +In a dropdown menu, you can use the up and down arrow keys +to navigate. You could also just type the accelerator key for the menu +item, which is the character with the underscore. For example, to initiate +a command to delete a container, type Alt + "A" + "D" + "C." + + +Ctrl-S is a shortcut to initiate saving changes. +Ctrl-Q is a shortcut to initiate quitting the EVMS GUI. + + + + +Selection Window Accelerator Keys + +A selection window typically contains a selection list, plus four to five +buttons below it. Use the following keys to navigate in the selection window: + + +Tab keyNavigate (change keyboard focus) between the list and the buttons. + +Up and down arrow keysNavigate within the selection list. + +Spacebar keySelect and unselect items in the selection list. + + +To activate a button, press the Enter key on the button or type the accelerator character (if one exists). + + + +Configuration Options Window Accelerator Keys + +Use the following keys to navigate in the configuration options window: + + +Tab keyCycles focus between fields and buttons. +Left and right arrow keysNavigates the folder tabs if the window has a widget notebook. +Spacebar key or the down arrowSwitches focus to a different notebook page. +Enter key or typing accelerator character (if one exists)Activates a button + + + +For widgets, use the following keys to navigate: + +Tab keyCycles forward through a set of widgets. + +Shift-Tab keyCycles backward through a set of widgets. + + + +The widget navigation, selection, and activation is the same in all dialog +windows. + + + + + \ No newline at end of file diff --git a/LDP/guide/docbook/EVMSUG/addfeatures-ug.xml b/LDP/guide/docbook/EVMSUG/addfeatures-ug.xml new file mode 100644 index 00000000..c77a43d6 --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/addfeatures-ug.xml @@ -0,0 +1,155 @@ + + + +Adding features to an existing volume + +This chapter tells how to add additional EVMS features to an +already existing EVMS volume. + + + +Why add features to a volume? +EVMS lets you add features such as drive linking or bad block relocation to +a volume that already exists. By adding features, you avoid having to potentially +destroy the volume and recreate it from scratch. For example, take the +scenario of a volume that contains important data but is almost full. +If you wanted to add more data to that volume but no free space existed on the +disk immediately after the segment, you could add a drive link to the volume. +The drive link concatenates another object to the end of the volume and +continues seamlessly. + + + + +Example: add drive linking to an existing volume + The following example shows how to add drive linking to a volume with +the EVMS GUI, Ncurses, and CLI interfaces. + + +
Add drive linking to an existing volume + +The following sections show how to add a drive link to volume +/dev/evms/vol and call the drive link "DL." + + + + +NOTEDrive linking can be done only on +EVMS volumes; therefore, /dev/evms/vol must be converted to an EVMS volume if it is not +already. +
+ +Using the EVMS GUI +Follow these steps to add a drive link to the volume with the EVMS GUI: + + + Select Actions + AddFeature to Volume. + + + + Select /dev/evms/vol + + + Click Next. + + + Select Drive Linking Feature. + + + Click Next. + + + Type DL in the Name Field. + + + Click Add. + + + + +Alternatively, you can perform some of the steps to add a drive link with the GUI +context sensitive menu: + + From the Volumes tab, right click + /dev/evms/vol. + Click Add feature... + Continue adding the drive link beginning with step 3 of the + GUI instructions. + + + + + +Using Ncurses + Follow these steps to add a drive link to a volume with Ncurses: + + + Select ActionsAdd + Feature to Volume. + + + + Select + /dev/evms/vol. + + + Activate Next. + + + + Select + Drive Linking Feature. + + + Activate Next. + + + Press Spacebar to edit the Name field. + + + At the "::" prompt enter DL. + + + Press Enter. + + Activate Add. + + + + +Alternatively, you can perform some of the steps to add a drive link with the +context sensitive menu: + + +From the Volumes view, press Enter on /dev/evms/vol. + +Activate the Add feature menu item. + +Continue adding the drive link beginning with step 3 of the Ncurses instructions. + + + + + +Using the CLI + + + Use the + add feature to add a feature to an existing volume. + Specify the command name followed by a colon, followed by any options + and the volume to operate on. To determine the options for a given + feature, use the following query: + + +query: plugins, plugin=DriveLink, list options + +The option names and descriptions are listed to help you construct +your command. For our example, the command would look like the following: + +add feature: DriveLink={ Name="DL }, /dev/evms/vol + + + + + \ No newline at end of file diff --git a/LDP/guide/docbook/EVMSUG/appx-csm.xml b/LDP/guide/docbook/EVMSUG/appx-csm.xml new file mode 100644 index 00000000..b31c7bd6 --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/appx-csm.xml @@ -0,0 +1,132 @@ + +The CSM plug-in + +The Cluster Segment Manager (CSM) is the EVMS plug-in that identifies and +manages cluster storage. The CSM protects disk storage objects by writing metadata +at the start and end of the disk, which prevents other plug-ins from attempting to use the disk. +Other plug-ins can look at the disk, but they cannot see their own metadata signatures +and cannot consume the disk. The protection that CSM provides allows the CSM to +discover cluster storage and present it in an appropriate fashion to the system. +All cluster storage disk objects must be placed in containers that have the +following attributes: + + + +cluster ID that identifies the cluster management software + + + +node ID that identifies the owner of the disk objects + + + +storage type: private, shared, or deported + + + + +The CSM plug-in reads metadata and constructs containers that consume +the disk object. Each disk provides a usable area, mapped as an EVMS +data segment, but only if the disk is accessible to the node viewing +the storage. + +The CSM plug-in performs these operations: + + + + + +examines disk objects + + + + +creates containers + + + + +uses the containers to consume disk objects + + + + +produces data segment objects if the disk is accessible to the node + + + + + +Assigning the CSM plug-in +Assigning a segment manager to a disk means that you want the plug-in to +manage partitions on the disk. In order to do this, the plug-in needs to create and +maintain appropriate metadata. The CSM creates the follow three segments on the disk: + + + +primary metadata segment + + + +usable area data segment + + + +secondary metadata segment + + + +The CSM collects the information it needs to perform the assign operation with the +following options: + + +NodeId +Choose only from a list of configured node IDs that have been +provided to the CSM by clustering software. The default selection is the +node from which you are running the EVMS user interface. + + +Container Name +The name for the container. Currently, you need to keep this name unique +across the cluster to prevent name-in-conflict errors should the container fail over to +another node that has a container with the same name. Later releases of EVMS will assist +you with this. + + +Storage Type +Can be either: share, private, or deported. + + + + +Note that you would typically assign the CSM to a disk when you want to +add a disk to an existing CSM container. If you are creating a new container, you +have a choice of using either: + +ActionsCreateContainer + or +ActionsAddSegment Manager. + + +If the container doesn't exist, it will be created for it. If the container already +exists, the disk will be added to it. + + + +Unassigning the CSM plug-in +Unassigning a CSM plug-in results in the CSM removing its metadata from +the specified disk storage object. The result is that the disk has no segments +mapped and appears as a raw disk object. The disk is removed from the +container that consumed it and the data segment is removed as well. + + + +Deleting a CSM container + +An existing CSM container cannot be deleted if it is producing any data segments, +because other EVMS plug-ins might be building higher-level objects on the CSM objects. +To delete a CSM container, first remove disk objects from the container. When the last +disk is removed, the container is also removed. + + + diff --git a/LDP/guide/docbook/EVMSUG/appx-dos.xml b/LDP/guide/docbook/EVMSUG/appx-dos.xml new file mode 100644 index 00000000..b59d8fa9 --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/appx-dos.xml @@ -0,0 +1,325 @@ + + +The DOS link plug-in + +The DOS plug-in is the most commonly used EVMS segment manager +plug-in. The DOS plug-in supports DOS disk partitioning as well as: + + +OS/2 partitions that require extra metadata sectors. + + +Embedded partition tables: SolarisX86, BSD, and UnixWare. + + + +The DOS plug-in reads metadata and constructs segment storage +objects that provide mappings to disk partitions. + + + +How the DOS plug-in is implemented +The DOS plug-in provides compatibility with DOS partition tables. +The plug-in produces EVMS segment storage objects that map primary partitions +described by the MBR partition table and logical partitions +described by EBR partition tables. + + +DOS partitions have names that are constructed from two pieces +of information: + + + +The device they are found on. + + +The partition table entry that provided the information. + + + +Take, for example, partition name hda1, which +describes a partition that is found on device hda +in the MBR partition table. +DOS partition tables can hold four entries. +Partition numbers 1-4 refer to MBR partition records. Therefore, our +example is telling us that partition hda1 is described +by the very first partition record entry in the MBR partition table. +Logical partitions, however, are different than primary partitions. +EBR partition tables are scattered across a disk but are linked together +in a chain that is first located using an extended partition record found +in the MBR partition table. +Each EBR partition table contains a partition record that describes a logical +partition on the disk. +The name of the logical partition reflects its position in the EBR chain. +Because the MBR partition table reserves numerical names 1-4, the very +first logical partition is always named 5. +The next logical partition, found by following the EBR chain, is called 6, +and so forth. +So, the partition hda5 is a logical partition that is +described by a partition record in the very first EBR partition table. + + +While discovering DOS partitions, the DOS plug-in also looks for +OS/2 DLAT metadata to further determine if the disk is an OS/2 disk. +An OS/2 disk has additional metadata and the metadata is validated during +recovery. +This information is important for the DOS plug-in to know because an OS/2 +disk must maintain additional partition information. (This is why the +DOS plug-in asks, when being assigned to a disk, if the disk is a +Linux disk or an OS/2 disk.) The DOS plug-in needs to know how much +information must be kept on the disk and what kind of questions it should +ask the user when obtaining the information. + + + +An OS/2 disk can contain compatibility volumes as well as logical volumes. +A compatibility volume is a single partition with an assigned drive +letter that can be mounted. An OS/2 logical volume is a drive link of 1 +or more partitions that have software bad-block relocation at the +partition level. + + + +Embedded partitions, like those found on a SolarisX86 disk or a BSD +compatibility disk, are found within a primary partition. +Therefore, the DOS plug-in inspects primary partitions that it has +just discovered to further determine if any embedded partitions exist. +Primary partitions that hold embedded partition tables have partition +type fields that indicate this. +For example, a primary partition of type 0xA9 probably has a BSD partition +table that subdivides the primary partition into BSD partitions. +The DOS plug-in looks for a BSD disk label and BSD data partitions in the +primary partition. +If the DOS plug-in finds a BSD disk label, it exports the BSD partitions. Because +this primary partition is actually just a container that holds the BSD +partitions, and not a data partition itself, it is not exported by the +DOS plug-in. +Embedded partitions are named after the primary partition they were +discovered within. As an example, hda3.1 is +the name of the first embedded partition found within primary partition +hda3. + + + +Assigning the DOS plug-in + +Assigning a segment manager to a disk means that you want the plug-in +to manage partitions on the disk. +In order to assign a segment manager to a disk, the plug-in needs to +create and maintain the appropriate metadata, which is accomplished +through the "disk type" option. +When you specify the "disk type" option and choose +Linux or OS/2, the plug-in knows what sort of metadata it needs to keep +and what sort of questions it should ask when creating partitions. + + + +An additional OS/2 option is the "disk name" option, by which you can +provide a name for the disk that will be saved in OS/2 metadata and that +will be persistent across reboots. + + + +Creating DOS partitions + +There are two basic DOS partition types: + + + +A primary partition, which is described by a partition record +in the MBR partition table. + + +A logical partition, which is described by a partition record +in the EBR partition table. + + + +Every partition table has room for four partition records; however, +there are a few rules that impose limits on this. + + + +An MBR partition table can hold four primary partition records unless you +also have logical partitions. +In this case, one partition record is used to describe an extended +partition and the start of the EBR chain that in turn describes +logical partitions. + + + +Because all logical partitions must reside in the extended partition, you +cannot allocate room for a primary partition within the extended partition +and you +cannot allocate room for a logical partition outside or adjacent to this area. + + + +Lastly, an EBR partition table performs two functions: + + + +It describes a logical partition and therefore uses a partition +record for this purpose. + + +It uses a partition record to locate the next EBR partition table. + + + +EBR partition tables use at most two entries. + + +When creating a DOS partition, the options you are presented with depend +on the kind of disk you are working with. However, both OS/2 disks and +Linux disks require that you choose a freespace segment on the disk +within which to create the new data segment. The create options are: + + + +size + +The size of the partition you are creating. +Any adjustments that are needed for alignment are performed by the +DOS plug-in and the resulting size might differ slightly from the +value you enter. + + + + +offset + +Lets you skip sectors and +start the new partition within the freespace area by specifying a +sector offset. + + + + +type + +Lets you enter a partition type or choose from a list of +partition types; for example, native Linux. + + + + +primary + +Lets you choose between creating a primary or logical partition. +Due to the rules outlined above, you might or might not have a choice. +The DOS plug-in can determine if a primary or logical partition can be +created in the freespace area you chose and disable this choice. + + + + +bootable + +Lets you enable the sys_ind flag field in a primary partition +and disable it when creating a logical partition. +The sys_ind flag field identifies the active primary partition for booting. + + + + + + +Additional OS/2 options are the following: + + + +partition name + + +An OS/2 partition can have a name, like Fred or Part1. + + + + +volume name + + +OS/2 partitions belong to volumes, either +compatibility or logical, and volumes have names. However, because +the DOS plug-in is not a logical volume manager, it cannot actually +create OS/2 logical volumes. + + + + +drive letter + +You can specify the drive letter for an OS/2 partition, but it +is not a required field. Valid drive letters are: C,D...Z. + + + + + + + +Expanding DOS partitions + +A partition is a physically contiguous run of sectors on a disk. +You can expand a partition by adding unallocated sectors to the initial +run of sectors on the disk. Because the partition must remain physically +contiguous, a partition can only be expanded by growing into an unused +area on the disk. +These unused areas are exposed by the DOS plug-in as freespace segments. +Therefore, a data segment is only expandable if a freespace segment +immediately follows it. Lastly, because a DOS partition must end on a +cylinder boundary, DOS segments are expanded in +cylinder size increments. This means that if the DOS segment you want +to expand is followed by a freespace segment, you might be unable to +expand the DOS segment if the freespace segment is less than a cylinder +in size. + + +There is one expand option, as follows: + + +size + + +This is the amount by which you want to expand the data segment. The amount must +be a multiple of the disk's cylinder size. + + + + + + +Shrinking DOS partitions + + +A partition is shrunk when sectors are removed from the end of the +partition. +Because a partition must end on a cylinder boundary, a partition is +shrunk by removing cylinder amounts from the end of the segment. + + +There is one shrink option, as follows: + + +size + +The amount by which you want to reduce the size of the segment. +Because a segment ends on a cylinder boundary, this value must be +some multiple of the disk's cylinder size. + + + + + + + +Deleting partitions + +You can delete an existing DOS data segment as long as it is not +currently a compatibility volume, an EVMS volume, or consumed by another +EVMS plug-in. +No options are available for deleting partitions. + + + \ No newline at end of file diff --git a/LDP/guide/docbook/EVMSUG/appx-drivelink.xml b/LDP/guide/docbook/EVMSUG/appx-drivelink.xml new file mode 100644 index 00000000..a5e8082a --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/appx-drivelink.xml @@ -0,0 +1,143 @@ + + + +The drive link plug-in + +The EVMS drive link plug-in is an aggregating plug-in that +combines storage objects into a single object. +The resulting drive link storage object can be made into a +compatibility volume, EVMS volume, or even be consumed by +higher-level storage objects. +The drive link plug-in is one way to create large storage objects and +volumes from smaller individual pieces. + + +How drive linking is implemented +The drive link plug-in consumes storage objects, called link +objects, producing a larger drive link object whose address space spans +the link objects. +The drive link plug-in knows how to assemble the link objects so as to +create the exact same address space every time. +The information required to do this is kept on each link child as persistent +drive-link metadata. +During discovery, the drive link plug-in inspects each known storage +object for this metadata. +The presence of this metadata identifies the storage object as a link object. +The information contained in the metadata is sufficient to: + + +Identify the link object itself. + + +Identify the drive link storage object that the link object belongs to. + + + +Identify all link objects belonging to the drive link storage. +object + + +Establish the order in which to combine the child link objects. + + + + +If any link objects are missing at the conclusion of the discovery +process, the drive link storage object contains gaps where the missing +link objects occur. +In such cases, the drive link plug-in attempts to fill in the gap with a +substitute link object and construct the drive link storage object in +read-only mode, which allows for recovery action. +The missing object might reside on removable storage that has been removed or +perhaps a lower layer plug-in failed to produce the missing object. +Whatever the reason, a read-only drive link storage object, together +logging errors, help you takea the appropriate actions to recover the drive link. + + + + +Creating a drive link + +The drive link plug-in provides a list of acceptable objects from which it can create a drive link object. +When you create an EVMS storage object and choose +the drive link plug-in, a list of acceptable objects is provided that you +simply choose from. +The ordering of the drive link is implied by the order in which you pick objects from the +provided list. +After you provide a name for the drive link, the identified link +objects are consumed and the new drive link object is produced. +There are no create options. + + + +Expanding partitions + +Drive links are aggregating objects that can be expanded in the following ways: + + + + +By adding an additional storage object to the end of the drive link. + + + + +Bexpanding the last storage object in the drive link. + + + + + +If the expansion point is the drive link storage object, you can perform the +expansion by choosing from a list of objects that the drive link plug-in +finds acceptable for the expansion. +Multiple objects can be selected and added to the drive link. + + + +If the expansion point is a link object, then the +plug-in that produced the link object does the expansion. +For example, if the link object was a segment, then the segment manager +plug-in that produced the storage object expands the link object. +Afterward, the drive link storage object is resized to reflect the expansion. + + +There are no expand options. + + + + +Shrinking a drive link + +Drive links can be shrunk in the following ways: + +By removing link objects from the end of the drive link. + +By shrinking the last storage object in the drive link. + + + +Removing +a link object from anywhere other than the end of the drive link produces a gap in the drive link address +space, similar to the gap produced by missing link objects. +The drive link plug-in attempts to orchestrate the shrinking of a +drive-link storage object by only listing the last link object. +If you select this object, the drive link plug-in then lists the next-to-last link object, and so forth, moving backward through the link +objects to satisfy the shrink command. + + +There are no shrink options. + + + +Deleting a drive link + +A drive link can be deleted as long as it is not currently a +compatibility volume, an EVMS volume, or consumed by another EVMS plug-in. + + +No options are available for deleting a drive link storage object. + + + + \ No newline at end of file diff --git a/LDP/guide/docbook/EVMSUG/appx-ext23.xml b/LDP/guide/docbook/EVMSUG/appx-ext23.xml new file mode 100644 index 00000000..007bc98e --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/appx-ext23.xml @@ -0,0 +1,123 @@ + +Ext-2/3 file system interface module + + +The Ext-2/3 FSIM lets EVMS users create and manage Ext2 and +Ext3 file systems from +within the EVMS interfaces. In order to use the Ext-2/3 FSIM, +the e2fsprogs package +must be installed on your system. The e2fsprogs package +can be found at +http://e2fsprogs.sourceforge.net/. + + +Creating Ext-2/3 file systems + +Ext-2/3 file systems can be created with mkfs on any EVMS +or compatibility volume that does not already +have a file system. The following options are available for creating +Ext-2/3 file systems: + + + +badblocks + +Perform a read-only check for bad blocks on the volume +before creating the file system. The default is false. + + + +badblocks_rw + +Perform a read/write check for bad blocks on the volume before +creating the file system. The default is false. + + + + +vollabel + +Specify a volume label for the file system. The default is none. + + + + +journal + +Create a journal for use with the Ext2 file system. The default +is true. + + + + + + + + +Checking Ext-2/3 file systems + +The following options are available for checking Ext-2/3 file systems with +fsck: + + + + +force + +Force a complete file system check, even if the file system is +already marked clean. The default is false. + + + +readonly + +Check the file system is in read-only mode. Report but do not +fix errors. If the file system is mounted, this option is +automatically selected. The default is false. + + + + +badblocks + +Check for bad blocks on the volume and mark them as busy. The +default is false. + + + + +badblocks_rw + +Perform a read-write check for bad blocks on the volume and mark +them as busy. The default is false. + + + + + + + +Removing Ext-2/3 file systems + + +An Ext-2/3 file system can be removed from its volume if the file system is +unmounted. This operation involves erasing the superblock from the volume +so the file system will not be recognized in the future. There are no +options available for removing file systems. + + + + +Expanding and shrinking Ext-2/3 +file systems + + +An Ext-2/3 file system is automatically expanded or shrunk when its volume +is expanded or shrunk. +However, Ext-2/3 only allows these operations if the volume is +unmounted, because online expansion and shrinkage is not yet supported. + + + + + diff --git a/LDP/guide/docbook/EVMSUG/appx-initram.xml b/LDP/guide/docbook/EVMSUG/appx-initram.xml new file mode 100644 index 00000000..6e057310 --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/appx-initram.xml @@ -0,0 +1,407 @@ + + + + + +Building an init-ramdisk to use with EVMS + +EVMS versions 1.9.0 and later perform volume discovery in user space and +communicate with kernel drivers to activate the volumes. This process presents +a problem with having the root file system on an EVMS volume. In order for the +root file system volume to be activated, the EVMS tools must be running. However, +in order to access the EVMS tools, the root file system must be mounted. +The solution to this dilemma is to use an initial ramdisk (initrd). An initrd is a +ram-based device that acts as a temporary root file system at boot time and provides +the ability to run programs and load modules that are necessary to activate the true +root file system. Thus, in order to have your root file system on an EVMS volume, you +need to create and use an initrd. +The following sections provide instructions for creating a new initrd image for use +with EVMS. + +Build and install EVMS +Follow the normal EVMS installation instructions for configuring your kernel +and building the EVMS tools. See or the INSTALL file in +the EVMS package for more information. + + +Kernel support for initrd +Before you can start creating the initrd, make sure your kernel +supports ramdisks. You can verify that your kernel supports ramdisks +when the kernel is being configured; if it does not support ramdisks, you +change the settings so that the kernel does support ramdisks. +Start the kernel configuration: +cd /usr/src/linux +make xconfig +On the Main Menu screen, under the section for Block Devices, check +to see if "RAM disk support" and "Initial RAM disk (initrd) support" +are supported (a "Y" should be in the field before each entry). +If they are not supported, enter a "Y" for "RAM disk support" and +"Initial RAM disk (initrd) support." +Main Menu +-Block Devices +<Y>RAM disk support +<Y>Initial RAM disk (initrd) support + +This support must be built statically into the kernel. Building RAM disk support +as a module will not work. The "Default RAM disk size" option is not important at +this time, because it can be modified with a command-line option to the kernel. +Save your kernel configuration and rebuild and reinstall your kernel. + + +Build the initrd image +The next step is to build the actual ramdisk image, which is +described in the following subsections. +The important thing to remember is that any program that needs to +run from the initrd needs to be copied to the initrd. +In addition, any shared libraries that are needed by programs that run +from the initrd need to be copied to the initrd as well. + +Create a new, blank initrd + +Start by creating a new initrd image with an ext2 file system. +The following example creates the initrd image at +/boot/initrd-evms. +You can choose to use a different file name if you wish. + +The size of the initrd in the following example is 16 MB. +You can make the initrd larger or smaller by adjusting the "count" +value. +The minimum size needed for all the required EVMS tools and supporting +libraries is about 11 MB. +If you are installing kernel modules to your initrd (see step 3-H below) +or other non-EVMS programs, the size might need to be increased. +dd if=/dev/zero of=/boot/initrd-evms bs=1M count=16 +mke2fs -F -m 0 -b 1024 /boot/initrd-evms + + +Mount the initrd +In order to copy all the required files to the initrd, the initrd must be mounted +through a loopback device. To mount the initrd through a loopback device requires +that you have loopback support compiled in your kernel (or as a kernel module). +See the "Block Devices" menu in the kernel configuration for more information +about loopback. +mkdir /mnt/initrd +mount -t ext2 -o loop /boot/initrd-evms /mnt/initrd + + +Set up the basic directory structure +Use the following commands to create several basic directories that +are required on the initrd: +cd /mnt/initrd +mkdir bin dev etc lib proc sbin var +cd var +mkdir lock log + + +Copy helpful utilities +The script that runs in the initrd requires a few common command-line utilities, which +you can create with the following commands: +cd /bin +cp -a bash cat echo expr grep mount sh umount /mnt/initrd/bin +cd /etc +cp fstab /mnt/initrd/etc + + +Copy supporting libraries +The utilities from the previous step, along with the EVMS tools, require a few +common shared libraries. You can create these shared libraries with the following +commands: +cd /lib +cp -a ld-* /mnt/initrd/lib +cp -a libc-* libc.* /mnt/initrd/lib +cp -a libdl-* libdl.* /mnt/initrd/lib +cp -a libpthread* /mnt/initrd/lib +cp -a libtermcap* /mnt/initrd/lib +It is possible that some of the utilities (bash in particular) require additional +libraries. Use the ldd command to determine if you need additional +libraries copied to your initrd. For example, output from +the ldd /bin/bash command provides a list similar to the following: +libtermcap.so.2 => /lib/libtermcap.so.2 (0x40020000) +libdl.so.2 => /lib/libdl.so.2 (0x40024000) +libc.so.6 => /lib/libc.so.6 (0x40027000) +/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000000) +All libraries listed by ldd need to be copied to the +/lib directory on the initrd. + + +Copy the EVMS tools +Several EVMS libraries and a couple of executables need to be copied +to the initrd. +First, you need to locate where the EVMS libraries were installed. By default, +these libraries are installed in /lib. If you specified a different +prefix or libdir when you configured EVMS, the libraries might be located in a +different directory. It is important that these libraries be installed in the same +location on the initrd as they are on your real system. For example, if the libraries +installed in /lib, the libraries need to be copied to /lib on the initrd; +If the libraries are installed in /usr/lib, they need to be copied to /usr/lib on the initrd. +The following example assumes the libraries are installed in /lib. Only +the shared libraries (.so) need to be copied. The static versions (.a) are not +needed on the initrd. +cd /lib +cp -a libevms*so* /mnt/initrd/lib +cp -a libdlist*so* /mnt/initrd/lib +Next, copy the plug-in libraries to the initrd. The plug-ins are always installed +in the evms subdirectory of the directory where libevms is installed. +Not all of the plug-ins need to be copied to the initrd. Several plug-ins are +only for interfacing with the file system utilities and are not necessary at boot time. +Other plug-ins are only for interfacing with clustering packages, which cannot be +started until the regular boot process. +The following is a list of the specific plug-ins that do not need to be installed: + +csm +ext2 +ha +jfs +reiser +replace +rsct +swap +xfs + +Create and change directory to /lib/evms: +mkdir /mnt/initrd/lib/evms +cd /lib/evms +Copy the contents of the /lib/evms directory, minus the plug-ins +listed earlier that +do not need to be installed, to /mnt/initrd/lib/evms: +for foo in aix bbr bsd disk dos drivelink gpt lvm md os2 s390 snapshot sparse +do + cp -a *$foo* /mnt/initrd/lib/evms +done +Next, copy the activation program to the initrd. The full user interfaces are +not needed, because the only thing the initrd does is activate the volumes. +Unlike the EVMS libraries, the exact location of this program in the initrd is not +important, so it can simply go in sbin: +cd /sbin +cp evms_activate /mnt/initrd/sbin +cp get_dev_num /mnt/initrd/sbin +Finally, if you have an /etc/evms.conf file installed, you should copy it to +the initrd so that EVMS uses the correct options during activation. (However, +if you have an /etc/evms.conf file but have never modified it for your system, it should still have all the default values and does not necessarily need to +be installed on the initrd.) +cd /etc +cp evms.conf /mnt/initrd/etc + + +Set up disk devices +The initrd needs to be set up to reflect the disk devices that are on your system. +EVMS needs to find the disks in order to activate the volumes. +Before setting up the disk devices on the initrd, determine if you are +using devfs. If you are not sure, you can quickly check for the file +/dev/.devfsd. If /dev/.devfsd exists, you are running devfs. +You can also +check your kernel configuration in the "Filesystems" menu. If +"/dev file system support" and "Automatically mount at boot" are enabled, you are +running devfs. + +devfs users +Because devfs runs automatically within the initrd, you do not need to +manually copy the device files to the initrd. However, devfs does need to be +mounted within the initrd for it to work properly. There are two ways to accomplish this: + +In the kernel configuration, in the "Filesystems" menu, set the +"Automatically mount at boot time" option. With this option set, devfs will be +automatically mounted on /dev when the initrd is loaded. +Manually mount devfs from the linuxrc script before running +evms_activate. See for more details. + + + + +devfsd users +EVMS does not require devfs users to run devfsd. +However, if you do run +devfsd, you also need to run it on the initrd to ensure that all disks and segments +are discovered with the same names on both the initrd and the real system. Thus, if +you run devfsd, you need to copy the devfsd program and +config file to the initrd, as +follows: +cd /sbin +cp devfsd /mnt/initrd/sbin +cd /etc +cp devfsd.conf /mnt/initrd/etc +Next, examine the devfsd.conf file (the one you just copied to the ramdisk) with +a text editor. First look for a line like this: +LOOKUP.* MODLOAD +Also in the devfsd file, look for a line that begins with RESTORE. This line +specifies a directory where devfsd stores changes to +the /dev file system. Create this +directory in your initrd. For example, if your devfsd.conf file contains the line +"RESTORE /dev-state," issue the following commands to prevent error messages from +being generated when devfsd starts within the initrd: +cd /mnt/initrd +mkdir dev-state + + +Non-devfs users +Because devfs is not running and mounted within the initrd, you need to +manually copy the necessary device node files to the initrd. If you only have IDE +or SCSI disks, the following commands should be sufficient. If you specifically +know which disks are on your system, you can copy only those device files. +cd /dev +cp -a hd[a-z] /mnt/initrd/dev +In addition to the disk devices, you also need a console device: +cp -a console /mnt/initrd/dev + + + + +Copy kernel modules +If you have any kernel modules that need to be loaded in order for EVMS to +run, those modules need to be copied to the initrd. In particular, if you build your +IDE or SCSI drivers, the Device Mapper or MD/Software-RAID drivers, or any +required file systems as modules, they need to be present on the initrd so they +can be loaded before you run EVMS and try to mount the root file system. +If you build all of the necessary drivers and file systems statically into the +kernel, you can skip this step. Skipping this step is the recommended approach so +that you avoid any possible problems that might be caused by required modules missing +from the initrd. +When copying the kernel modules, it is probably safest to copy the entire +module directory so as not to miss any modules that might be needed on the initrd: +mkdir /mnt/initrd/lib/modules +cd /lib/modules +cp -a x.y.z /mnt/initrd/lib/modules +x.y.z is the version of the kernel that will be running EVMS and the initrd. + +In addition, you will need the module-loading utilities, and probably the module +configuration file: +cd /sbin +cp modprobe /mnt/initrd/sbin +cd /etc +cp modules.conf /mnt/initrd/etc + + +Write the linuxrc script +At this point, all of the necessary files, programs, and libraries should be on +the initrd. The only thing remaining is the linuxrc script. +When the kernel mounts the initrd, it tries to run a script called linuxrc, in the root of +the initrd. This script performs all the actions necessary for the initrd, and prepares the +root device so that it can be mounted when the initrd exits. +A sample linuxrc script is provided in the doc directory of the EVMS source package. +You can use this script as a starting point. +Copy the linuxrc sample to your initrd: +cd /usr/src/evms-2.0.0/doc +cp linuxrc /mnt/initrd +Open the linuxrc sample script in your favorite text editor. The following paragraphs +provide a brief explanation of what the linuxrc does at boot time and offer suggestions for +modifying the script for your system. + +The first section tries to mount devfs. You only need to +uncomment this section if you are running devfs and do not automatically mount +devfs on /dev (see for more details). +The next section tries to start the devfs daemon. If devfs +is not running or devfsd is not present, this section is skipped. +The next section mounts the proc file system. +EVMS looks in the /proc file system to find the location of the +Device Mapper driver. Also, later parts of the linuxrc script try to +access /proc in order to properly set the root file system device. +The next section loads the kernel modules. If you did not copy any +kernel modules to your initrd (), you can leave this section commented out. +If you need to load kernel modules from the initrd, this is the place to do it. Use +the modprobe command for each module that needs to be loaded. +A few examples have been provided within the section. +The next section is where EVMS runs and activates all of the volumes. +The next section examines the kernel command line for a parameter +that specifies the root volume. More information about how to set up this +parameter is included in . Device Mapper +dynamically allocates all device numbers, which means it is possible that the +root volume specified to LILO or GRUB might have a different number when the +initrd runs than when the system was last running. In order to make sure the +correct volume is mounted as root, the linuxrc script must determine what the +desired root volume name is, determine the number for that device, and set +that value in the appropriate file in /proc. +Finally, the /proc file system can be unmounted. +Also, devfs +can be unmounted (but only if it was mounted at the start of the script). + +When the linuxrc script completes, the kernel automatically tries to +mount the root file system, and the initrd is removed from memory. + + + +Unmount the initrd image +The contents of the initrd should now be complete and you can unmount it. + + +Compress the initrd image +To conserve space, compress the initrd image: +gzip /boot/initrd-evms + + + + +Set up the boot loader +In order to actually use the initrd at boot time, the boot-loader must know the location +of the initrd so it can tell the kernel where to load it from. There are also some other changes +that the boot loader needs to know about in order to successfully mount your EVMS +volume as the root file system. The procedure is slightly different for LILO and GRUB, the +two main boot loaders used with Linux. + +LILO procedure +LILO uses the file /etc/lilo.conf as its configuration file. Edit +the file with a text editor. If you have not already done so, add an image section +for the kernel you will be using with EVMS. The section should look something like this: +image = /boot/vmlinuz-2.4.20 # Replace with your kernel image + label = 2.4.20 #Any label you'd like to use + read-only + initrd = /boot/initrd-evms.gz # The compressed initrd you just created + append = "ramdisk=16384 root=/dev/evms/Root" +The last line (beginning with "append") in this section is very important. The line specifies +parameters that are passed to the kernel command line. The "ramdisk" option +overrides the default ramdisk size. This value is in kilobytes and needs to be +at least as big as the initrd image you created in step . Thus, if your initrd +image is 20 MB, you need to set this value to 20 * 1024 = 20480. +The "root" option in the "append" line is not only a parameter to the kernel +but also an indicator to the linuxrc script () so it can determine the name of +your root file system and use it to tell the kernel the actual root device after the +volumes have been activated. Obviously, you should set this option to the actual +name of your root volume. +After updating /etc/lilo.conf, run lilo to install the boot-loader. + + +GRUB procedure +GRUB uses the file /boot/grub/menu.lst as its configuration file. +Edit this file with a text editor. If you have not already, add a menu item for the kernel +you will be using with EVMS. The menu item should look something like this: +title 2.4.20 # Any label you'd like to use + kernel (hd0,0)/vmlinuz-2.4.20 root=/dev/evms/Root ramdisk=16384 + # Replace with the name of your kernel image. + # See the Grub documentation for which (hdx,y) + # value to use. + initrd (hd0,0)/initrd-evms.gz # The compressed initrd image you just created +The extra information after the kernel image name is very important. +These are parameters that are passed to the kernel command line. +The "ramdisk" option +overrides the default ramdisk size. This value is in kilobytes and needs to be +at least as big as the initrd image you created in . Thus, if your initrd +image is 20 MB, you need to set this value to 20 * 1024 = 20480. +The "root" option in the "kernel" line is not only a parameter to the kernel +but also an indicator to the linuxrc script () so it can determine the name of +your root file system and use it to tell the kernel the actual root device after the +volumes have been activated. Obviously, you should set this option to the actual +name of your root volume. + + + + +Update the file system configuration +Because the goal of creating the initrd is to use an EVMS volume as your +root file system, you also need to update the fstab file. Edit /etc/fstab with a text editor. +There should be an entry in the file similar to the following: +/dev/evms/RootVolume / ext2 defaults 1 1 +Replace RootVolume with the actual name of your root volume, and +ext2 with +the appropriate type for the root file system. + + +Reboot the system +The kernel has been built with the appropriate support, the initrd image has +been constructed, and the boot-loader has been configured. You are now +ready to reboot your system using your EVMS volume as the root file system. +In general, you should still run evms_activate during your regular boot scripts. +Even though the volumes will already be activated, running evms_activate +makes sure the device files in /dev/evms correctly reflect the device numbers +assigned by Device Mapper. + + + \ No newline at end of file diff --git a/LDP/guide/docbook/EVMSUG/appx-jfs.xml b/LDP/guide/docbook/EVMSUG/appx-jfs.xml new file mode 100644 index 00000000..e81c546c --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/appx-jfs.xml @@ -0,0 +1,146 @@ + +JFS file system interface module + + +The JFS FSIM lets EVMS users create and manage JFS file systems from +within the EVMS interfaces. In order to use the JFS FSIM, version 1.0.9 or +later of the JFS utilities must be installed on your system. The latest +version of JFS can be found at +http://oss.software.ibm.com/jfs/. + + +Creating JFS file systems + +JFS file systems can be created with mkfs on any EVMS +or compatibility volume (at least 16 MB in size) that does not already +have a file system. The following options are available for creating +JFS file systems: + + + +badblocks + +Perform a read-only check for bad blocks on the volume +before creating the file system. The default is false. + + + +caseinsensitive + +Mark the file system as case-insensitive (for OS/2 compatibility). +The default is false. + + + +vollabel + +Specify a volume label for the file system. The default is none. + + + + +journalvol + +Specify the volume to use for an external journal. This option +is only available with version 1.0.20 or later of the JFS utilities. +The default is none. + + + + +logsize + + +Specify the inline log size (in MB). This option is only available if +the journalvol option is not set. The default is 0.4% of the size of +the volume up to 32 MB. + + + + + + + + +Checking JFS file systems + +The following options are available for checking JFS file systems with +fsck: + + + + +force + +Force a complete file system check, even if the file system is +already marked clean. The default is false. + + + +readonly + +Check the file system is in read-only mode. Report but do not +fix errors. If the file system is mounted, this option is +automatically selected. The default is false. + + + + +omitlog + +Omit replaying the transaction log. This option should only +be specified if the log is corrupt. The default is false. + + + +verbose + +Display details and debugging information during the check. +The default is false. + + + +version + +Display the version of fsck.jfs and exit without +checking the file system. The default is false. + + + + + + + +Removing JFS file systems + + +A JFS file system can be removed from its volume if the file system is +unmounted. This operation involves erasing the superblock from the volume +so the file system will not be recognized in the future. There are no +options available for removing file systems. + + + + +Expanding JFS file systems + + +A JFS file system is automatically expanded when its volume is expanded. +However, JFS only allows the volume to be expanded if it is mounted, +because JFS performs all of its expansions online. In addition, JFS only +allows expansions if version 1.0.21 or later of the JFS utilities are +installed. + + + + +Shrinking JFS file systems + + +At this time, JFS does not support shrinking its file systems. +Hence, volumes with JFS file systems cannot be shrunk. + + + + + diff --git a/LDP/guide/docbook/EVMSUG/appx-lvm.xml b/LDP/guide/docbook/EVMSUG/appx-lvm.xml new file mode 100644 index 00000000..58dc8bd3 --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/appx-lvm.xml @@ -0,0 +1,199 @@ + + + +The LVM plug-in + +The LVM plug-in combines storage objects into groups called containers. +From these containers, new storage objects can be created, with a variety of +mappings to the consumed objects. Containers allow the storage capacity of +several objects to be combined, allow additional storage to be added in the future, +and allow for easy resizing of the produced objects. +How LVM is implemented +The Linux LVM plug-in is compatible with volumes and volume groups from +the original Linux LVM tools from Sistina Software. The original LVM is based on the +concept of volume groups. A volume group (VG) is a grouping of physical volumes +(PVs), which are usually disks or disk partitions. The volume group is not directly +usable as storage space; instead, it represents a pool of available storage. +You create logical volumes (LVs) to use this storage. The storage space of the LV can +map to one or more of the group's PVs. +The Linux LVM concepts are represented by similar concepts in the EVMS LVM plug-in. +A volume group is called a container, and the logical volumes that are produced are +called regions. The physical volumes can be disks, segments, or other regions. +Just as in the original LVM, regions can map to the consumed objects in a variety of ways. + + +Container operations + +Creating LVM containers + +Containers are created with an initial set of objects. In the LVM plug-in, the +objects can be disks, segments, or regions. LVM has two options for creating containers. +The value of these options cannot be changed after the container has been created. The +options are: + +name +The name of the new container. + + +pe_size +The physical extent (PE) size, which is the granularity with which regions can be created. The default is 16 MB. Each region must have a whole number of extents. +Also, each region can have only up to 65534 extents. Thus, the PE size for the container +limits the maximum size of a region in that container. With the default PE size, an LVM +region can be, at most 1 TB. In addition, each object consumed by the container must +be big enough to hold at least five extents. Thus, the PE size cannot be arbitrarily large. Choose wisely. + + + + + +Adding objects to LVM containers +You can add objects to existing LVM containers in order to increase the pool of +storage that is available for creating regions. A single container can consume up to 256 +objects. Because the name and PE size of the containers are set when the container is +created, no options are available when you add new objects to a container. Each object +must be large enough to hold five physical extents. If an object is not large enough to +satisfy this requirement, the LVM plug-in will not allow the object to be added to the container. + + + + +Removing objects from LVM containers +You can remove a consumed object from its container as long as no regions +are mapped to that object. The LVM plug-in does not allow objects that are in use to +be removed their their container. If an object must be removed, you can delete or +shrink regions, or move extents, in order to free the object from use. +No options are available for removing objects from LVM containers. + + + +Deleting LVM containers +You can delete a container as long as the container does not have any produced +regions. The LVM plug-in does not allow containers to be deleted if they have any +regions. No options are available for deleting LVM containers. + + + +Region operations + +Creating LVM regions +You create LVM regions from the freespace in LVM containers. If there is at least +one extent of freespace in the container, you can create a new region. +The following options are available for creating LVM regions: + + +name +The name of the new region. + + +extents +The number of extents to allocate to the new region. A new region must +have at least one extent and no more than the total available free extents in the container, +or 65534 (whichever is smaller). If you use the extents option, the appropriate value +for the size option is automatically calculated. By default, a new region uses all +available extents in the container. + + + +size +The size of the new region. This size must be a multiple of the +container's PE size. If you use the size option, the appropriate value for the +extents options is automatically calculated. By default, a new region uses all +available freespace in the container. + + +stripes +If the container consumes two or more objects, and each object has +unallocated extents, then the new region can be striped across multiple objects. +This is similar to RAID-0 striping and achieves an increased amount of I/O +throughput across multiple objects. This option specifies how many objects the +new region should be striped across. By default, new regions are not striped, and +this value is set to 1. + + + +stripe_size +The granularity of striping. The default value is 16 KB. Use this option +only if the stripes option is greater than 1. + + + +contiguous +This option specifies that the new region must be allocated on a single +object, and that the extents on that object must be physically contiguous. By default, +this is set to false, which allows regions to span objects. This option cannot be used +if the stripes option is greater than 1. + + + +pv_names +A list of names of the objects the new region should map to. By default, +this list is empty, which means all available objects will be used to allocate space +to the new region. + + + + + + +Expanding LVM regions +You can expand an existing LVM region if there are unused extents in the +container. If a region is striped, you can expand it only by using free space on +the objects it is striped across. If a region was created with the contiguous option, +you can only expand it if there is physically contiguous space following the +currently allocated space. +The following options are available for expanding LVM regions: + + +add_extents +The number of extents to add to the region. If you specify this +option, the appropriate value for the add_size option is automatically +calculated. By default, the region will expand to use all free extents in the +container. + + +add_size +The amount of space to add to the region. If you specify this option, +the appropriate value for the add_extents option is automatically calculated. +By default, the region will expand to use all freespace in the container. + + +pv_names +A list of names of the objects to allocate the additional space from. +By default, this list is empty, which means all available objects will be used to +allocate new space to the region. + + + + + +Shrinking LVM regions +You can shrink an existing LVM region by removing extents from the end of the +region. Regions must have at least one extent, so regions cannot be shrunk to zero. +The following options are available when shrinking LVM regions. Because regions +are always shrunk by removing space from the end of the region, a list of objects +cannot be specified in this command. + + +remove_extents +The number of extents to remove from the region. If you specify this option, +the appropriate value for the remove_size option is automatically calculated. By +default, one extent is removed from the region. + + +remove_size +The amount of space to shrink the region by. If you specify this option, +the appropriate value for the remove_extents option is automatically calculated. + + + + + +Deleting LVM regions +You can delete an existing LVM region as long as it is not currently a +compatibility volume, an EVMS volume, or consumed by another EVMS plug-in. +No options are available for deleting LVM regions. + + + + + \ No newline at end of file diff --git a/LDP/guide/docbook/EVMSUG/appx-md.xml b/LDP/guide/docbook/EVMSUG/appx-md.xml new file mode 100644 index 00000000..841921e8 --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/appx-md.xml @@ -0,0 +1,430 @@ + +The MD region manager + + +Multiple disks (MD) support in Linux is a software implementation of RAID +(Redundant Array of Independent Disks). The basic idea of software RAID +is to combine multiple inexpensive hard disks into an array of disks to +obtain performance, capacity, and reliability that exceeds that of a single +large disk. + + + +Linux software RAID works on most block devices. A Linux RAID device +can be composed of a mixture of IDE or SCSI devices. Furthermore, +because a Linux RAID device is itself a block device, it can be a +member of another Linux RAID device. + + + +Whereas there are six standard types of RAID arrays (RAID-0 through RAID-5) in the hardware implementation, the Linux implementation of software +RAID has RAID-0, RAID-1, RAID-4, and RAID-5 levels. In addition to these +four levels, Linux also has support for another non-redundant array called +"Linear Mode." + + + +All levels of Linux software RAID are discussed in greater detail in the +Software RAID HOWTO of The Linux Documentation Project +(TLDP). +One important thing to remember is RAID is not a substitute for backups. + + +Creating an MD region +There are four EVMS MD region plug-ins: Linear, RAID-0, RAID-1, +and RAID-4/5. The RAID-4/5 region plug-in provides support for both +RAID-4 and RAID-5 arrays. After an MD region manager is selected, the software +provides a +list of acceptable objects. The ordering of the MD array is +implied by the order in which you pick objects from the provided list. The +following are MD region configuration options: + + +chunk size +The smallest chunk size is 4 KB and the largest is 4096 KB. The +chunk size is a power of 2 of the previous value. Consider the intended use of the +MD region when selecting chunk size. For example, +if the MD region contains mostly large files, you might see better performance +by having a larger chunk size. The block size of the file system being used is +also an importnat factor when selecting chunk size. +This option is available for use with RAID-0 and RAID-4/5. + + +spare disk +The benefit of having a spare disk is that when an active disk fails, +the kernel MD code automatically replaces the failed disk with the spare disk. +Otherwise, the MD array operates in a degraded mode. +This option is available for use with RAID-1 and RAID-4/5. + + +RAID-5 algorithms +There are four RAID-5 parity algorithms: left assymetric, right +assymetric, left symmetric, and right symmetric. The ACCS web +page provides examples of what the different parity algorithms do. +This option is available for use with the RAID-5 algorithm. + + + + + + +Adding and removing a spare object (RAID-1 and RAID-4/5) + +When adding a spare disk to an existing MD region, select an available object +that has the same size as the disks that are currently active in the MD region. +If the MD region consists of objects with different sizes, use the smallest size. +Note that after adding a spare to a degraded MD region, the kernel MD code +automatically starts the reconstruction of the MD array. When reconstruction finishes, +the spare disks becomes an active disk. +If you want to reorganize disks and segments, you can remove an existing +spare disk from the MD region. This is a safe operation because the spare disk does +not contain any data. + + +Removing an active object (RAID-1 only) + +Only the MD RAID-1 region plug-in lets you remove an active disk of the +MD region. This option is available for those MD RAID-1 regions that have at least +two active members. + + + + + +Removing a faulty object (RAID-1 and RAID-4/5) +When an I/O error occurs on a disk, the disk is marked faulty by the kernel +MD code. Use this function to permanently remove the faulty disk from the MD region. + + + + + +Marking an object faulty (RAID-4/5 only) + +This option is available when the RAID-4/5 array has at least one spare disk. +Use this option to swap an active disk with a spare disk. The active disk is marked +faulty and can be later removed, as described in . + + + + +Replacing an object + +In EVMS 2.0 and later, you can replace a member of an MD region with an +available storage object. The new object must be the same size as the replaced object. +This option is currently only supported for volumes that are offline. + + + +Characteristics of Linux RAID levels + +The following subsections describe the characteristics of each Linux RAID level. + +Linear mode +Characteristics: + + + +Two or more disks are combined into one virtual MD device. + + + +The disks are appended to each other, so writing linearly to the MD device +fills up disk 0 first, then 1, and so on. + + + +The disks do not have to be of the same size. + + +Advantages: + + + +Can be used to build a very large MD device. + + + + +No parity calculation overhead is involved. + + + +Disadvantages: + + + +Not a "true" RAID because it is not fault-tolerant. + + + + +One disk crash will probably result in loss of most or all data. + + + + +Should never be used in mission-critical environments. + + + + +RAID-0 + +Characteristics: + + + +Two or more disks are combined into one virtual MD device. + + + +Also called "stripe" mode. + + + +Stripe size determines how data is written to disk. For example, +writing 16 K bytes to a RAID-0 array of three disks with stripe size +of 4 K bytes is broken down into: + + + +4 K bytes of disk 0 + + + + +4 K bytes to disk 1 + + + + +4 K bytes to disk 2 + + + + +4 K bytes to disk 0 + + + + + + +The disks should be the same size but they do not have to be the same size. + + + + +Advantages: + + + +Can be used to build a very large MD device. + + + + +I/O performance is greatly improved by spreading I/O load across many +controllers and disks. + + + + +No parity calculation overhead is involved. + + + + +Disadvantages: + + + +Not a "true" RAID because it is not fault-tolerant. + + + + +One disk crash is liable to result in the loss of the whole array. + + + + +Should never be used in mission-critical environments. + + + + + +RAID-1 +Characteristics: + + + + +Consists of two or more disks to provide a two-way or N-way mirrored MD device. + + + + +Writes result in writing identical data to all active disks in the array. + + + + +Reads can be performed on any active disk of the array. + + + + +Data is intact as long as there is at least one "good" active disk in the array. + + + + +The disks should be the same size. If they are different sizes, the size +of the RAID-1 array is determined by the smallest disk. + + + + +Advantages: + + + +100% redundancy of data. + + + + +Under certain circumstances, a RAID-1 array can sustain multiple simultaneous +disk failures. + + + + +Kernel MD code provides good read-balancing algorithm. + + + + +No parity calculation overhead is involved. + + + + +Disadvantages: + + + +Write performance is often worse than on a single device. + + + + + +RAID-4 +Characteristics: + + + +Consists of three or more striped disks. + + + + +Parity information is kept on one disk. When a disk fails, parity information +is used to reconstruct all data. + + + + +The disks should be the same size. If they are different sizes, the size of +the RAID-4 array is determined by the smallest disk. + + + + +Advantages: + + + +Like RAID-0, I/O performance is greatly improved by spreading the I/O load +across many controllers and disks. + + + + +Disadvantages: + + + +The parity disk becomes a bottleneck. Therefore, a slow parity disk degrades +I/O performance of the whole array. + + + + +Cannot sustain a two-disk simultaneous failure. + + + + + +RAID-5 + +Characteristics: + + + +Consists of three or more striped disks. + + + + +Parity information is distributed evenly among the participating disks. + + + + +The disks should be the same size. If they are different sizes, the size of +the RAID-5 array is determined by the smallest disk. + + + + +Advantages: + + + +Like RAID-0, I/O performance is greatly improved by spreading the I/O load +across many controllers and disks. + + + + +Read performance is similar to RAID-0. + + + + +Disadvantages: + + + +Writes can be expensive when required read-in blocks for parity calculations +are not in the cache. + + + + +Cannot sustain a two-disk simultaneous failure. + + + + + + + + + diff --git a/LDP/guide/docbook/EVMSUG/appx-reiserfs.xml b/LDP/guide/docbook/EVMSUG/appx-reiserfs.xml new file mode 100644 index 00000000..7671a8db --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/appx-reiserfs.xml @@ -0,0 +1,85 @@ + + +ReiserFS file system interface module + + +The ReiserFS FSIM lets EVMS users create and manage ReiserFS file systems from +within the EVMS interfaces. In order to use the +ReiserFS FSIM, version 3.x.0 or +later of the ReiserFS utilities must be installed on your system. +In order to get full functionality from the ReiserFS FSIM, use version +3.x.1b or later. The latest +version of ReiserFS can be found at +http://www.namesys.com/. + + +Creating ReiserFS file systems + +ReiserFS file systems can be created with mkfs on any EVMS +or compatibility volume that does not already +have a file system. The following option is available for creating +ReiserFS file systems: + + + +vollabel + +Specify a volume label for the file system. The default is none. + + + + + + + + +Checking ReiserFS file systems + +The following option is available for checking XFS file systems with +fsck: + + + + +mode + +There are three possible modes for checking a ReiserFS file system: +Check Read-Only, Fix, and Rebuild Tree." + + + + + + + +Removing ReiserFS file systems + + +A ReiserFS file system can be removed from its volume if the file system is +unmounted. This operation involves erasing the superblock from the volume +so the file system will not be recognized in the future. There are no +options available for removing file systems. + + + + +Expanding ReiserFS file systems + + +A ReiserFS file system is automatically expanded when its volume is expanded. +ReiserFS file systems can be expanded if the volume is mounted or +unmounted. + + + + +Shrinking ReiserFS file systems + + +A ReiserFS file system is automatically shrunk if the volume is shrunk. +ReiserFS file systems can only be shrunk if the volume is unmounted. + + + + + \ No newline at end of file diff --git a/LDP/guide/docbook/EVMSUG/appx-snap.xml b/LDP/guide/docbook/EVMSUG/appx-snap.xml new file mode 100644 index 00000000..6b6f677c --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/appx-snap.xml @@ -0,0 +1,139 @@ + + + +The snapshot plug-in + +A snapshot represents a frozen image of a volume. The source of a snapshot is +called an "original." When a snapshot is created, it looks exactly like the original +at that point in time. As changes are made to the original, the snapshot remains the +same and looks exactly like the original at the time the snapshot was created. +The snapshot feature is very useful for performing data backups. In order to perform a consistent backup, the volume that is being backed up should not change while the +backup is running. This often means the volume must be taken offline during the +backup, which can be a significant inconvenience to users. With snapshots, the +volume can be kept online. A snapshot of the volume is created and the backup is taken +from the snapshot, while the original remains in active use. +How snapshotting is implemented + A snapshot represents a copy of its original volume "frozen" at some +point in time. Instead of actually copying all the data from the original to the snapshot, +a portion of data is copied only when that portion is being modified on the original. +This data portion is called a "chunk." +When data is written to a chunk on the original volume, the snapshot intercepts +the I/O request and determines if that chunk has already been saved. +If the chunk has not been saved, the chunk is copied from the original to the +snapshot, and then the write request is allowed to proceed ot the original volume. +If additional data is written to that same chunk on the original, the chunk does not +need to be copied again. +When data is read from the snapshot, it is the same as when data is read from the original. +When a chunk of data is read from the snapshot, the snapshot determines if that +chunk has been saved. If it has, the data is retrieved from the snapshot. +If the chunk has not been saved, the data is retrieved from the original. + + +Creating and activating snapshot objects + +Creating and activating a snapshot is a two-step process. The first step is to +create the snapshot object. The snapshot object specifies where the saved data will +be stored when changes are made to the original. The second step is to activate the +object, which is to make an EVMS volume from the object. + +Creating a snapshot +You can create a snapshot object from any unused storage object in EVMS +(disks, segments, regions, or feature objects). The size of this consumed object is +the size available to the snapshot object. The snapshot object can be smaller +or larger than the original volume. If the object is smaller, the original volume could fill up +as data is copied from the oriignal to the snapshot, given sufficient activity on the original. +In this situation, the snapshot is deactivated and additional I/O to the snapshot fails. + +Base the size of the snapshot object on the amount of activity that is likely to take place +on the original during the lifetime of the snapshot. The more changes that occur on the +original and the longer the snapshot is expected to remain active, the larger the snapshot +should be. Clearly, determining this calculation is not simple and requires trial and error to determine the correct snapshot object size to use for a particular situation. The goal is +to create a snapshot object large enough to prevent the shapshot from being +deactivated if it fills up, yet small enough to not waste disk space. If the snapshot +object is the same size as the original volume (actually, a little larger, to account for +the snapshot mapping tables), the snapshot is never deactivated. + tells how to create snapshots. The following options are available for +creating snapshot objects through the CLI: + + +original +The name of the volume to take a snapshot of. +Only volumes (EVMS or compatibility) can be snapshotted. +Other storage objects cannot be snapshotted. + + + + +snapshot +The name to assign to the new snapshot object. + + + + +chunksize +The granularity of the data that is copied from the +original to the snapshot. The default chunksize is 64 KB. + + + + + + + + +Activating a snapshot +After you create a snapshot, activate it by making an EVMS volume from the object. +After you create the volume and save the changes, the snapshot is active. The only +option for activating snapshots is the name to give the EVMS volume. This name can be +the same as or different than the name of the snapshot object. + + + + + +Other snapshot activities +In addition to creating and activating snapshots, you can also reinitialize them, +delete them, and roll them back. The following sections describe these tasks. + +Reinitializing a snapshot +Snapshots can be reinitialized, which causes all of the saved data to be erased and +starts the snapshot from the current point in time. A reinitialized snapshot has the same +original, chunk size, and writeable flags as the original snapshot. +To reinitialize a snapshot, delete the EVMS volume from the snapshot without +deleting the snapshot object. Then create a new EVMS volume from the snapshot object. + + + +Deleting a snapshot +When a snapshot is no longer needed, you can remove it by deleting the EVMS +volume from the snapshot object, and then deleting the snapshot object. Because the +snapshot saved the initial state of the original volume (and not the changed state), +the original is always up-to-date and does not need any modifications when a snapshot +is deleted. +No options are available for deleting snapshots. + + +Rolling back a snapshot +Situations can arise where a user wants to restore the original volume to +the saved state of the snapshot. This action is called a rollback. One such scenario +is if the data on the original is lost or corrupted. Snapshot rollback acts as a quick +backup and restore mechanism, and allows the user to avoid a more lengthy restore +operation from tapes or other archives. +Another situation where rollback can be particularly useful is when you are +testing new software. Before you install a new software package, create a writeable +snapshot of the target volume. You can then install the software to the snapshot +volume, instead of to the original, and then test and verify the new software on the +snapshot. If the testing is successful, you can then roll back the snapshot to the +original and effectively install the software on the regular system. If there is a problem +during the testing, you can simply delete the snapshot without harming the original +volume. +Rollback can only be performed when both the snapshot and the original volumes +are unmounted and otherwise not in use. Rollback can also be performed only when +there is only a single snapshot of an original. If an original has multiple snapshots, +all but the desired snapshot must be deleted before rollback can take place. +No options are available for rolling back snapshots. + + + + + \ No newline at end of file diff --git a/LDP/guide/docbook/EVMSUG/appx-xfs.xml b/LDP/guide/docbook/EVMSUG/appx-xfs.xml new file mode 100644 index 00000000..d0d44964 --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/appx-xfs.xml @@ -0,0 +1,107 @@ + +XFS file system interface module + + +The XFS FSIM lets EVMS users create and manage XFS file systems from +within the EVMS interfaces. In order to use the XFS FSIM, version 2.0.0 or +later of the XFS utilities must be installed on your system. The latest +version of XFS can be found at +http://oss.sgi.com/projects/xfs/. + + +Creating XFS file systems + +XFS file systems can be created with mkfs on any EVMS +or compatibility volume that does not already +have a file system. The following options are available for creating +XFS file systems: + + + +vollabel + +Specify a volume label for the file system. The default is none. + + + + +journalvol + +Specify the volume to use for an external journal. +The default is none. + + + + +logsize + + +Specify the inline log size (in MB). This option is only available if +the journalvol option is not set. The default is 4 MB; the +allowed range is 2 to 256 MB. + + + + + + + + +Checking XFS file systems + +The following options are available for checking XFS file systems with +fsck: + + + + +readonly + +Check the file system is in read-only mode. Report but do not +fix errors. The default is false. + + + + +verbose + +Display details and debugging information during the check. +The default is false. + + + + + + + +Removing XFS file systems + + +An XFS file system can be removed from its volume if the file system is +unmounted. This operation involves erasing the superblock from the volume +so the file system will not be recognized in the future. There are no +options available for removing file systems. + + + + +Expanding XFS file systems + + +An XFS file system is automatically expanded when its volume is expanded. +However, XFS only allows the volume to be expanded if it is mounted, +because XFS performs all of its expansions online. + + + + +Shrinking XFS file systems + + +At this time, XFS does not support shrinking its file systems. +Hence, volumes with XFS file systems cannot be shrunk. + + + + + diff --git a/LDP/guide/docbook/EVMSUG/clusterops-ug.xml b/LDP/guide/docbook/EVMSUG/clusterops-ug.xml new file mode 100644 index 00000000..ae90af56 --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/clusterops-ug.xml @@ -0,0 +1,787 @@ + + + + + + + + + +Clustering operations +This chapter discusses how to configure cluster storage containers (referred to throughout +this chapter as "cluster containers"), a feature provided by the EVMS Cluster Segment +Manager (CSM). +Disks that are physically accessible from all of the nodes of the cluster can be +grouped together as a single manageable entity. EVMS storage objects can then be +created using storage from these containers. +Ownership is assigned to a container to make the container either private or shared. +A container that is owned by any one node of the cluster is called a private container. +EVMS storage objects and storage volumes created using space from a private +container are accessible from only the owning node. +A container that is owned by all the nodes in a cluster is called a shared container. +EVMS storage objects and storage volumes created using space from a shared +container are accessible from all nodes of the cluster simultaneously. +EVMS provides the tools to convert a private container to a shared container, and +a shared container to a private container. EVMS also provides the flexibility to +change the ownership of a private container from one cluster node to another +cluster node. +Rules and restrictions for creating cluster containers +Note the following rules and limitations for creating cluster containers: + +Do not assign non-shared disks to a cluster container. + +Storage objects created on a cluster container must not span across +multiple cluster containers. Currently, the EVMS Engine cannot enforce this rule, so +you must ensure that objects and volumes created from cluster storage manager +segments do not span multiple containers. + +A disk should not span cluster containers. + +Do not assign RAID, snapshot, and BBR features to storage +objects on a cluster container. + + + + +Example: create a private cluster container +This section tells how to create a sample private +container and provides instructions for completing the following task: + +
Create a private cluster container +Given a system with three available shared disks +(sdd, sde, and +sdf), +use the EVMS Cluster Segment Manager to combine these disk drives into a +container called Priv1 owned by node1. + + +
+ +Using the EVMS GUI +To create a container with the EVMS GUI, follow these steps: + + + +Select +ActionsCreate +Container + to see a list of plug-ins that support container creation. + + + +Select the Cluster Segment Manager. + + +Click Next. +The next dialog window contains a list of storage objects that +the CSM can use to create a container. + + +Select sdd, sde, and sdf from the list. + +Click Next. + +In the first pull-down menu, select the "Node Id" of the cluster node that +owns this container (node1). Select "Storage Type" as +private from the second pull-down menu. + +Enter the name Priv1 for the Container Name. + +Click Create. +A window opens that displays the outcome. + +Commit the changes. + + + + + +Using Ncurses +To create the private container with the Ncurses interface, follow these steps: + + +Select Actions +CreateContainer to see a list +of plug-ins that support container creation. + + +Scroll down with the down arrow and select Cluster Segment Manager by +pressing spacebar. The plug-in you selected is marked with an "x." + +Press Enter. +The next submenu contains a list of disks that the Cluster Segment Manager finds +acceptable to use for the creation of a container. + +Use spacebar to select sdd, sde, +and sdf from the list. The disks you select are marked with an "x." + +Press Enter. + +On the Create Storage Container - Configuration Options menu, press +spacebar on the Node Id, which will provide a list of nodes from +which to select. + +Press spacebar on the node node1 and +then press Enter. + +Scroll down with the down arrow and press spacebar on the +Storage Type. A list of storage types opens. + +Scroll down with the down arrow to +private entry and press spacebar. + +Press Enter. + +Scroll down with the down arrow to +Container Name and press spacebar. +The Change Option Value menu opens and asks for the Container Name. Type +in the name of the container as Priv1, and press Enter. + +Press Enter to complete the operation. + + + + + +Using the CLI +An operation to create a private cluster container with the CLI takes three parameters: the name +of the container, the type of the container, and the nodeid to which the container belongs. + +On the CLI, type the following command to create the private container +Priv1: +create: container,CSM={name="Priv1",type="private",nodeid="node1"},sdd,sde,sdf + + + + +Example: create a shared cluster container +This section tells how to create a sample shared container and provides +instructions to help you complete the following task: + +
Create a shared cluster container +Given a system with three available shared disks +(sdd, sde, and +sdf), +use the EVMS Cluster Segment Manager to combine these disk drives into a shared +container called Shar1. + + +
+Using the EVMS GUI +To create a shared cluster container with the EVMS GUI, follow these steps: + + + +Select +ActionsCreate +Container + to see a list of plug-ins that support container creation. + + + +Select the Cluster Segment Manager. + + +Click Next. +The next dialog window contains a list of storage objects that +the CSM can use to create a container. + + +Select sdd, sde, and sdf from the list. + +Click Next. + + +You do not need to change the "Node Id" field. Select +Storage Type as +shared from the second pull-down menu. + + +Enter the name Shar1 for the Container Name. + +Click Create. A window opens to display the outcome. + +Commit the changes. + +Quit the GUI and run evms_activate on each of the cluster +nodes so that the nodes discover the volume. +This process will be automated in future releases of EVMS. + + + + +Using Ncurses +To create a shared cluster contained with the Ncurses interface, follow these steps: + +Select Actions +Create +Container + to see a list of plug-ins that support container creation. + + +Scroll down with the down arrow and select Cluster Segment Manager by +pressing spacebar. The plug-in you selected is marked with an "x." + +Press Enter. +The next submenu contains a list of disks that the Cluster Segment Manager finds +acceptable to use for the creation of a container. + +Use spacebar to select sdd, sde, +and sdf from the list. The disks you select are marked with an "x." + +Press Enter. + +The Create Storage Container - Configuration Options menu open; +ignore the "Node Id" menu. + + +Scroll down with the down arrow and press spacebar on the +Storage Type. A list of storage types opens. + +Scroll down with the down arrow to +shared entry and press spacebar. + +Press Enter. + +Scroll down with the down arrow to +Container Name and press spacebar. +The Change Option Value menu opens and asks for the Container Name. Type +in the name of the container as Shar1, and press Enter. + +Press Enter to complete the operation. + +Quit Ncurses and run evms_activate on each of the cluster +nodes. This process will be automated in future releases of EVMS. + + + + + + +Using the CLI +An operation to create a shared cluster container with the CLI takes two parameters: +the name of the container and the type of the container. +On the CLI, type the following command to create shared container Shar1: +create: container,CSM={name="Shar1",type="shared"},sdd,sde,sdf + +Run evms_activate on each node of the cluster. This process will be automated in future releases of EVMS. + + + + +Example: convert a private container to a shared container + +This section tells how to convert a sample private container to a shared +container and provides instructions for completing the following task: + +
Convert a private container to shared +Given a system with a private storage container Priv1 owned +by evms1, convert +Priv1 to a shared storage container with the same name. + +
+ +CAUTION +Ensure that no application +is using the volumes on the container on any node of the cluster. + +Using the EVMS GUI +Follow these steps to convert a private cluster container to a shared cluster +container with the EVMS GUI: + +Select ActionsModifyContainer to see a list of containers. + +Select the container csm/Priv1 and press Next. +A Modify Properties dialog box opens. + +Change "Type Field" to "shared" and click Modify. +A window opens that displays the outcome. + +Commit the changes. + +Quit the GUI and run evms_activate on all the cluster nodes so that the nodes discover +all the volumes on the csm/Priv1 container. This process will be +automated in a future release of EVMS. + + + +Using Ncurses +Follow these steps to convert a private cluster container to a shared cluster +container with the Ncurses interface: + +Select ActionsModifyContainer to see a list of containers. + + +The Modify Container Properties dialog opens. Select the container +csm/Priv1 by +pressing spacebar. The container you selected is marked with an "x." +Press Enter. + + +Use spacebar to select sdd, sde, +and sdf from the list. The disks you select are marked with an "x." + +Press Enter. + +The Modify Container Properties - Configuration Options" dialog opens. Scroll down with the down arrow and press spacebar on the "Type field". + + +Press spacebar. + +The Change Option Value dialog opens. Type shared and press Enter. +The changed value is now displays in the Modify Container Properties - +Configuration Options dialog. + + +Press Enter. +The outcome of the command is displayed at the bottom of the screen. + +Save the changes by clicking Save in the Actions pulldown menu. + +Quit Ncurses and run evms_activate on all the cluster nodes so that the nodes discover +all the volumes on the csm/Priv1 container. This process will be +automated in a future release of EVMS. + + + + + +Using the CLI +The modify command modifies the properties of a container. The first argument +of the command is the object to modify, followed by its new properties. The command +to convert the private container to a shared container in the example is: +modify: csm/Priv1,type=shared +Run evms_activate on all the cluster nodes so that the nodes discover +all the volumes on the csm/Priv1 container. This process will be +automated in a future release of EVMS. + + + + + +Example: convert a shared container to a private container +This section tells how to convert a sample shared container to a private +container and provides instructions for completing the following task: + +
Convert a shared container to private +Given a system with a shared storage container Shar1, convert +Shar1 to a private storage container owned by node node1 (where +node1 is the nodeid of one of the cluster nodes). + +
+ +CAUTION +Ensure that no application +is using the volumes on the container of any node in the cluster. + +Using the EVMS GUI +Follow these steps to convert a shared cluster container to a private cluster +container with the EVMS GUI: + +Select ActionsModifyContainer to see a list of containers. + +Select the container csm/Shar1 and press Next. +A Modify Properties dialog opens. + +Change "Type Field" to "private" and the "NodeID" field to node1. Click Modify. +A window opens that displays the outcome. + +Commit the changes. + +Quit the GUI and run evms_activate on the other nodes to deactivate +the volumes of the shared container on the other nodes. This process will be +automated in a future release of EVMS. + + + +Using Ncurses +Follow these steps to convert a shared cluster container to a private cluster +container with the Ncurses interface: + +Select Actions +Modify +Container + + + +The Modify Container Properties dialog opens. Select the container +csm/Shar1 by +pressing spacebar. The container you selected is marked with an "x." +Press Enter. + + + +The Modify Container Properties - Configuration Options" dialog opens. Scroll down with the down arrow and press spacebar on the "Type" field. + + +Press spacebar. + +The Change Option Value dialog opens. Type private and press Enter. + + +The Modify Container Properties - +Configuration Options dialog opens. Scroll down the list to NodeId +with the down arrow +and press spacebar. + +The Change Option Value dialog opens. Enter node1 and press Enter. + +The changed values now display in the Modify Container Properties - +Configuration Options dialog. Press Enter. +The outcome of the command is displayed at the bottom of the screen. + + +Save the changes by clickting Save in the Actions pulldown. +Quit Ncurses and run evms_activate on all the cluster nodes to deactivate the volumes of the shared container on all the other nodes. This process will be +automated in a future release of EVMS. + + + + + +Using the CLI +The modify command modifies the properties of a container. The first argument +of the command is the object to modify, followed by its new properties. The command +to convert the shared container to a private container in the example is: +modify: csm/Shar1,type=private,nodeid=node1 +Run evms_activate on all the cluster nodes to deactivate the volumes +of the shared container on all the other nodes. This process will be +automated in a future release of EVMS. + + + + +Example: deport a private or shared container + +When a container is deported, the node disowns the container and deletes +all the objects created in memory that belong to that container. +No node in +the cluster can discover objects residing on a deported container or +create objects for a deported container. +This section explains how to deport a private or shared container. + + +
Deport a cluster container +Given a system with a private or shared storage container named +c1, deport c1. + + +
+ +Using the EVMS GUI + +To deport a container with the EVMS GUI, follow these steps: + + + + +Select +ActionsModifyContainer. + + + +Select the container csm/c1 and press +Next. + + +A Modify Properties dialog opens. + + + +Change "Type Field" to "deported." Click Modify. + + +A window opens that displays the outcome. + + + +Commit the changes. + + + +NOTE + +If the deported container was a shared container, quit the GUI and then +run evms_activate on each cluster node. This operation +will be automated in a future release of EVMS. + + + + + +Using Ncurses + +To deport a container with Ncurses, follow these steps: + + + + +Scroll down the list with the down arrow to +Modify. Press Enter. + + +A submeny is displayed. + + + +Scroll down until Container is highlighted. Press Enter. + + +The Modify Container Properties dialog opens. + + + +Select the container csm/c1 by pressing +spacebar. The container you selected is marked with an "x." + + + + +Press Enter. + + +The Modify Container Properties - Configuration Options dialog opens. + + + +Scroll down and press spacebar on the "Type" field. + + + + +Press spacebar. + + +The Change Option Value dialog opens. + + + +Type deported and press Enter. + + +The changed value is displayed in the Modify Container Properties - +Configuration Options dialog. + + + +Press Enter. + + +The outcome of the command is displayed at the bottom of the screen. + + +Commit the changes by clicking Save in the +Actions pulldown. + + + + + +NOTE + +If the deported container was a shared container, quit Ncurses and then +run evms_activate on each cluster node. This operation +will be automated in a future release of EVMS. + + + + + +Using the CLI + +To deport a container from the CLI, execute the following command +at the CLI prompt: + + +modify: csm/c1,type="deported" + + +NOTE + +If the deported container was a shared container, +run evms_activate on each cluster node. This operation +will be automated in a future release of EVMS. + + + + + +Deleting a cluster container + +The procedure for deleting a cluster container is the same for deleting +any container. See + + + + + + + +Failover and Failback of a private container on Linux-HA + +EVMS supports the Linux-HA cluster manager in EVMS V2.0 and later; support for +the RSCT cluster +manager will be made available in a future release of EVMS. +NOTE +Ensure that evms_activate is called in one of the startup scripts +before the heartbeat startup script is called. If evms_activate is not called, failover +might not work correctly. + + +Follow these steps to set up failover and failback of a private container: + +Add an entry in /etc/ha.d/haresources for each +private container to be failed over. For example, if container1 and +container2 are to +be failed over together to the same node with node1 as the owning node, add the +following entry to /etc/ha.d/haresources: +node1 evms_failover::container1 evms_failover::container2 +node1 is the cluster node that owns this resource. The resource is failed over +to the other node when node1 dies. +Similarly, if container3 and container4 are to be failed over together to the same +node with node2 as the owning node, then add the following entry to +/etc/ha.d/haresources: +node2 evms_failover::container3 evms_failover::container4 +Refer to the following source for more details on the semantics of resource groups: +http://www.linux-ha.org/download/GettingStarted.html. + +Validate that the /etc/ha.d, /etc/ha.cf and /etc/ha.d/haresources files are the same +on all the nodes of the cluster. + +The heartbeat cluster manager must be restarted, as follows, after the +/etc/ha.d/haresources file has been changed: +/etc/init.d/heartbeat restart +NOTE + +Do not add shared containers to the list of failover resources; doing so causes +EVMS to respond unpredictably. + + + + + + +Remote configuration management +EVMS supports the administration of cluster nodes by any node in the cluster. For +example, storage on remote cluster node node1 can be administered from cluster node +node2. The following sections show how to set up remote administration +through the various EVMS user interfaces. + +Using the EVMS GUI + +To designate node2 as the node to administer from the GUI, follow these steps: + + +Select SettingsNode Administered... + +Select node2. + +Click Administer to switch to the new node. + + + +The discovery of the remote configuration is initiated and the status +bar displays the message "Now administering node node2," which indicates +that the GUI is switched over and node node. + + + + +Using Ncurses + +To designate node2 as the node to administer from Ncurses, follow these steps: + + +Go to the Settings pulldown menu. + +Scroll down with the down arrow to the "Node Administered" option and +press Enter. + +The Administer Remote Node dialog opens. Select node2 and press +spacebar. +The node you selected is marked with an "x." + +Press Enter. + +The "EVMS is examining your system. Please wait" dialog opens. After a +while you will be switched over to the node node2. + + + +Using the CLI +To designate node2 as a node administrator from the CLI, issue this command: +evms -n node2 + + + + +Forcing a cluster container to be imported + +A private container and its objects are made active on a node if: + + + + +the private container is owned by the node + + + + +the container is not deported + + + + +the node currently has quorum + + + + + +Similarly, a shared container and its objects are made active on a node if +the node currently has quorum. However, the administrator can force the +importation of private and shared containers by overriding these rules, as +follows: + + +NOTE + +Use extreme caution when performing this operation by ensuring that the +node on which the cluster container resides is the only active node in the +cluster. Otherwise, the data in volumes on shared and private containers +on the node can get corrupted. + + + + + + +Enabling the maintenance mode in the evms.conf file. +The option to modify in the evms.conf file is the following: + + +# cluster segment manager section +csm { +# admin_mode=yes # values are: yes or no + # The default is no. Set this key to + # yes when you wish to force the CSM + # to discover objects from all cluster + # containers, allowing you to perform + # configuration and maintenance. Setting + # admin_mode to yes will cause the CSM + # to ignore container ownership, which + # will allow you to configure storage + # in a maintenance mode. + + + + + +Running evms_activate on the node. + + + + + + + \ No newline at end of file diff --git a/LDP/guide/docbook/EVMSUG/containerops-ug.xml b/LDP/guide/docbook/EVMSUG/containerops-ug.xml new file mode 100644 index 00000000..f279e2a2 --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/containerops-ug.xml @@ -0,0 +1,570 @@ +Clustering operations +This chapter discusses how to configure cluster storage containers (referred to throughout +this chapter as "cluster containers"), a feature provided by the eVMS Cluster Segment +Manager (CSM). +Disks that are physically accessible from all of the nodes of the cluster can be +grouped together as a single manageable entity. EVMS storage objects can then be +created using storage from these containers. +Ownership is assigned to a container to make the container either private or shared. +A container that is owned by any one node of the cluster is called a private container. +EVMS storage objects and storage volumes created using space from a private +container are accessible from only the owning node. +A container that is owned by all the nodes in a cluster is called a shared container. +EVMS storage objects and storage volumes created using space from a shared +container are accessible from all nodes of the cluster simultaneously. +EVMS provides the tools to convert a private container to a shared container, and +a shared container to a private container. EVMS also provides the flexibility to +change the ownership of a private container from one cluster node to another +cluster node. +Rules and restrictions for creating cluster containers +Note the following rules and limitations for creating cluster containers: + +Non-shared disks should not be assigned to a cluster container. + +Storage objects created on a cluster container must not span across +multiple cluster containers. Currently, the EVMS Engine cannot enforce this rule, so +you need to ensure that objects and volumes created from cluster storage manager +segments do not span multiple containers. + +A disk should not span across cluster containers. + +RAID, snapshot, and BBR features should not be assigned to storage +objects on a cluster container. + + + + +Example: Create a private cluster container +This section tells how to create a sample private +container with EVMS and provides instructions for completing the following task + +
Create a private cluster container +Given a system with three available shared disks +(sdd, sde, and +sdf), +use the EVMS Cluster Segment Manager to combine these disk drives into a +container called Priv1 owned by node1. + + +
+ +Using the EVMS GUI +To create a container with the EVMS GUI, follow these steps: + + + +Select +ActionsCreate +Container + to see a list of plug-ins that support container creation. + + + +Select the Cluster Segment Manager. + + +Click Next. +The next dialog window contains a list of storage objects that +the CSM can use to create a container. + + +Select sdd, sde, and sdf from the list. + +Click Next. + +In the first pull-down menu, select the "Node Id" of the cluster node that +owns this container as node1. Select Storage Type as +private from the second pull-down menu. + +Enter the name Priv1 for the Container Name. + +Click Create. A window opens to display the outcome. + +Commit the changes. + + + + + +Using Ncurses +To create the private container with the Ncurses interface, follow these steps: + +Scroll down the list using the down arrow to Create. + + +Press Enter. A submenu is displayed. + +Scroll down until Container is highlighted. + +Press Enter. +A list opens of plug-ins that support container creation. + +Scroll down with the down arrow and select Cluster Segment Manager by +pressing spacebar. The plug-in you selected is marked with an "x." + +Press Enter. +The next submenu contains a list of disks that the Cluster Segment Manager finds +acceptable to use for the creation of a container. + +Use spacebar to select sdd, sde, +and sdf from the list. The disks you select are marked with an "x." + +Press Enter. + +On the Create Storage Container - Configuration Options menu, press +spacebar on the Node Id, which will provide a list of nodes to select from. + +Press spacebar on the node node1 and +press Enter. + +Scroll down with the down arrow and press spacebar on the +Storage Type. A list of storage types opens. + +Scroll down with the down arrow to +private entry and press spacebar. + +Press Enter. + +Scroll down with the down arrow to +Container Name and press spacebar. +The Change Option Value menu opens and asks for the Container Name. Type +in the name of the container as Priv1, and press Enter. + +Press Enter to complete the operation. + + + + + +Using the CLI +An operation to create a cluster container with the CLI takes three parameters: the name +of the container, the type of the container, and the nodeid to which the container belongs. +On the CLI, type the following command to create the private container Priv1: +create: container,CSM={name="Priv1",type="private",nodeid="node1"},sdd,sde,sdf + + + + +Example: Create a shared cluster container +This sections tells how to create a Sample Shared Container with EVMS and provides +instructions to help you complete the following task: + +
Create a shared cluster container +Given a system with three available shared disks +(sdd, sde, and +sdf), +use the EVMS Cluster Segment Manager to combine these disk drives into a shared +container called Shar1. + + +
+Using the EVMS GUI +To create a shared cluster container with the EVMS GUI, follow these steps: + + + +Select +ActionsCreate +Container + to see a list of plug-ins that support container creation. + + + +Select the Cluster Segment Manager. + + +Click Next. +The next dialog window contains a list of storage objects that +the CSM can use to create a container. + + +Select sdd, sde, and sdf from the list. + +Click Next. + + +You do not need to change the "Node Id" field. Select +Storage Type as +shared from the second pull-down menu. + + +Enter the name Shar1 for the Container Name. + +Click Create. A window opens to display the outcome. + +Commit the changes. + +Run evms_activate on each of the cluster nodes so that the nodes discover +the volume. This process will be automated in future releases of EVMS. + + + + +Using Ncurses +To create a shared cluster contained with the Ncurses interface, follow these steps: + +Scroll down the list using the down arrow to Create. + + +Press Enter. A submenu is displayed. + +Scroll down until Container is highlighted. + +Press Enter. +A list opens of plug-ins that support container creation. + +Scroll down with the down arrow and select Cluster Segment Manager by +pressing spacebar. The plug-in you selected is marked with an "x." + +Press Enter. +The next submenu contains a list of disks that the Cluster Segment Manager finds +acceptable to use for the creation of a container. + +Use spacebar to select sdd, sde, +and sdf from the list. The disks you select are marked with an "x." + +Press Enter. + +The Create Storage Container - Configuration Options menu open; +ignore the "Node Id" menu. + + +Scroll down with the down arrow and press spacebar on the +Storage Type. A list of storage types opens. + +Scroll down with the down arrow to +shared entry and press spacebar. + +Press Enter. + +Scroll down with the down arrow to +Container Name and press spacebar. +The Change Option Value menu opens and asks for the Container Name. Type +in the name of the container as Shar1, and press Enter. + +Press Enter to complete the operation. + + + + + + +Using the CLI +Execute the following command at the CLI prompt to create a shared container +Shar1: +create: container,CSM={name="Shar1",type="shared"},sdd,sde,sdf + + + + +Example: Convert a private container to a shared container + +This section tells how to convert a sample private container to a shared +container and provides instructions for completing the following task: +NOTE +Exercise caution while performing this operation. Ensure that no application +is using the volumes on the container on any node of the cluster. + +
Convert a private container to shared +Given a system with a private storage container Priv1 owned +by evms1, convert +Priv1 to a shared storage container with the same name. + +
+ +Using the EVMS GUI +Follow these steps to convert a private cluster container to a shared cluster +container with the EVMU GUI: + +Select ActionsModifyContainer to see a list of containers. + +Select the container csm/Priv1 and press Next. +A Modify Properties dialog box opens. + +Change "Type Field" to "shared" and click Modify. +A window opens that displays the outcome. + +Commit the changes. + +Run evms_activate on all the cluster nodes so that the nodes discover +all the volumes on the csm/Priv1 container. This process will be +automated in a future release of EVMS. + + + +Using Ncurses +Follow these steps to convert a private cluster container to a shared cluster +container with the Ncurses interface: + +Scroll down the list using the down arrow to +Modify. + + +Press Enter. A submenu is displayed. + +Scroll down until Container is highlighted. + +Press Enter. +The Modify Container Properties dialog opens. Select the container +csm/Priv1 by +pressing spacebar. The container you selected is marked with an "x." + + +Press Enter. + + +Use spacebar to select sdd, sde, +and sdf from the list. The disks you select are marked with an "x." + +Press Enter. + +The Modify Container Properties - Configuration Options" dialog opens. Scroll down with the down arrow and press spacebar on the "Type field". + + +Press spacebar. + +The Change Option Value dialog opens. Type shared and press Enter. +The changed value is now displays in the Modify Container Properties - +Configuration Options dialog. + + +Press Enter. +The outcome of the command is displayed at the bottom of the screen. + +Save the changes by clicking Save in the Actions pulldown menu. + +Run evms_activate on all the cluster nodes so that the nodes discover +all the volumes on the csm/Priv1 container. This process will be +automated in a future release of EVMS. + + + + + +Using the CLI +The modify command modifies the properties of a container. The first argument +of the command is the object to modify, followed by its new properties. The command +to convert the private container to a shared container in the example is: +modify: csm/Priv1,type=shared +Run evms_activate on all the cluster nodes so that the nodes discover +all the volumes on the csm/Priv1 container. This process will be +automated in a future release of EVMS. + + + + + +Example: Convert a shared container to a private container +This section tells how to convert a sample shared container to a private +container and provides instructions for completing the following task: +NOTE +Exercise caution while performing this operation. Ensure that no application +is using the volumes on the container on any node of the cluster. + +
Convert a shared container to private +Given a system with a shared storage container Shar1, convert +Shar1 to a private storage container owned by node node1 (where +node1 is the nodeid of one of the cluster nodes). + +
+ +Using the EVMS GUI +Follow these steps to convert a shared cluster container to a private cluster +container with the EVMU GUI: + +Select ActionsModifyContainer to see a list of containers. + +Select the container csm/Shar1 and press Next. +A Modify Properties dialog opens. + +Change "Type Field" to "private" and the "NodeID" field to node1. Click Modify. +A window opens that displays the outcome. + +Commit the changes. + +Run evms_activate on the other nodes to deactivate +the volumes of the shared container on the other nodes. This process will be +automated in a future release of EVMS. + + + +Using Ncurses +Follow these steps to convert a shared cluster container to a private cluster +container with the Ncurses interface: + +Scroll down the list using the down arrow to +Modify. + + +Press Enter. A submenu is displayed. + +Scroll down until Container is highlighted. + +Press Enter. +The Modify Container Properties dialog opens. Select the container +csm/Shar1 by +pressing spacebar. The container you selected is marked with an "x." + + +Press Enter. + + +The Modify Container Properties - Configuration Options" dialog opens. Scroll down with the down arrow and press spacebar on the "Type" field. + + +Press spacebar. + +The Change Option Value dialog opens. Type private and press Enter. + + +The Modify Container Properties - +Configuration Options dialog opens. Scroll down the list to NodeId +with the down arrow +and press spacebar. + +The Change Option Value dialog opens. Enter node1 and press Enter. + +The changed values now display in the Modify Container Properties - +Configuration Options dialog. Press Enter. +The outcome of the command is displayed at the bottom of the screen. + + +Save the changes by clickting Save in the Actions pulldown. +Run evms_activate on all the cluster nodes to deactivate the volumes of the shared container on all the other nodes. This process will be +automated in a future release of EVMS. + + + + + +Using the CLI +The modify command modifies the properties of a container. The first argument +of the command is the object to modify, followed by its new properties. The command +to convert the shared container to a private container in the example is: +modify: csm/Shar1,type=private,nodeid=node1 +Run evms_activate on all the cluster nodes to deactivate the volumes +of the shared container on all the other nodes. This process will be +automated in a future release of EVMS. + + + + +Failover and Failback of a private container on Linux-HA + +EVMS supports the Linux-HA cluster manager in EVMS V2.0 and later; support for +the RSCT cluster +manager will be made available in a future release of EVMS. +NOTE +Ensure that evms_activate is called in one of the startup scripts +before the heartbeat daemon starts (for example, /etc/kinit.d/heartbeat). If evms_activate is not called, failover +might not work correctly. + + +Follow these steps to set up failover and failback of a private container: + +Add an entry in /etc/ha.d/haresources for each +private container to be failed over. For example, if container3 and +container4 are to +be filled over together to the same node with node1 as the owning node, add the +following entry to /etc/ha.d/haresources: +node1 evms_failover::container1 evms_failover::container1 +node1 is the cluster node that owns this resource. The resource is failed over +to the other node when node1 dies. +Similarly, if container3 and container4 are to be failed over together to the same +node with node2 as the owning node, then add the following entry to +/etc/ha.d/haresources: +node2 evms_failover::container3 evms_failover::container4 +Refer to the following source for more details on the semantics of resource groups: +http://www.linux-ha.org/download/GettingStarted.html. + +Validate that the /etc/ha.d, /etc/ha.cf and /etc/ha.d/haresources files are the same +on all the nodes of the cluster. + +The heartbeat cluster manager must be restarted, as follows, after the +/etc/ha.d/haresources file has been changed: +/etc/init.d/heartbeat restart +NOTE +Do not add shared containers to the list of failover resources; doing so causes +EVMS to respond unpredictably. + + + + + +Remote configuration management +EVMS supports the administration of cluster nodes by any node in the cluster. For +example, storage on remote cluster node node1 can be administered from cluster node +node2. The following sections show how to set up remote administration +through the various EVMS user interfaces. + +Using the EVMS GUI + +To designate node2 as a node administrator, enter this command: +evmsgui -n node2 + +Using Ncurses + +To designate node2 as a node administrator from Ncurses, follow these steps: + + +Go to the Setting pulldown menu. + +Scroll down with the down arrow to the "Node Administered" option and +press Enter. + +The Administer Remote Node dialog opens. Select node2 and press +spacebar. +The node you selected is marked with an "x." + +Press Enter. + +The "EVMS is examining your system. Please wait" dialog opens. After a +while you will be switched over to the node node2. + + + +Using the CLI +To designate node2 as a node administrator from the CLI, issue this command: +evms -n node2 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/LDP/guide/docbook/EVMSUG/create-drivelinking.xml b/LDP/guide/docbook/EVMSUG/create-drivelinking.xml new file mode 100644 index 00000000..8ee70fdf --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/create-drivelinking.xml @@ -0,0 +1,307 @@ +Creating drive links + +This chapter discusses the EVMS drive linking feature, which is +implemented by the drive link plug-in, and tells how to create, expand, shrink, +and delete a drive link. + + +What is drive linking? +Drive linking linearly concatenates objects, allowing you to +create large storage objects and volumes from smaller individual pieces. +For example, say you need a 1 GB volume but do +not have contiguous space available of that length. Drive linking lets you +link two or more objects together to form the 1 GB volume. + + +The types of objects that can be drive linked include disks, segments, +regions, compatibility volumes, and other feature objects. + + + +Any resizing of an existing drive link, whether to grow it or shrink it, +must be coordinated with the appropriate file system operations. +EVMS handles these file system operations automatically. + + + +Because drive linking is an EVMS-specific feature that contains EVMS metadata, +it is not backward compatible with other volume-management schemes. + + + + +How drive linking is implemented +The drive link plug-in consumes storage objects, called link +objects, which produce a larger drive link object whose address space spans +the link objects. +The drive link plug-in knows how to assemble the link objects so as to +create the exact same address space every time. +The information required to do this is kept on each link child as persistent +drive-link metadata. +During discovery, the drive link plug-in inspects each known storage +object for this metadata. +The presence of this metadata identifies the storage object as a link object. +The information contained in the metadata is sufficient to: + + +Identify the link object itself. + + +Identify the drive link storage object that the link object belongs to. + + + +Identify all link objects belonging to the drive link storage. +object + + +Establish the order in which to combine the child link objects. + + + + +If any link objects are missing at the conclusion of the discovery +process, the drive link storage object contains gaps where the missing +link objects occur. +In such cases, the drive link plug-in attempts to fill in the gap with a +substitute link object and construct the drive link storage object in +read-only mode, which allows for recovery action. +The missing object might reside on removable storage that has been removed or +perhaps a lower layer plug-in failed to produce the missing object. +Whatever the reason, a read-only drive link storage object, together +logging errors, help you take the appropriate actions to recover the drive link. + + + +Creating a drive link + +The drive link plug-in provides a list of acceptable objects from +which it can create a drive-link object. +When you create an EVMS storage object and then choose the drive +link plug-in, a list of acceptable objects is provided that you can choose +from. +The ordering of the drive link is implied by the order in which you pick +objects from the provided list. +After you provide a name for the new drive-link object, the identified +link objects are consumed and the new drive-link object is produced. +There are no create objects. + + +Only the last object in a drive link +can be expanded, shrunk or removed. Additionally, a new object can be added to the +end of an existing drive link only if the file system (if one exists) permits. +Any resizing of a drive link, whether to grow it or shrink it, must be coordinated with the +appropriate file system operations. EVMS handles these file system operations +automatically. + + + +Example: create a drive link + This section shows how to create a drive link with EVMS: + +
Create a drive link +Create a new drive link consisting of sde4 and hdc2, and call it "dl."
+ + +Using the EVMS GUI + To create the drive link using the GUI, follow these steps: + + Select + Actions + Create + Feature Object + to see a list of EVMS features. + + + Select + Drive Linking Feature. + + + + + Click Next. + + + Click the objects you want to compose the drive link: + sde4 and hdc2. + + Click Next. + + + Type dl in the "name" field + + Click + Create. + + The last dialog window + presents the free space object you + selected as well as the available + configuration options for that + object. + + + + + +Alternatively, you can perform some of the steps to create a drive link with the GUI +context sensitive menu: + + + From the Available Objects tab, + right click sde4. + Click Create Feature Object... + Continue creating the drive link beginning with step 2 of the GUI + instructions. In step 4, sde4 is selected for you. You can also + select hdc2. + + + + + + +Using Ncurses + To create the drive link, follow these steps: +Select ActionsCreateFeature Object to see a list of EVMS features. + + + Select Drive Linking Feature. + + Activate Next. + + Use spacebar + to select the objects you want to compose the drive + link from: sde4 and hdc2. + + Activate Next. + + Press + spacebar to edit the Name field. + + Type dl at the "::" prompt. + Press Enter. + + Activate Create. + + + +Alternatively, you can perform some of the steps to create a drive link with the +context sensitive menu: + + +From the Available Objects view, press Enter on sde4. + +Activate the Create Feature Object menu item. + +Continue creating the drive link beginning with step 4 of the Ncurses +instructions. sde4 will be pre-selected. You can also select hdc2. + + + + + +Using the CLI + + + Use the + create command to create a drive link through the CLI. You pass the "object" keyword to the create command, followed by the plug-in and its options, and finally the objects. + +To determine the options for the plug-in you are going to use, issue the following command: + +query: plugins, plugin=DriveLink, list options + +Now construct the create command, as follows: + +create: object, DriveLink={Name=dl}, sde4, hdc2 + + + + + +Expanding a drive link + +A drive link is an aggregating storage object that is built by combining a number of +storage objects into a larger resulting object. A drive link consumes link objects in order +to produce a larger storage object. The ordering of the link objects as well as the +number of sectors they each contribute is described by drive link metadata. The metadata +allows the drive link plug-in to recreate the drive link, spanning the link objects in a +consistent manner. Allowing any of these link objects to expand would corrupt the +size and ordering of link objects; the ordering of link objects is vital to the correct +operation of the drive link. However, expanding a drive link can be controlled by only +allowing sectors to be added at the end of the drive link storage object. This does not +disturb the ordering of link objects in any manner and, because sectors are only added +at the end of the drive link, existing sectors have the same address (logical sector +number) as before the expansion. Therefore, a drive link can be expanded by adding +additional sectors in two different ways: + + + + +By adding an additional storage object to the end of the drive link. + + + + +By expanding the last storage object in the drive link. + + + + + +If the expansion point is the drive link storage object, you can perform the +expansion by adding an additional storage object to the drive link. This is done +by choosing from a list of acceptable objects during the expand operation. Multiple objects +can be selected and added to the drive link. + + + +If the expansion point is the last storage object in the drive link, then you expand the +drive link by interacting with the plug-in that produced the object. For example, if +the link was a segment, then the segment manager plug-in that produced the storage +object expands the link object. Afterwards, the drive link plug-in notices the size +difference and updates the drive link metadata to reflect the resize of the child object. + +There are no expand options. + + + + + +Shrinking a drive link + +Shrinking a drive link has the same restrictions as expanding a drive link. A drive link +object can only be shrunk by removing sectors from the end of the drive link. This can +be done in the following ways: + +By removing link objects from the end of the drive link. + +By shrinking the last storage object in the drive link. + + + + +The drive link plug-in attempts to orchestrate the shrinking of a +drive-link storage object by only listing the last link object. +If you select this object, the drive link plug-in then lists the next-to-last +link object, and so forth, moving backward through the link +objects to satisfy the shrink command. + +If the shrink point is the last storage object in th drive link, then you shrink the +drive link by interacting with the plug-in that produced the object. + + +There are no shrink options. + + + +Deleting a drive link + +A drive link can be deleted as long as it is not currently a +compatibility volume, an EVMS volume, or consumed by another EVMS plug-in. + + +No options are available for deleting a drive link storage object. + + + + + diff --git a/LDP/guide/docbook/EVMSUG/create-snapshot.xml b/LDP/guide/docbook/EVMSUG/create-snapshot.xml new file mode 100644 index 00000000..2128ee6e --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/create-snapshot.xml @@ -0,0 +1,250 @@ + + + + +Creating snapshots + +This chapter discusses snapshotting and tells how to create +a snapshot. + + +What is a snapshot? + +A snapshot represents a frozen image of a volume. +The source of a snapshot is +called an "original." +When a snapshot is created, it looks exactly like the original +at that point in time. +As changes are made to the original, the snapshot remains the +same and looks exactly like the original at the time the snapshot was +created. + + +The snapshot feature is very useful for performing data backups. +In order to perform a consistent backup, the volume that is being backed up +should not change while the +backup is running. +This often means the volume must be taken offline during the +backup, which can be a significant inconvenience to users. +With snapshots, the volume can be kept online. +A snapshot of the volume is created and the backup is taken +from the snapshot, while the original remains in active use. + + + +Creating and activating snapshot objects + +Creating and activating a snapshot is a two-step process. +The first step is to create the snapshot object. +The snapshot object specifies where the saved data will +be stored when changes are made to the original. +The second step is to activate the +object, which is to make an EVMS volume from the object. + +Creating a snapshot +You can create a snapshot object from any unused storage object in EVMS +(disks, segments, regions, or feature objects). +The size of this consumed object is +the size available to the snapshot object. The snapshot object can be smaller +or larger than the original volume. +If the object is smaller, the original volume could fill up +as data is copied from the original to the snapshot, given sufficient +activity on the original. +In this situation, the snapshot is deactivated and additional +I/O to the snapshot fails. + + +Base the size of the snapshot object on the amount of activity that +is likely to take place on the original during the lifetime of the snapshot. +The more changes that occur on the +original and the longer the snapshot is expected to remain active, +the larger the snapshot should be. +Clearly, determining this calculation is not simple and requires trial and +error to determine the correct snapshot object size to use for a +particular situation. +The goal is to create a snapshot object large enough to prevent the +shapshot from being +deactivated if it fills up, yet small enough to not waste disk space. +If the snapshot +object is the same size as the original volume (actually, a little larger, +to account for the snapshot mapping tables), the snapshot is +never deactivated. + + + + + +Activating a snapshot +After you create a snapshot, activate it by making an EVMS volume from the object. +After you create the volume and save the changes, the snapshot is active. The only +option for activating snapshots is the name to give the EVMS volume. This name can be +the same as or different than the name of the snapshot object. + + + +Example: create a snapshot + This section shows how to create a snapshot with EVMS: + +
Create a snapshot of a volume +Create a new snapshot of /dev/evms/vol on +lvm/Sample Container/Sample Region, and call +it "snap."
+ + +Using the EVMS GUI + To create the snapshot using the GUI, follow these steps: + + Select + + Actions + Create + Feature Object + + to see a list of EVMS feature objects. + + + Select + Snapshot Feature. + + Click Next. + + Select lvm/Sample Container/Sample Region. + + Click Next. + + Select /dev/evms/vol from the list in the + "Volume to be Snapshotted" field. + + Type snap in the "Snapshot Object Name" field. + + + Click Create. + + + +Alternatively, you can perform some of the steps to create a snapshot with the GUI +context sensitive menu: + + From the Available Objects tab, right click + lvm/Sample Container/Sample Region. + Click Create Feature Object... + Continue creating the snapshot beginning with step 2 of the + GUI instructions. You can skip steps 4 and 5 of the GUI instructions. + + + + + + +Using Ncurses + To create the snapshot, follow these steps: +Select ActionsCreate + Feature Object + to see a list of EVMS feature objects. + + + Select Snapshot Feature. + + Activate Next. + + Select lvm/Sample Container/Sample Region. + + Activate Next. + + Press + spacebar to edit the "Volume to be Snapshotted" field. + +Highlight /dev/evms/vol and press spacebar to select. + +Activate OK. + +Highlight "Snapshot Object Name" and press spacebar to edit. + + Type snap at the "::" prompt. + Press Enter. + + Activate Create. + + + + + +Alternatively, you can perform some of the steps to create a snapshot with the +context sensitive menu: + + +From the Available Objects view, press Enter on lvm/Sample Container/Sample Region. + +Activate the Create Feature Object menu item. + +Continue creating the snapshot beginning with step 6 of the Ncurses +instructions. + + + + + + +Using the CLI + + + Use the + create command to create a snapshot through the CLI. You pass the "Object" keyword to the create command, followed by the plug-in and its options, and finally the objects. + +To determine the options for the plug-in you are going to use, issue the following command: + +query: plugins, plugin=Snapshot, list options + +Now construct the create command, as follows: + +create: object, Snapshot={original=/dev/evms/vol, snapshot=snap}, +"lvm/Sample Container/Sample Region" + + + +Reinitializing a snapshot +Snapshots can be reinitialized, which causes all of the +saved data to be erased and +starts the snapshot from the current point in time. +A reinitialized snapshot has the same +original, chunk size, and writeable flags as the original +snapshot. + +To reinitialize a snapshot, delete the EVMS volume from the +snapshot without deleting the snapshot object. +Then create a new EVMS volume from the snapshot object. + + + +Deleting a snapshot +When a snapshot is no longer needed, you can remove it by deleting the EVMS +volume from the snapshot object, and then deleting the snapshot object. Because the +snapshot saved the initial state of the original volume (and not the changed state), +the original is always up-to-date and does not need any modifications when a snapshot +is deleted. +No options are available for deleting snapshots. + + +Rolling back a snapshot +Situations can arise where a user wants to restore the original volume to +the saved state of the snapshot. This action is called a rollback. One such scenario +is if the data on the original is lost or corrupted. Snapshot rollback acts as a quick +backup and restore mechanism, and allows the user to avoid a more lengthy restore +operation from tapes or other archives. +Another situation where rollback can be particularly useful is when you are +testing new software. Before you install a new software package, create a writeable +snapshot of the target volume. You can then install the software to the snapshot +volume, instead of to the original, and then test and verify the new software on the +snapshot. If the testing is successful, you can then roll back the snapshot to the +original and effectively install the software on the regular system. If there is a problem +during the testing, you can simply delete the snapshot without harming the original +volume. +Rollback can only be performed when both the snapshot and the original volumes +are unmounted and otherwise not in use. Rollback can also be performed only when +there is only a single snapshot of an original. If an original has multiple snapshots, +all but the desired snapshot must be deleted before rollback can take place. +No options are available for rolling back snapshots. + + + + \ No newline at end of file diff --git a/LDP/guide/docbook/EVMSUG/debuglog-ug.xml b/LDP/guide/docbook/EVMSUG/debuglog-ug.xml new file mode 100644 index 00000000..4912f5d8 --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/debuglog-ug.xml @@ -0,0 +1,63 @@ + +The EVMS log file and error data collection + +This chapter discusses the EVMS information and error log file and the various logging levels. It also explains how to change the logging level. + + +About the EVMS log file +The EVMS Engine creates a log file called /var/log/evmsEngine.log every time the Engine is opened. The Engine also saves copies of up to 10 previous Engine sessions in the files /var/log/evmsEngine.n.log, where n is the number of the session between 1 and 10. + + + +Log file logging levels +There are several possible logging levels that you can choose to be collected in /var/log/evmsEngine.log. The "lowest" logging level, critical, collects only messages about serious system problems, whereas the "highest" level, everything, collects all logging related messages. When you specify a particular logging level, the Engine collects messages for that level and all the levels below it. + +The following table lists the allowable log levels and the information they provide: +EVMS logging levels +Level name +Description + +CriticalThe health of the system or the Engine is in jeopardy; for example, an operation has failed because there is not enough memory. +SeriousAn operation did not succeed. +ErrorThe user has caused an error. The error messages are provided to help the user correct the problem. +WarningAn error has occurred that the system might or might not be able to work around. +DefaultAn error has occurred that the system has already worked around. +DetailsDetailed information about the system. +DebugInformation that helps the user debug a problem. +ExtraMore information that helps the user debug a problem than the "Debug" level provides. +Entry_ExitTraces the entries and exits of functions. +EverythingVerbose output. +
 + + + +Specifying the logging levels +By default, when any of the EVMS interfaces is opened, the Engine logs the Default level of messages into the /var/log/evmsEngine.log file. However, if your system is having problems and you want to see more of what is happening, you can change the logging level to be higher; if you want fewer logging messages, you can change the logging level to be lower. To change the logging level, specify the -d parameter and the log level on the interface open call. The following examples show how to open the various interfaces with the highest logging level (everything): +GUI: evmsgui -d everything +Ncurses: evmsn -d everything +CLI: evms -d everything + +NOTE +If you use the EVMS mailing list for help with a problem, providing to us +the log file that is created when you open one of the interfaces (as shown +in the previous commands) makes it easier for us to help you. + + + +The EVMS GUI lets you change the logging level during an Engine session. To do so, follow these steps: + + +Select Settings + Log Level + Engine. + + + Click the Level you want. + + + +The CLI command, probe, opens and closes the Engine, which causes a new log to start. The log that existed before the probe command was issued is renamed /var/log/evmsEngine.1.log and the new log is named /var/log/evmsEngine.log. + + + + diff --git a/LDP/guide/docbook/EVMSUG/deleterecurs-ug.xml b/LDP/guide/docbook/EVMSUG/deleterecurs-ug.xml new file mode 100644 index 00000000..dc151aba --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/deleterecurs-ug.xml @@ -0,0 +1,165 @@ + + + +Destroying EVMS objects + +This chapter tells how to destroy EVMS objects through the delete and +delete recursive operations. + + +How to delete objects: delete and delete recursive +There are two ways in EVMS that you can destroy objects that you no longer want: Delete and Delete Recursive. The Delete option destroys only the specific object you specify. The Delete Recursive option destroys the object you specify and its underlying objects, down to the container, if one exists, or else down to the disk. In order for an object to be deleted, it must not be mounted. EVMS verifies that the object you are attempting to delete is not mounted and does not perform the deletion if the object is mounted. + + + +Example: perform a delete recursive operation + The following example shows how to destroy a volume and the objects below it with the EVMS GUI, Ncurses, and CLI interfaces. + +
Destroy a volume and the region and container below it +This example uses the delete recursive operation to destroy volume /dev/evms/Sample Volume and the region and container below it. Volume /dev/evms/Sample Volume is the volume that was created in earlier. Although we could also use the delete option on each of the objects, the delete recursive option takes fewer steps. Note that because we intend to delete the container as well as the volume, the operation needs to be performed in two steps: one to delete the volume and its contents, and one to delete the container and its contents. +
+ +Using the EVMS GUI +Follow these steps to delete the volume and the container with the EVMS GUI: + + + Select Actions + Delete + Volume. + + + Select volume /dev/evms/Sample Volume + from the list. + + + Click Recursive Delete. This step deletes the volume + and the region lvm/Sample Container/Sample Region. If you want to + keep the + underlying pieces or want to delete each piece separately, you would click + Delete instead of Delete Recursive. + + + Assuming you chose Delete Recursive (if not, delete the region before + continuing with these steps), select Actions + Delete + Container. + + + Select container lvm/Sample Container from the list. + + + Click Recursive Delete to destroy the container and anything + under it. Alternatively, click Delete to destroy only the container (if you built the container on + disks as in the example, either command has the same effect). + + + + + +Alternatively, you can perform some of the volume deletion steps with the GUI context +sensitive menu: + + + From the Volumes tab, right click + /dev/evms/Sample Volume. + Click Delete... + Continue with the operation beginning with step 3 of the + GUI instructions. + + + + + +Using Ncurses + Follow these steps to delete the volume and the container with Ncurses: + + + Select Actions + DeleteVolume. + + + Select volume + /dev/evms/Sample Volume from the list. + + + Activate + Delete Volume Recursively. + This step deletes the volume and the region + lvm/Sample Container/Sample Region. If you want to keep the + underlying pieces or want to delete each piece separately, activate + Delete instead of Delete Recursive. + + + + Assuming you chose Delete Volume Recursively + (if not, delete the region before continuing with + these steps), select Actions + DeleteContainer. + + + Select container + lvm/Sample Container from the list. + + + Click + Recursive Delete to destroy the container and + everything under it. Alternatively, activate Delete to delete + only the container (if you built the container on disks as in the + example, either command has the same effect). + + Press Enter. + + + + +Alternatively, you can perform some of the volume deletion steps with the +context sensitive menu: + + +From the Volumes view, press Enter on /dev/evms/Sample Volume. + +Activate Delete. + +Continue with the operation beginning with step 3 of the Ncurses instructions. + + + + + + +Using the CLI + + + Use the + delete and delete recursive + commands to destroy EVMS objects. + Specify the command name followed by a colon, and then specify the + volume, object, or container name. For example: + + +Enter this command to perform the delete recursive +operation: +delete recursive: "/dev/evms/Sample Volume" + +This step deletes the volume and the region +/lvm/Sample Container/Sample Region. If you wanted to keep the +underlying pieces or wanted to delete each piece separately, use the delete command, as follows: + +delete: "/dev/evms/Sample Volume" + + +Assuming you chose Delete Volume Recursively (if not, delete the region before +continuing with these steps) enter the following to destroy the container and everything under it: + +delete recursive: "lvm/Sample Container" + +To destroy only the container, enter the following: + +delete: "lvm/Sample Container" + + + + + + + \ No newline at end of file diff --git a/LDP/guide/docbook/EVMSUG/displaydetails-ug.xml b/LDP/guide/docbook/EVMSUG/displaydetails-ug.xml new file mode 100644 index 00000000..ddafd794 --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/displaydetails-ug.xml @@ -0,0 +1,87 @@ + + + +Obtaining interface display details + +The EVMS interfaces let you view more detailed information about an EVMS object than +what is readily available from the main views of the EVMS user interfaces. The type and extent +of additional information available is dependent on the interface you use. For example, the +EVMS GUI provides more in-depth information than does the CLI. + +The following sections show how to find detailed information on the region +lvm/Sample Container/Sample Region, which is part of +volume /dev/evms/Sample Volume (created in section 10.2). + +Using the EVMS GUI +With the EVMS GUI, it is only possible to display additional details on an object through +the Context Sensitive Menus, as shown in the following steps: + +Looking at the volumes view, click the "+" next +to volume /dev/evms/Sample Volume. Alternatively, look at the regions view. + + +Right click lvm/Sample Container/Sample Region. + +Point at Display Details... and left click. A new window opens +with additional information about the selected region. + +Click More by the Logical Extents box. Another window opens that displays the mappings of logical extents to physical extents. + + + + + +Using Ncurses +Follow these steps to display additional details on an object with Ncurses: + + + Press + Tab to reach the Storage Regions view. + + + Scroll down using the down arrow until + lvm/Sample Container/Sample Region is highlighted. + + + Press Enter. + + + In the context menu, scroll down using the down arrow + to highlight "Display Details..." + + + Press Enter to activate the menu item. + + + In the Detailed Information dialog, use the down arrow to + highlight the "Logical Extents" item and then use spacebar to open + another window that displays the mappings of logical extents to physical extents. + + + + + +Using the CLI +Use the + query command (abbreviated q) with filters to display details about EVMS objects. There are two filters that are especially helpful for navigating +within the command line: list options (abbreviated lo) and extended info (abbreviated ei). +The list options command tells you what can currently be done and what options you +can specify. To use this command, first build a traditional query command starting with the command name query, followed by a colon (:), and then the type of object you +want to query (for example, volumes, objects, plug-ins). Then, you can use filters to narrow +the search to only the area you are interested in. For example, to determine the acceptable +actions at the current time on lvm/Sample Container/Sample Region, enter the following command: + +query: regions, region="lvm/Sample Container/Sample Region", list options + +The extended info filter is the equivalent of Display Details in the EVMS GUI and Ncurses interfaces. The command takes the following form: query, followed by a colon (:), the filter (extended info), a comma (,), and the object you want more information about. The command returns a list containing the field names, titles, descriptions and values for each field defined for the object. For example, to obtain details on lvm/Sample Container/Sample Region, enter the following command: + +query: extended info, "lvm/Sample Container/Sample Region" + +Many of the field names that are returned by the extended info filter can be expanded +further by specifying the field name or names at the end of the command, separated +by commas. For example, if you wanted additional information about logical extents, the query would look like the following: + +query: extended info, "lvm/Sample Container/Sample Region", Extents + + + \ No newline at end of file diff --git a/LDP/guide/docbook/EVMSUG/expandshrink.xml b/LDP/guide/docbook/EVMSUG/expandshrink.xml new file mode 100644 index 00000000..29604ee1 --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/expandshrink.xml @@ -0,0 +1,292 @@ + + + +Expanding and shrinking volumes + +This chapter tells how to expand and shrink EVMS volumes with the EVMS +GUI, Ncurses, and CLI interfaces. Note that you can also expand and shrink compatibility volumes and EVMS objects. + +Why expand and shrink volumes? +Expanding and shrinking volumes are common volume operations on most systems. For example, it might be necessary to shrink a particular volume to create +free space for another volume to expand into or to create a new volume. + +EVMS simplifies the process for expanding and shrinking volumes, and +protects the integrity of your data, by coordinating expand and shrink +operations with the volume's file system. For example, when shrinking a +volume, EVMS first shrinks the underlying file system appropriately to protect +the data. When expanding a volume, EVMS expands the file system automatically +when new space becomes available. + +Not all file system interface modules (FSIM) types supported by EVMS +allow shrink and expand operations, and some only perform the operations when +the file system is mounted ("online"). The following table details the +shrink and expand options available for each type of FSIM. + + FSIM support for expand and shrink operations +FSIM type +Shrinks +Expands + + +JFSNoOnline onlyXFSNoOnline onlyReiserFSOffline onlyOffline and onlineext2/3Offline onlyOffline onlySWAPFSOffline onlyOffline only
 +You can perform all of the supported shrink and expand operations with each of the EVMS user interfaces. + +Example: shrink a volume +This section tells how to shrink a compatibility volume by 500 MB. + +
Shrink a volume +Shrink the volume +/dev/evms/lvm/Sample Container/Sample Region, which +is the compatibility volume that was created in the chapter entitled +"Creating Volumes," by 500 MB. +
+ +Using the EVMS GUI +Follow these steps to shrink the volume with the EVMS GUI: + + + Select ActionsShrinkVolume... + + Select + /dev/evms/lvm/Sample Container/Sample Region + from the list of volumes. + + + Click Next. + + + Select /lvm/Sample Container/Sample Region from the list of volumes. + + + Click Next. + + + + Enter 500MB in the "Shrink by Size" field. + + Click Shrink. + + + +Alternatively, you can perform some of the steps to shrink the volume with the GUI +context sensitive menu: + +From the Volumes tab, right click + /dev/evms/lvm/Sample Container/Sample Region + Click Shrink... + Continue the operation beginning with step 3 of the GUI + instructions. + + + + + + +Using Ncurses + Follow these steps to shrink a volume with Ncurses: + + + Select ActionsShrink + Volume. + + + Select + /dev/evms/lvm/Sample Container/Sample Region from the + list of volumes. + + + Activate Next. + + +Select + lvm/Sample Container/Sample Region from the + shrink point selection list. + + +Activate Next. + + + Scroll down using the down arrow until + Shrink by Size is highlighted. + + + + Press spacebar. + + + Press Enter. + + + + At the "::" prompt enter 500MB. + + + Press Enter. + + Activate Shrink. + + + + + + +Alternatively, you can perform some of the steps to shrink the volume with the +context sensitive menu: + + +From the Volumes view, press Enter on /dev/evms/lvm/Sample Container/Sample Region. + +Activate the Shrink menu item. + +Continue the operation beginning with step 3 of the Ncurses instructions. + + + + + +Using the CLI + + + The shrink command takes a shrink point followed by an optional name +value pair or an optional shrink object. To find the shrink point, use the query command with the shrink points filter on the object or volume you plan to shrink. For example: + +query: shrink points, "/dev/evms/lvm/Sample Container/Sample Region" + +Use a list options filter on the object of the shrink point to determine the name-value pair to use, as follows: + +query: objects, object="lvm/Sample Container/Sample Region", list options +With the option information that is returned, you can construct the command, as follows: + +shrink: "lvm/Sample Container/Sample Region", remove_size=500MB + + + + + +Example: expand a volume +This section tells how to expand a volume a compatibility volume by 500 MB. +
Expand a volume +Expand the volume /dev/evms/lvm/Sample Container/Sample Region, which is the compatibility volume that was created in the chapter entitled "Creating Volumes," by 500 MB. +
+ +Using the EVMS GUI +Follow these steps to expand the volume with the EVMS GUI: + + + Select + ActionsExpand + Volume... + + + Select + /dev/evms/lvm/Sample Container/Sample Region + from the list of volumes. + + + Click Next. + + + + Select lvm/Sample Container/Sample Region from the list as the expand point. + + + Click Next. + + + Enter 500MB in the "Additional Size" field. + + Click Expand. + + +Alternatively, you can perform some of the steps to expand the volume with the GUI +context sensitive menu: + + + From the Volumes tab, right click + /dev/evms/lvm/Sample Container/Sample Region. + Click Expand... + + Continue the operation to expand the volume beginning with step 3 + of the GUI instructions. + + + + + + +Using Ncurses + Follow these steps to expand a volume with Ncurses: + + + Select ActionsExpandVolume. + + + Select + /dev/evms/lvm/Sample Container/Sample Region from the + list of volumes. + + + Activate Next. + + + + Select lvm/Sample Container/Sample Region from + the list of expand points. + + + Activate Next. + + + Press spacebar on the Additional Size field. + + + At the "::" prompt enter 500MB. + + + Press Enter. + + Activate Expand. + + + + + + +Alternatively, you can perform some of the steps to shrink the volume with the +context sensitive menu: + + +From the Volumes view, press Enter on /dev/evms/lvm/Sample Container/Sample Region. + +Activate the Expand menu item. + +Continue the operation beginning with step 3 of the Ncurses instructions. + + + + + + +Using the CLI + +The expand command takes an expand point followed by an optional name +value pair and an expandable object. To find the expand point, use the query command with the Expand Points filter on the object or volume you plan to expand. For example: + +query: expand points, "/dev/evms/lvm/Sample Container/Sample Region" + +Use a list options filter on the object of the expand point to determine the name-value pair to use, as follows: + +query: objects, object="lvm/Sample Container/Sample Region", list optionsThe free space in your container is the container name plus /Freespace. +With the option information that is returned, you can construct the command, as follows: + +expand: "lvm/Sample Container/Sample Region", add_size=500MB, +"lvm/Sample Container/Freespace" + + + + + + + + + \ No newline at end of file diff --git a/LDP/guide/docbook/EVMSUG/fsim-template.xml b/LDP/guide/docbook/EVMSUG/fsim-template.xml new file mode 100644 index 00000000..4b71ec37 --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/fsim-template.xml @@ -0,0 +1,68 @@ + + + + + + + + + +Creating JFS file systems + + + + + + + + +size + +The device they are found on. + + + + + + + +Checking JFS file systems + + + + + + +Removing JFS file systems + + + + +size + +The device they are found on. + + + + + + + + +Expanding JFS file systems + + + + + + +Shrinking JFS file systems + + + + + + + + + diff --git a/LDP/guide/docbook/EVMSUG/fsimops-ug.xml b/LDP/guide/docbook/EVMSUG/fsimops-ug.xml new file mode 100644 index 00000000..3cb51db5 --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/fsimops-ug.xml @@ -0,0 +1,326 @@ + + + +FSIMs and file system operations + +This chapter discusses the five File System Interface Modules (FSIMs) shipped with EVMS, and then provides examples of adding file systems and coordinating file system checks with the FSIMs. + + +The FSIMs supported by EVMS +EVMS currently ships with five FSIMs. These file system modules allow EVMS to interact with file system utilities such as mkfs and fsck. Additionally, the FSIMs ensure that EVMS safely performs operations, such as expanding and shrinking file systems, by coordinating these actions with the file system. + +You can invoke operations such as mkfs and fsck through the various EVMS user interfaces. Any actions you initiate through an FSIM are not committed to disk until the changes are saved in the user interface. Later in this chapter we provide examples of creating a new file system and coordinating file system checks through the EVMS GUI, Ncurses, and command-line interfaces. +The FSIMs supported by EVMS are: + +JFS +XFS +ReiserFS +Ext2/3 +SWAPFS + + +JFS + +The JFS module supports the IBM journaling file system (JFS). +Current support includes mkfs, unmkfs, +fsck, and online file system expansion. +Support for external logging will be added in a future release of EVMS. +You must +have at least version 1.0.9 of the JFS utilities for your system +to work with this EVMS FSIM. You can download the latest utilities +from the JFS for Linux +site. + + +For more information on the JFS FSIM, refer to . + + + + +XFS + +The XFS FSIM supports the XFS file system from SGI. +Command support includes mkfs, unmkfs, +fsck, and online expansion. Use version 1.2 or higher, which you can download from the SGI open source FTP directory. + + + +For more information on the XFS FSIM, refer to . + + + + +ReiserFS + +The ReiserFS module supports the ReiserFS journaling file system. +This module supports mkfs, unmkfs, fsck, online and offline +expansion and offline shrinkage. You need version 3.x.1a or higher +of the ReiserFS utilities for use with the EVMS FSIM modules. You can download +the ReiserFS utilities from The Naming +System Venture (Namesys) web site. + + + +For more information on the ReiserFS FSIM, refer to . + + + +Ext2/3 + +The EXT2/EXT3 FSIM supports both the ext2 and ext3 file system formats. +The FSIM supports mkfs, unmkfs, +fsck, and offline shrinkage and expansion. + + + +For more information on the Ext2/3 FSIM, refer to . + + + +SWAPFS + +The SWAPFS FSIM supports Linux swap devices. The FSIM lets you create +and delete swap devices, and supports mkfs, +unmkfs, shrinkage and expansion. +Currently, you are responsible for issuing the +swapon and swapoff commands either in +the startup scripts or manually. +You can resize swap device with the SWAPFS FSIM as long as the device is +not in use. + + + + + +Example: add a file system to a volume +After you have made an EVMS or compatibility volume, add a file system to the volume before mounting it. You can add a file system to a volume through the EVMS interface of your choice. + +
Add a JFS File System to a Volume +This example creates a new JFS file system, named jfs_vol, on volume /dev/evms/my_vol. +
+ +Using the EVMS GUI +Follow these steps to create a JFS file system with the EVMS GUI: + + + Select Actions + File Systems + Make. + + + Select JFS File System Interface Module. + + + Click Next. + + + Select /dev/evms/my_vol. + + + Click Next. + + + + Type jfs_vol in the "Volume Label" + field. Customize any other options you are interested in. + + + Click Make. + + + The operation is completed when you save. + + + + +Alternatively, you can perform some of the steps to create a file system with the GUI +context sensitive menu: + + From the Volumes tab, right click + /dev/evms/my_vol. + Click Make Filesystem... + Continue creating the file system beginning with step 2 of the + GUI instructions. You can skip steps 4 and 5 of the GUI instructions. + + + + + +Using Ncurses + Follow these steps to create a JFS file system with Ncurses: + + + Select ActionsFile SystemsMake. + + +Select JFS File System Interface Module. + +Activate Next. + +Select /dev/evms/my_vol. + +Activate Next. + + Scroll down using the down arrow until + Volume Label is highlighted. + + + + Press Spacebar. + + + At the "::" prompt enter jfs_vol. + + + Press Enter. + + + Activate Make. + + + +Alternatively, you can perform some of the steps to create a file system with the +context sensitive menu: + + +From the Volumes view, press Enter on +/dev/evms/my_vol. + +Activate the Make Filesystem menu item. + +Continue creating the file system beginning with step 2 of the +Ncurses instructions. + + + + + + +Using the CLI + + + Use the + mkfs command to create the new file system. +The arguments to mkfs include the FSIM type (in our example, JFS), followed +by any option pairs, and then the volume name. The command to accomplish +this is: + +mkfs: JFS={vollabel=jfs_vol}, /dev/evms/my_vol + +The command is completed upon saving. +If you are interested in other options that mkfs can +use, look at the results of the following query: + +query: plugins, plugin=JFS, list options + + + + + +Example: check a file system +You can also coordinate file system checks from the EVMS user interfaces. + +
Check a JFS File System +This example shows how to perform a file system check on a JFS file system, named jfs_vol, on volume /dev/evms/my_vol, with verbose output. +
+ +Using the EVMS GUI +Follow these steps to check a JFS file system with the EVMS GUI: + + + Select Actions + File Systems + Check/Repair. + + + Select /dev/evms/my_vol. + + + Click Next. + + + + Click the Yes button by Verbose Output. + Customize any other options you are interested in. + + + Click Check. + + + The operation is completed when you save. + + + + +Alternatively, you can perform some of the steps to check a file system with the GUI context sensitive menu: + + From the Volumes tab, right click + /dev/evms/my_vol. + Click Check/Repair File System... + + Continue checking the file system beginning with step 3 of the + GUI instructions. + + + + + + +Using Ncurses + Follow these steps to check a JFS file system with Ncurses: + + + Select Actions + File SystemCheck/Repair + + + Select + /dev/evms/my_vol. + + + Activate Next. + + + Scroll down using the down arrow until + Vebose Output is highlighted. + + + Press Spacebar to change Verbose Output to Yes. + + + Activate Check. + + + + + +Alternatively, you can perform some of the steps to check a file system with the +context sensitive menu: + + +From the Volumes view, press Enter on /dev/evms/my_vol. + +Activate the Check/Repair File System menu item. + +Continue checking the file system beginning with step 3 of the Ncurses +instructions. + + + + + +Using the CLI + + + The CLI check command takes a volume name and options as + input. The command to check the file system on /dev/evms/my_vol is the following: + + +check: /dev/evms/my_vol, verbose=TRUE + +Currently, a query command for viewing additional options is not available. + + + + + diff --git a/LDP/guide/docbook/EVMSUG/plugin-ug.xml b/LDP/guide/docbook/EVMSUG/plugin-ug.xml new file mode 100644 index 00000000..127009c4 --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/plugin-ug.xml @@ -0,0 +1,4 @@ +More About the Standard EVMS Plug-Institle> + +<para>This appendix provides detailed information about the standard EVMS +plug-ins and describes diff --git a/LDP/guide/docbook/EVMSUG/plugintasks.xml b/LDP/guide/docbook/EVMSUG/plugintasks.xml new file mode 100644 index 00000000..7427754f --- /dev/null +++ b/LDP/guide/docbook/EVMSUG/plugintasks.xml @@ -0,0 +1,160 @@ + + + +<chapter id="plugintasks"><title>Plug-in operations tasks + +This chapter discusses plug-in operations tasks and shows how to complete a plug-in task with the EVMS GUI, Ncurses, and CLI interfaces. + +What are plug-in tasks? +Plug-in tasks are functions that are available only within the context of a particular plug-in. These functions are not common to all plug-ins. For example, tasks to add spare disks to a RAID array make sense only in the context of the MD plug-in, and tasks to reset a snapshot make sense only in the context of the Snapshot plug-in. + + +Example: complete a plug-in operations task + This section shows how to complete a plug-in operations task with the EVMS GUI, Ncurses, and CLI interfaces. + +
Add a spare disk to a compatibility volume made from an MDRaid5 region +This example adds disk sde as a spare disk onto volume /dev/evms/md/md0, which is a compatibility volume that was created from an MDRaid5 region.
+ +Using the EVMS GUI +Follow these steps to add sde to /dev/evms/md/md0 with the EVMS GUI: + + + Select Other + Storage Object Tasks... + + + Select md/md0. + + + Click Next. + + + Select Add spare object. + + + Click Next. + + + + Select sde. + + Click Add. + + + The operation is completed when you save. + + +Alternatively, you could use context-sensitive menus to +complete the task, as follows: + + + View the region md/md0. You can view the region either + by clicking on the small plus sign beside the volume name + (/dev/evms/md/md0) on the volumes tab, + or by selecting the regions tab. + + Right click the region (md/md0). A list of acceptable + Actions and Navigational shortcuts displays. The last items on the + list are the tasks that are acceptable at this time. + + Point to Add spare object and + left click. + + Select sde. + + Click Add. + + + + +Using Ncurses + Follow these steps to add sde to /dev/evms/md/md0 with Ncurses: + + + Select Other + Storage Object Tasks + + + + + Select + md/md0. + + + Activate Next. + + + Select + Add spare object. + + + Activate Next. + + + Select + sde. + + + Activate Add. + + + + + +Alternatively, you can use the context sensitive menu to complete the task: + + +From the Regions view, press Enter on md/md0. + +Activate the Add spare object menu item. + +Select sde. + +Activate Add. + + + + + +Using the CLI + + + With the EVMS CLI, all plug-in tasks must be +accomplished with the task command. Follow these steps +to add sde to /dev/evms/md/md0 +with the CLI: + + + The following query command with the list + options filter to determines + the acceptable tasks for a particular object and the name-value + pairs it supports. The command returns information about which + plug-in tasks are available at the current time and provides + the information necessary for you to complete the command. + + + query: objects, object=md/md0, list options + + + + The command takes the name of the task + (returned from the previous query), the object to operate on + (in this case, md/md0), any required options (none in this case) + and, if necessary, another object to be manipulated + (in our example, sde, which is the spare disk + we want to add): + + task: addspare, md/md0, sde + + The command is completed upon saving. + + + + + + + + + + + \ No newline at end of file