User manual QUANTUM STORNEXT 4.1 RELEASE NOTES REV C

[. . . ] StorNext 4. 1 Release Notes Product Date StorNext® 4. 1 December 2010 Contents Purpose of this Release . 6-00431-34 Rev C, December 2010 Quantum, the Quantum logo, DLT, DLTtape, the DLTtape logo, SuperLoader, Scalar, StorNext, and DXi are registered trademarks of Quantum Corporation, registered in the U. S. StorNext utilizes the following components which are copyrighted by their respective entities: ACSAPI, copyright © Storage Technology Corporation Java, copyright Oracle Corporation LibICE, LibSM, LibXau, LibXdmcp, LibXext, LibXi copyright The Open Group LibX11copyright The Open Group, MIT, Silicon Graphics, and the Regents of the University of California, and copyright (C) 1994-2002 The XFree86 Project, Inc. Libxml2 and LibXdmcp, copyright MIT Linter, copyright © Relex Software Corporation Ncurses, copyright © 1997-2009, 2010 by Thomas E. [. . . ] Resolved an issue which prevented snhamgr from enabling/disabling HA resets if fsmpm was not running. Resolved a condition which caused syncha. pl to fail because it was unable to communicate with the hostname by using gethostname. Corrected an issue which prevented converting to HA on the secondary system due to not being able to mount a shared file system. Resolved a condition which prevented accessing StorNext after several iterations of 'primary MDC power cycle test' on HA systems. Corrected an issue in which scanning with 4. 0 GUI and ACSLS 8. 0 returned bad data. (Devices were missing, and the drive serial number was unreadable. ) 32309 n/a 31865 n/a 31867 n/a 31894 Linux 31898 n/a n/a 31921 n/a 32412 n/a 32152 n/a Resolved Issues 35 StorNext 4. 1 Release Notes 6-00431-34 Rev C December 2010 Operating System All CR Number 32432 SR Number n/a Description Resolved a condition which generated the following error in the log reports when converting the primary MDC to HA: 'ungraceful shutdown of share FS' Corrected a condition in which snpolicyd seemed stuck on Start after being forcibly killed. Resolved a condition in which creating the blockpool failed silently due to insufficient memory. Corrected a condition in which Replication instantiated two identical copies of the target namespace. Corrected a condition which prevented manually truncating files reliably. The active server is no longer counted against the Distributed Data Mover license count. FSM now picks up the new number of licensed clients without requiring a restart. Corrected a condition in which the license key generator (cvfsskey) did not create a Manager license for 1567 TB. 31868 31885 32223 n/a n/a n/a 32282 32367 32164 32165 32211 n/a 1174446 1166852 1176490 1144680 36 Resolved Issues StorNext 4. 1 Release Notes 6-00431-34 Rev C December 2010 Known Issues The following sections list known issues in this release of StorNext, as well as associated workarounds, where applicable: · StorNext File System Known Issues on page 37 · StorNext Storage Manager Known Issues on page 40 · StorNext GUI Known Issues on page 42 · StorNext HA and Replication Known Issues on page 48 StorNext File System Known Issues Table 14 lists known issues that are specific to StorNext File System. Table 14 StorNext File System Known Issues Operating System Linux CR Number 25864 SR Number n/a Description An NFS server that exports a StorNext file system with the default export options may not flush data to disk immediately when an NFS client requests it. This could result in loss of data if the NFS server crashes after the client has written data, but before the data has reached the disk. Scheduled tasks for "partial backups" and for "rebuild policy" can fail if they overlap. Workaround (if applicable) The workaround is to add the no_wdelay option to each line in the /etc/ exports file that references a StorNext file system. If you have a large managed file system you might need to adjust schedules to permit longer times if your partial backups require more than two hours to complete. Changing the allotted time will ensure that the partial backup completes before the rebuild policy task starts. 25978 n/a Known Issues 37 StorNext 4. 1 Release Notes 6-00431-34 Rev C December 2010 Operating System Linux CR Number 28375 SR Number n/a Description StorNext doesn't replicate nonregular files. (Currently, StorNext skips files that are UNIX domain sockets, block/char devices, and fifo's. Some of these file types could be included in namespace replication. ) When a machine is rebooted, in rare situation, the network interfaces may have been changed. If you have configured Distributed LAN Server (DLS), the file system may fail to mount because the DLS may perceive that the associated network interface may have changed or disappeared. In an HA configuration, RAS messages are not generated for loss of SAN connectivity by the secondary system. Workaround (if applicable) The workaround is to ensure that your replication workflow does not rely on non-regular file replication. 28561 n/a To work around this issue, you must find the appropriate network interfaces and reconfigure the dpserver. fsname file and then remount the file system. A workaround is to activate some of the unmanaged file systems on the secondary metadata controller. This will allow RAS messages from the secondary MDC if there is SAN connectivity loss. [. . . ] The VIP is an alias IP address that is associated with a real interface. For example, if the VIP is based on eth0, eth0:ha will be created as the VIP. The netmask you associate with the VIP should generally be the same as that of the base interface, but in no case should it be more specific. For example, if the netmask on eth0 is 255. 255. 224. 0 (a /19), then configuring the VIP netmask as anything more than a /19, such as a /24 (255. 255. 255. 0) would be incorrect. [. . . ]