Quantum STORNEXT 3.1.3 User Manual

StorNext 3.1.3 Release Notes

Product

Supported Platforms:
Storage Manager, File
System MDC, Distributed
LAN Server and Client, and
SAN Client

StorNext 3.1.3

Red Hat® Enterprise Linux® 4

• x86 32-bit and x86 64-bit

• Itanium x86 64-bit

Red Hat Enterprise Linux 5

• x86 64-bit

SUSETM Linux Enterprise Server 10

• x86 32-bit and x86 64-bit

• Itanium x86 64-bit

Supported Platforms:
File System MDC,

Windows Server 2003

• x86 32-bit and x86 64-bit

®

Distributed LAN Server and
Client, and SAN Client

Supported Platforms:
Distributed LAN Server and

Windows XP

• x86 32-bit and 64-bit

®

Client, and SAN Client

Document 6-00431-23 Rev A

Quantum Corporation provides this publication “as is” without warranty of any kind, either express or implied, including but not limited to
the implied warranties of merchantability or fitness for a particular purpose. Quantum Corporation may revise this publication from time to
time without notice.

COPYRIGHT STATEMENT

© Copyright 2000 - 2009 Quantum Corporation. All rights reserved.

US Patent No: 5,990,810 applies. Other Patents pending in the US and/or other countries.

StorNext is either a trademark or registered trademark of Quantum Corporation in the US and/or other countries.

Your right to copy this manual is limited by copyright law. Making copies or adaptations without prior written authorization of Quantum
Corporation is prohibited by law and constitutes a punishable violation of the law.

TRADEMARK STATEMENT

DLT and DLTtape are trademarks of Quantum Corporation. Quantum, the Quantum logo, and the DLTtape logo are all registered
trademarks of Quantum Corporation. Other trademarks may be mentioned herein which belong to other companies.

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Supported Platforms:
Distributed LAN Client and
SAN Client

Supported Platforms:
File System MDC, SAN
Client and Storage Manager

Supported Platforms: SAN
Client

Windows Vista

®

• x86 32-bit and 64-bit

Windows Server 2008

®

• x86 32-bit and 64-bit

Sun SolarisTM 10

• SPARC 64-bit

Sun SolarisTM 9

• SPARC 64-bit

Sun Solaris 10

• Opteron x86 64-bit

•Intel x86 64-bit

IBM AIX

• 64-bit Power Architecture

HP-UX

•Itanium 64-bit

SGI IRIX

•64-bit MIPS

Apple MacOS X

• x86 32-bit

Date

January 2009

2

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Contents 0

Purpose of this Release ................................................................................................. 4

Enhancements and Improvements.............................................................................. 4

Changes From Previous Releases................................................................................ 4

StorNext Upgrade Recommendations........................................................................ 6

Configuration Requirements........................................................................................ 6

Operating System Requirements................................................................................. 8

Supported Libraries and Tape Drives ...................................................................... 11

Minimum Firmware Levels for StorNext Drives.................................................... 13

Supported System Components ................................................................................ 14

Hardware Requirements ............................................................................................ 15

Resolved Issues ............................................................................................................ 17

Known Issues ............................................................................................................... 23

Operating Guidelines and Limitations..................................................................... 34

Documentation............................................................................................................. 35

Contacting Quantum................................................................................................... 36

Contents 3

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Purpose of this Release 0

StorNext 3.1.3 includes enhancements that extend the capabilities of StorNext
Storage Manager (SNSM) and StorNext File System (SNFS). This document
describes these enhancements, as well as supported platforms and system
components. This document also lists currently known issues, issues that were
resolved for this release, and known limitations.

Visit www.quantum.com/ServiceandSupport for additional information and
updates for StorNext.

Enhancements and Improvements 0

StorNext support for the Sun/StorageTek SL3000 library has been added. In
addition, validation on this library was added for ACSLS 7.3.

Changes From Previous Releases 0

The following change was instituted in a previous StorNext release and is listed
here as a reminder that important settings have been changed.

Revised FSBlockSize, Metadata Disk Size, and JournalSize Settings

The FsBlockSize (FSB), metadata disk size, and JournalSize settings all work
together. For example, the FsBlockSize must be set correctly in order for the

0

metadata sizing to be correct. JournalSize is also dependent on the FsBlockSize.
For FsBlockSize the optimal settings for both performance and space utilization

are in the range of 16K or 64K.

Settings greater than 64K are not recommended because performance will be
adversely impacted due to inefficient metadata I/O operations. Values less than
16K are not recommended in most scenarios because startup and failover time

may be adversely impacted. Setting FsBlockSize (FSB) to higher values is

important for multi-terabyte file systems for optimal startup and failover time.

Note: This is particularly true for slow CPU clock speed metadata

servers such as Sparc. However, values greater than 16K can
severely consume metadata space in cases where the file-to­directory ratio is low (e.g., less than 100 to 1).

For metadata disk size, you must have a minimum of 25 GB, with more space
allocated depending on the number of files per directory and the size of your file
system.

Purpose of this Release 4

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

The following table shows suggested FsBlockSize (FSB) settings and metadata

disk space based on the average number of files per directory and file system size.
The amount of disk space listed for metadata is in addition to the 25 GB minimum
amount. Use this table to determine the setting for your configuration.

Average No.
of Files Per
Directory

File System SIze: Less
Than 10TB

File System Size: 10TB
or Larger

Less than 10 FSB: 16KB

Metadata: 32 GB per 1M
files

10-100 FSB: 16KB

Metadata: 8 GB per 1M
files

100-1000 FSB: 64KB

Metadata: 8 GB per 1M
files

1000 + FSB: 64KB

Metadata: 4 GB per 1M
files

FSB: 64KB

Metadata: 128 GB per 1M
files

FSB: 64KB

Metadata: 32 GB per 1M
files

FSB: 64KB

Metadata: 8 GB per 1M
files

FSB: 64KB

Metadata: 4 GB per 1M
files

The best rule of thumb is to use a 16K FsBlockSize unless other requirements

such as directory ratio dictate otherwise.

This setting is not adjustable after initial file system creation, so it is very
important to give it careful consideration during initial configuration.

Example: FsBlockSize 16K

JournalSize Setting 0

The optimal settings for JournalSize are in the range between 16M and 64M,
depending on the FsBlockSize. Avoid values greater than 64M due to potentially

severe impacts on startup and failover times. Values at the higher end of the 16M­64M range may improve performance of metadata operations in some cases,
although at the cost of slower startup and failover time.

The following table shows recommended settings. Choose the setting that
corresponds to your configuration.

FsBlockSize JournalSize

16KB 16MB

64KB 64MB

This setting is adjustable using the cvupdatefs utility. For more information, see
the

cvupdatefs man page.

Example: JournalSize 16M

Changes From Previous Releases 5

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

StorNext Upgrade Recommendations 0

Customers migrating to 3.1.3 should observe the following best practices:

• Whenever possible, StorNext systems should run the latest StorNext­supported operating system service pack or update level.

• When upgrading from StorNext 2.8 to StorNext 3.1.3 on RHEL4, you should
first upgrade the operating system to update 7. For example, if SNMS 2.8 is
installed on RHEL4U3, the upgrade procedure is:

1. Upgrade the operating system from RHEL4U3 to RHEL4U7

2. Upgrade the StorNext version from 2.8 to 3.1.3

Since StorNext 3.1.3 requires Update 5, 6 or 7 of RHEL4, these steps should be
performed one after the other to avoid running StorNext with an
unsupported Red Hat update level longer than necessary.

• StorNext 3.1.3 does not support RHEL5 GA (“update 0”). When upgrading a
system running RHEL5 GA to StorNext 3.1.3, you must first upgrade the
operating system to RHEL5U2.

• StorNext 3.1.3 does not support AIX 5.2. When upgrading clients running
AIX 5.2 to StorNext 3.1.3, perform the following steps:

1 Make a backup copy of /etc/filesystems
2 Uninstall StorNext
3 Upgrade the operating system to AIX 5.3
4 Install StorNext 3.1.3
5 Update /etc/filesystems with previously saved StorNext mount

information

Configuration Requirements 0

Before installing StorNext 3.1.3, note the following configuration requirements:

• In cases where gigabit networking hardware is used and maximum StorNext
performance is required, a separate, dedicated switched Ethernet LAN is
recommended for the StorNext metadata network. If maximum StorNext
performance is not required, shared gigabit networking is acceptable.

• A separate, dedicated switched Ethernet LAN is mandatory for the metadata
network if 100 Mbit/s or slower networking hardware is used.

• StorNext does not support file system metadata on the same network as
iSCSI, NFS, CIFS, or VLAN data when 100 Mbit/s or slower networking
hardware is used.

• The operating system on the metadata controller must always be run in U.S.
English.

StorNext Upgrade Recommendations 6

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

• For Windows systems (server and client), the operating system must always
be run in U.S. English.

Caution: If a Library used by StorNext Storage Manager is connected via a

fibre switch, zone the switch to allow only the system(s) running
SNSM to have access to the library. This is necessary to ensure that
a “rogue” system does not impact the library and cause data loss
or corruption. For more information, see CR 24565 in the Known
Issues section of the release notes. See also StorNext Product Alert

16.

Library Requirements 0 The following libraries require special configurations to run StorNext.

DAS and Scalar DLC Network-Attached Libraries 0

Prior to launching the StorNext Configuration Wizard, DAS, and Scalar DLC
network-attached libraries must have the DAS client already installed on the
appropriate host control computer.

January 2009

DAS Attached Libraries 0

For DAS attached libraries, refer to “Installation and Configuration” and “DAS
Configuration File Description” in the DAS Installation and Administration Guide.
The client name is either the default StorNext server host name or the name
selected by the administrator.

StorNext can support LTO-3 WORM media in DAS connected libraries, but
WORM media cannot be mixed with other LTO media types in one logical
library.

To use LTO-3 WORM media in a logical library, before configuring the library in
StorNext, set the environmental variable

/usr/adic/MSM/config/envvar.config file to the name of the library. The library name

XDI_DAS_MAP_LTO_TO_LTOW in the

must match the name given to the library when configuring it with StorNext. If
defining multiple libraries with this environmental variable, separate them with a
space. After setting the environmental variable, restart StorNext Storage Manager
(SNSM).

Note: SDLC software may not correctly recognize LTO-3 WORM media in

the library and instead set it to “unknown media type.” In this case
you must manually change the media type to “LTO3” using the SDLC
GUI.

Scalar DLC Attached Libraries 0

For Scalar 10K and Scalar 1000 DLC attached libraries, refer to “Installation and
Configuration” and “Client Component Installation” in the Scalar Distributed
Library Controller Reference Manual (6-00658-04).

The DAS client should be installed during the installation of the Scalar DLC
attached libraries. Use this procedure to install the DAS client.

Configuration Requirements 7

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

1 Select Clients > Create DAS Client.

The client name is either the default StorNext server host name or the name
selected by the administrator.

2 When the DAS client is configured in Scalar DLC, select Aliasing.
3 Select sony_ait as the Media aliasing.

The default value is 8mm.

4 Verify that Element Type has AIT drive selected.
5 Click Change to execute the changes.

ACSLS Attached Libraries 0

Due to limitations in the STK ACSLS interface, StorNext supports only single ACS
configurations (ACS 0 only).

Scalar i500 (Firmware Requirements) 0

For Scalar i500 libraries that do not have a blade installed, the library and drives
must meet the following minimum firmware requirements. (These requirements
apply only to Scalar i500 libraries that do not have a blade installed.)

• Scalar i500 minimum firmware level: 420GS.GS00600

• HP LTO-4 Fibre/SAS tape device minimum firmware level: H35Z

Caution: If you do not meet the minimum firmware requirements, you

might be unable to add a library to the Scalar i500 using the
StorNext Configuration Wizard.

Disk Naming Requirements

When naming disks, names should be unique across all SANs. If a client connects
to more that one SAN, a conflict will arise if the client sees two disks with the

0

same name.

Operating System Requirements 0

Table 1 shows the operating systems, kernel versions, and hardware platforms

that support StorNext File System, StorNext Storage Manager, and the StorNext
client software.

This table also indicates the platforms that support the following:

•MDC Servers

• Distributed LAN Servers

• File System LAN Clients

Operating System Requirements 8

Table 1 StorNext Supported
OSes and Platforms

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Notes: When adding StorNext Storage Manager to a StorNext File System environment, the metadata controller (MDC)

must be moved to a supported platform. If you attempt to install and run a StorNext 3.1.3 server that is not supported,
you do so at your own risk. Quantum strongly recommends against installing non-supported servers.

* 64-bit versions of Windows support up to 128 distributed LAN clients. 32-bit versions of Windows is not recommended

for MDC server or Distributed LAN due to memory limitations.

** Red Hat EL 4 has been linked to data corruption as described in StorNext Product Alert 16 and CR24565 in the Known

Issues section of this document.

*** Due to a bug in RHEL5, Storage Manager systems will crash when running kernels based on 2.6.18-8. This has been

corrected in RHEL5 updates 1 and 2. For additional details, refer to CR 16484 in the Known Issues section of this
document.

‡

StorNext releases after 3.1.3 might not include support for this StorNext configuration.

Operating System Requirements 9

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Notes: When adding StorNext Storage Manager to a StorNext File System environment, the metadata controller (MDC)

must be moved to a supported platform. If you attempt to install and run a StorNext 3.1.3 server that is not supported,
you do so at your own risk. Quantum strongly recommends against installing non-supported servers.

† StorNext support will transition from HP-UX 11i v2 to 11i v3, and from IBM AIX 5.3 to 6.1 on a future date.

‡

StorNext releases after 3.1.3 might not include support for this StorNext configuration.

Note: For systems running Red Hat Enterprise Linux version 4 or 5, before

installing StorNext you must first install the kernel header files
(shipped as the kernel-devel-smp or kernel-devel RPM).

For systems running SUSE Linux Enterprise Server, you must first
install the kernel source code (typically shipped as the kernel-source
RPM).

Caution: Red Hat 5 ships with secure Linux kernel enabled by default. To

ensure proper StorNext operation, you must not install Red Hat 5
with secure Linux enabled. The secure Linux kernel must be off, or
the file system could fail to start.

Note: GNU tar is required on Solaris systems. In addition, for systems

running Solaris 10, install the Recommended Patch Cluster (dated
March 10, 2006 or later) before installing StorNext.

To enable support for LUNs greater than 2TB on Solaris 10, the
following patches are required:

• 118822-23 (or greater) Kernel Patch

• 118996-03 (or greater) Format Patch

• 119374-07 (or greater) SD and SSD Patch

• 120998-01 (or greater) SD Headers Patch

Operating System Requirements 10

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Supported Libraries and Tape Drives 0

Libraries and tape drives supported for use with StorNext 3.1.3 are presented in

Table 2. Where applicable, minimum firmware levels for libraries are provided.

Table 2 StorNext Supported
Libraries and Tape Drives

Supported Libraries and Tape Drives 1 1

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Notes:

Sun/Storage Tek no longer supports ACSLS version 6.x. Version 7.0 or higher is required.

Before using DLT cleaning with DLT-S4 or SDLT 600 drives, configure the library (Scalar i2000 or PX720) to
disable reporting of the media ID. If media ID reporting is not disabled, StorNext will not recognize the
cleaning media (SDLT type 1).

* When using T10000 drives, the STK library parameter Fastload must be set to OFF.

Supported Libraries and Tape Drives 12

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Minimum Firmware Levels for StorNext Drives 0

Where applicable, the minimum firmware levels for StorNext-supported drives
are shown in

Table 3 Minimum Firmware
Levels for Drives

Table 3.

Note: When using IBM Ultrium-TD3 drives with SUSE Linux Enterprise Server 10, you must upgrade the
drive firmware to version 64D0 or later.

Minimum Firmware Levels for StorNext Drives 13

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Supported System Components 0

System components that are supported for use with StorNext 3.1.3 are presented
in

Table 4.

Table 4 StorNext Supported
System Components

Component Description

Browsers Internet Explorer 6.0 or later (including 7.0)

Mozilla Firefox 1.5 or later (including 2.0 or later)
(Minimum browser resolution: 800x600)

NOTE: Disable pop-up blockers.

LTO-1 Media to
LTO-3 or LTO-4
Drive Compatibility

LTO-1 media in an LTO-3 or LTO-4 library (LTO-3 or
LTO-4 drives) are considered for store requests unless
they are logically marked as write protected. When
LTO-1 media is mounted in an LTO-3 or LTO-4 drive,
StorNext marks the media as write protected.
Quantum recommends circumventing LTO-1 media
for store requests by following this procedure:

1 From the SNSM home page, choose Attributes

from the Media menu.

2 On the Change Media Att ributes window, select the

LTO-1 media from the list.
3 Click the Write Protect option.
4 Click Apply to make the change.
5 Repeat the process for each piece of LTO-1 media.

NFS Version 3

NOTE: 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.

This issue will be addressed in a future StorNext

release. As a workaround, add the no_wdelay option
to each line in the /etc/exports file that references a

StorNext file system. For example, typical export

options would be (rw,sync,no_wdelay).

Addressable Power
Switch

WTI RPS-10m
WTI IPS-800

The RPS-10m (master) is supported.
The RPS-10s (slave) is not supported.

LDAP LDAP (Lightweight Directory Access Protocol)

support requires Windows Active Directory.

Supported System Components 14

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Hardware Requirements 0

To successfully install StorNext 3.1.3, the following hardware requirements must
be met:

• StorNext Storage Manager Requirements on page 15

• StorNext File System Requirements on page 16

• StorNext Client Software Requirements on page 16

• Disk SCSI Command Requirements on page 16

Note: The following requirements are for running StorNext only. Running

additional software (including the StorNext client software) requires
additional RAM and disk space.

StorNext Storage Manager Requirements

Table 5 Storage Manager
Hardware Requirements

The hardware requirements for StorNext Storage Manager are presented in

0

Table 5.

File Systems RAM Disk Space

1–4* 2 GB • For application binaries, log files, and

5–8** 4 GB

* Two CPUs recommended for best performance.
** Two CPUs required for best performance.

Note: If a file system uses deduplicated storage disks (DDisks), note the

following additional requirements:

• Requires 2 GB RAM per DDisk in addition to the base RAM noted in

Table 5.

• Requires an additional 5GB of disk space for application binaries
and log files.

• Deduplication is supported only for file systems running on a Linux
operating system (x86 32-bit or x86 64-bit).

• An Intel Pentium 4 or later processor (or an equivalent AMD
processor) is required. For best performance, Quantum recommends
an extra CPU per DDisk.

documentation: up to 30GB (depending
on system activity)

• For support directories: 3 GB per million
files stored

Hardware Requirements 15

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

StorNext File System Requirements

Table 6 File System Hardware
Requirements

StorNext Client Software Requirements

The hardware requirements for StorNext File System are presented in Table 6.

0

File Systems RAM Disk Space

1–4* 2 GB 2 GB

5–8** 4 GB 4 GB

* Two CPUs recommended for best performance.
** Two CPUs required for best performance.

To install and run the StorNext client software, the client system must meet the
following minimum hardware requirements.

0

For SAN (FC-attached) clients or for Distributed LAN Clients:

•1 GB RAM

• 500 MB available hard disk space

For SAN clients acting as a Distributed LAN Server:

•2 GB RAM

• 500 MB available hard disk space

Disk SCSI Command Requirements

Note: Distributed LAN servers may require additional RAM depending on

the number of file systems, Distributed LAN Clients, and NICs used.
See

Distributed LAN Server Memory Tuning in the StorNext User’s

Guide for Distributed LAN Server memory tuning guidelines.

Disk devices must support, at minimum, the mandatory SCSI commands for
block devices as defined by the SCSI Primary Commands-3 standard (SPC-3) and

0

the SCSI Block Commands-2 (SBC-2) standard.

Disk devices must meet the requirements specified by Windows Hardware
Quality Labs (WHQL) testing.

Disk devices must be configured with 512-byte or 4096-byte sectors, and the
underlying operating system must support the device at the given sector size.
StorNext 3.1.3 only supports 4096-byte sectors on Windows and Linux systems.

In some cases, non-conforming disk devices can be identified by examining the

output of cvlabel –vvvl. For example:

/dev/rdsk/c1d0p0: Cannot get the disk physical info.

If you receive this message, contact your disk vendors to determine whether the
disk has the proper level of SCSI support.

Hardware Requirements 16

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Resolved Issues 0

The following sections list resolved issues in this release of StorNext:

• StorNext File System Resolved Issues on page 17

• StorNext Storage Manager Resolved Issues on page 21

• StorNext GUI Resolved Issues on page 22

• StorNext Installation Resolved Issues on page 23

Note: There is no change to cryptographic functionality in StorNext release

3.1.3.

StorNext File System Resolved Issues

Table 7 StorNext File System
Resolved Issues

Operating System CR Number SR Number Description

Linux 23115 597852,

Table 7 lists resolved issues that are specific to StorNext File System.

0

Corrected a condition in which running the command

888502

24191 n/a Corrected a Linux Xattr NULL Pointer Reference in

24238 n/a Timeout duration was increased for start/activate

24348 n/a Corrected a condition in which running the rm

24350 n/a Resolved a condition in which sigalrm could not be

24423 n/a The cvadmin command now receives the correct host

ls -l returned incomplete file information.

cvfs_xattr_user_get.

FSM.

command on a large directory caused soft lockups.

used to interrupt a file lock call.

name when checking status.

24857 n/a Corrected signal handling for the sigalm command on

Linux systems.

24958 n/a Corrected a condition in which md_get_dirattrs failed

when symlink exists in the directory.

25092 n/a Changes were added to support SLES 10 SP2.

25106 n/a Corrected a condition in which a file system folder is

stuck after a pulling a Fibre Channel cable during
testing.

25232 871620 Corrected a condition that produced mount failure

and the error message “no such file or directory.”

Resolved Issues 17

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Operating System CR Number SR Number Descriptio n

Linux 25262 n/a Resolved a condition in which Windows SetEndOfFile

preallocation did not always occur.

25396 884884,

872694

Resolved a memory corruption issue that caused the
metadata controller to crash.

25505 n/a HP cvpower scripts were perfected.
25819 n/a /usr/adic/HAM/shared/TSM/internal/event_dir/

*corrupt* files are no longer created and stored.

25857 n/a Corrected a condition that caused a blue screen error

on Windows when running the process monitor
(procmon).

25997 n/a Resolved a race condition in cvupdatefs that

potentially wrote ARB block in the wrong location.

26205 n/a Corrected a condition in which cvfsck doubly

allocated block false positives.

26213 902316 Corrected a potential data corruption issue that could

occur when reading a file.

26363 n/a Resolved a condition that caused case insensitive

rename failure in snmetadump.

26425 597852,

888502

Corrected a condition which caused the command ls -l

to return incomplete information on a file.

AIX 24882 840822 Corrected a condition in which incorrect data was

returned after using the pwd command.

24934 842264

893668

Corrected a crash in vnop_rele when called from
cvfs_create_attr after errors occurred.

IRIX 25052 724406 Added support for RAIDs and disks with 4KB sector

sizes.

Windows 24653 n/a Support has been added for a unique onboard SAS

RAID controller.

24662 n/a Resolved a condition in which the testbench tool

secreg did not compile properly using a third-party
application.

24919 n/a Corrected a condition that caused a blue screen error

after a Fibre Channel cable was inserted.

25068 n/a Removed the Windows installer limitation of 32

characters for the build number. The new limit is 512
characters.

25078 860992 Corrected an FSM coredump caused because the

alloc_session_lock was not initialized.

25103 n/a The Remote Notification feature can now be enabled

via a variable in the configuration file.

Resolved Issues 18

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Operating System CR Number SR Number Descriptio n

Windows 25181 861094 Corrected a condition that caused SetEndOfFile to

return the incorrect updated file size after truncation.

25187 n/a MEGARAID was added to licensing validation codes.

25203 n/a Resolved a condition that caused an infinite loop error

in FsmPM upon registry errors.

25206 850986 Sonic Scenarist HD DVD now works correctly with

SNFS.

25404 903964,

919712,
945086

The Remote Notification feature can now be enabled
via a configuration file (.cfg) variable. (This feature
continues to be Off by default.)

25442 n/a Corrected a condition in which a Windows client went

into a hung state if it retrieved a security descriptor
greater than 8K.

25613 890216 Corrected a condition that caused a blue screen error

on an SNMS Windows client when an iSCSI disk went
away and then came back.

25941 903638 Resolved a condition in which calling syslog too soon

caused an exception.

26149 914828 Corrected a condition that prevented monitoring

StorNext and LAN server performance.

26189 915042 Resolved a condition in which cvntadmin dumped

core while gathering client information.

26649 n/a Resolved a condition in which SNFS did not install

correctly on a Windows system due to conflicts with
signing certificates.

26741 n/a Resolved a condition in which errors occurred when

upgrading from 3.1.2 to 3.1.3 with the file system
mounted.

26775 n/a Corrected a condition in which perfmon did not work

correctly on 64-bit platforms.

All 24110 773540 Corrected a condition in which raid string file

processing failed when encountering blank lines.

24199 n/a Corrected an ReAcquireRtio freed pointer dereference

and memory leak.

24237 n/a Corrected an FSM memory leak in XattrAddChain.

24624 818454 Corrected an error condition that caused an assert in

FsRasSentTimeout.

24727 809080 Corrected a condition in which the backup script did

not correctly process newlines.

Resolved Issues 19

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Operating System CR Number SR Number Descriptio n

All 24773 n/a Addressed Solaris 10 and Irix cvlabel incompatibility

issues.

24906 n/a Resolved a condition in which the temporary restore

journal failed with an EBADF.

24912 n/a Corrected a condition when showing the directory

blocks of a B+ tree in which cvbtree tried to format all

space in the file system block as a B+ tree, even if the
B+ tree is smaller than a full fsblock.

24960 847324 Auth_secret on Distributed LAN Clients now works

correctly.

25027 848896 Corrected a condition in which the cvfsck report was

slow due to unnecessary work.

25051 860818 Resolved a cvfsck failure due to size compare failure.

25098 n/a A new identification string has been created in

cvversions.

25099 n/a A new method of capturing component information

has been created.

25413 n/a Resolved a condition in which the SNFS client could

receive outdated cvnode attr_flags.

25605 n/a Corrected performance problems caused by deferred

flushing from CvClose.

25645 n/a Resolved a condition in which the XML parser

incorrectly set the exclusive flag to false when
detecting the userdata attribute.

25808 892030 Corrected a condition in which cvcp -xyz did not

always update mtime correctly

25872 n/a Corrected the manner in which temporary licenses are

processed.

25933 910482,

933790

Corrected a condition in which directories were
incorrectly deleted during checking.

26306 909788 Resolved a condition in which doubly allocated

extents were detected.

26308 909788 The stripe group number is now displayed when

doubly allocated extents are detected.

26399 924986 Corrected a blockpool corruption condition that

caused complete data lose on an SDISK when using
deduplication.

26658 932342 Corrected a condition in which cvbtree code failed to

insert high keys after certain removal patterns.

Resolved Issues 20

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

StorNext Storage Manager Resolved Issues

Table 8 StorNext Storage
Manager Resolved Issues

Table 8 lists resolved issues that are specific to StorNext Storage Manager.

0

Operating System CR Number SR Number Description

Linux 25254 n/a When setting allow_dio and def_reserved_size /proc/

scsi/sg, the new value for /proc (which has been

deprecated) is /sys. (See CR 24543 for more

information.)

24260 794002 Changed the way in which SUID bits for TSM are set

on SuSE 10 systems.

24261 794002 The internal MSM utility vschmod now works

correctly on SuSE 10 systems

26562 883194 Corrected a condition in which files were written to

the incorrect archive.

26755 945582 Corrected the revision of dmapi library by updating

the tsm/ver/cvfs_rev file.

All 24167 751246 An unmodified copy of the metadump can now be

captured before applying the restore journal.

24250 795978 Changed the method of determining the MSM api

hostname.

25159 865230 The limit TSM set for the maximum number of tape

drives has been changed from 64 to 256 drives.

25434 883194,

889850,

Corrected a condition in which files were written to
tapes in the wrong archive.

915922

25888 899288 Corrected a condition that caused fs_resource to go

into an infinite loop when more than 63 drivepools are
defined.

25917 895622 Corrected errors in the database. (DSR Ticket #10166)

26031 862692,

889850,

Corrected more errors in the database. (Linter Ticket #
9922, 9993, 10145)

906226

26035 854274 Corrected more errors in the database. (Linter Ticket #

10000)

26258 873884,

912164,

Corrected errors which caused fsmedcopy to

overwrite other tapes.

918444

26291 909624 Corrected a condition in which large minsetsize

settings did not trigger stores when copying files into
a directory to which the policy applied.

Resolved Issues 21

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

Operating System CR Number SR Number Descriptio n

All 26315 n/a Cvgather now gathers capacity and usage

information.

25073 845714 Corrected hangs that occurred when running

fsclean -r.

26659 947962 When running the fsretrieve command on multiple

files on the same media, there is a delay while the
media unmounts.

Initially, fsretrieve retrieves the file and then unloads
the tape. The next time fsretrieve runs it has to wait for

the unmount delay to get the same piece of media
remounted.

January 2009

StorNext GUI Resolved Issues

Table 9 StorNext GUI
Resolved Issues

Table 9 lists resolved issues that are specific to the StorNext GUI.

0

Operating System CR Number SR Number Description

Linux 24829 838582 Corrected a condition in which the wrong value for

the stripe breadth was saved in the .cfg file when
adding a new stripe group using the GUI.

25308 n/a The StorNext GUI no longer shows multiple paths to

the same library.

26147 n/a Resolved a condition in which changing watermarks

on a managed file system caused TSM to stop and
then restart without warning.

Windows 25306 n/a When running the StorNext Configuration Wizard,

clicking “Show mapping help” now provides error
message information.

26479 n/a Corrected a condition in which attributes were

dropped after using the StorNext GUI to modify the
configuration file.

All 25111 844668 Resolved a condition in which file system expansion

performed via the StorNext GUI failed.

25312 757180,

771186

25581 888516,

741950

Added the ability to roll all log, error and message
files associated with StorNext.

Corrected a condition in which importing media via
the StorNext GUI’s Add Media command stopped the
Archive Manager.

Resolved Issues 22

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Operating System CR Number SR Number Descriptio n

All 26401 n/a New end user license agreement for StorNext

implemented.

StorNext Installation Resolved Issues

Table 10 StorNext Installation
Resolved Issues

Operating System CR Number SR Number Description

Linux 24830 865808 Resolved a condition in which init.d.cvfs failed to

HP-UX 24862 n/a Support was added to the NXDI code for the

Table 8 lists resolved issues that are specific to StorNext installation.

0

unmount all cvfs file systems in an HA configuration.

25494 822002 Added an on-screen message to the software

explaining that post-installation backups can take a
long time to complete.

25612 821994 Corrected a condition in which cnvt2ha.sh checked

/usr/adic/database/metadumps to obtain list of

managed file systems, resulting in errors.

following HP libraries known collectively as the MSL
G3 Series: 2024, 4048, and 8096.

26474 n/a

Known Issues 0

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 24

• StorNext Storage Manager Known Issues on page 29

• StorNext Installation Known Issues on page 33

Known Issues 23

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

StorNext File System Known Issues

Table 11 S torNext File System
Known Issues

Operating
System

CR
Number

Table 11 lists known issues that are specific to StorNext File System.

0

SR
Number

Description Workaround (if applicable)

Linux 16484 n/a Due to a bug in the RHEL5 “scsi

generic” driver (RedHat Bug 248564),
a system panic will occur on Storage
Managers running RedHat kernels
based on 2.6.18-8.

26664 931830 Intermittent backup failures occurred

and errors appeared in the logs.

24890 836284 DMA I/Os may hang when the file

offset is not aligned and disks
configured with 4096-byte sectors are
used. For example:

dd if=/stornext/sr83628a/file2g of=/
dev/null bs=1880000 count=1 skip=40

RHEL5 updates 1 and 2
contain a fix for this problem.

This issue will be addressed
in a future StorNext release.

This issue will be addressed
in a future StorNext release.

As a workaround, use the

“memalign=4k” mount

option.

Note: this mount option
should NOT be used with file
systems containing LUNs
configured with 512-byte
sectors.

26321 n/a Due to the way Linux handles errors,

the appearance of SCSI “No Sense”
messages in system logs can indicate
possible data corruption on disk
devices.

This affects StorNext users on Red
Hat 4, Red Hat 5, SuSe 9, and SuSe 10.

25102 n/a 32-bit StorNext Distributed Gateways

may lock up under load. This
problem is due to “highmem” kernel
memory depletion and occurs under
load when several distributed LAN
clients perform I/O concurrently.
Using a larger than default value for

the transfer_buffer_size_kb
parameter in the dpserver file will

exacerbate the problem.

This issue is not caused by
StorNext, and is described in
detail in StorNext Product
Alert 20.

For additional information,
see Red Hat 5 CR 468088 and
SuSE 10 CR 10440734121.

The workaround is to use 64­bit Distributed Gateways.

Known Issues 24

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Operating
System

CR
Number

SR
Number Description Workaround (if applicable)

Linux 25864 n/a 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.

26645 n/a After the fsrminfo command is run on

media, the media is logically blank
and the files on the media are no
longer accessible. (You cannot even

use the fsrecover command to bring a

file back.) Truncated files, which have
no other copies on another media,
will be removed from disk by the
follow-on scheduled background
processing.

The command itself completes very
quickly, but the scheduled

background processing (fsclean -r) is

performed by the system sometime

after the fsrminfo command

completes. This processing removes
truncated files from disk for the
provided media (unless other media
copies are available), and removes the
information for all files on the media
from the Tertiary Manager database.

This issue will be addressed
in a future StorNext release.

As a workaround, add the

no_wdelay option to each line
in the /etc/exports file that

references a StorNext file
system. For example, typical
export options would be

(rw,sync,no_wdelay).

This issue will be addressed
in a future StorNext release.

You can manually run the

fsclean -r command.

However, use care because
this processing can be quite
time consuming depending
on the number of files on the
media, and the overall
number of files in the system.

During the time after the fsrminfo

command is run, and before the
scheduled background processing
completes, there will be files on disk
that no longer have their media data
available. If you attempt to retrieve
one of these files, an error will be
reported indicating the media
information for the file was removed.

Note that after the fsrminfo command

completes, the media is available for
re-use immediately, regardless of
whether background processing has
completed.

Known Issues 25

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Operating
System

CR
Number

SR
Number Description Workaround (if applicable)

Linux 25124 833282 A “no space” error appears after you

attempt to add a file to a directory
known to contain sufficient space.

There has been only one known
instance of this problem, which is a
corrupted B-tree for one directory.
Please report any additional instances
to Quantum Support.

Identify this problem by looking for
these indicators:

1. Attempts to add a file to an affected
directory produce a “no space” error.

2. Files can be added to other
directories in the same file system
without error.

3. Running the command cvadmin -F
<FileSystemName> -e show reports

free space in the metadata stripe
groups for the file system of the
affected directory.

After collecting debugging
information, the following
workaround can be applied:

1) Rename the corrupt

directory <dir> to

<dir>.corrupt

2) Create a new directory

named <dir>

3) Move all files from the
corrupt directory

<dir>.corrupt to the newly
created directory <dir>

4) Delete the empty corrupt

directory <dir>.corrupt

Solaris 24331 755956 Running an anonymous FTP server

inside of a StorNext file system could
cause a system to crash with the
following error:

CVFS ASSERTION FAILED: f_cvp­>cv_opencnt == 0

HP-UX 24309 n/a If the cvpaths file contains an invalid

wild-card specification (that is, a
wild-card pattern that does not
include a leading '/' character), the
fsmpm process could panic and the

cvlabel command might fail with a

core dump.

Windows 26115 n/a Failover did not execute properly

after an upgrade.

This issue will be addressed
in a future StorNext release.

To work around this issue,
install Very Secure FTP
Daemon (vsftpd) and use it
instead of the FTP daemon
(in.ftpd) that is shipped with
Solaris.

This issue will be addressed
in a future StorNext release.

This issue will be addressed
in a future StorNext release.

Known Issues 26

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Operating
System

CR
Number

SR
Number Description Workaround (if applicable)

Windows 24034 n/a Windows has different limitations

regarding maximum allowable path
names. The limitations depend upon
whether you are using the NTFS API
or the WIN32 API.

The WIN32 API has a maximum path
name length of 260 characters,
including all path characters (for

example, c:\,) and the path’s NUL

termination character. The NTFS API
allows 32,000 characters.

There isn't an easy work­around for this problem.

The path name in the

command del \\?\<drive

letter>:\<directory>\...\
<filename> must not be

longer than 260 characters.

However, applications can
use this path-naming syntax
to access files with path
names longer than 260
characters. That is, an
application can use the syntax

\\?\<drive letter>:\ <directory>
\...\<filename> on Windows

APIs to access paths longer
than 260 characters.

Windows has additional
restrictions on file names. For
more information, contact
Microsoft.

24174 n/a Issues may arise due to the way

Windows handles Posix-compliant
file names.

NTFS and Posix subsystems allow
trailing periods and spaces in file
names, whereas WIN32 subsystem
does not. (MS-DOS support allows
only 8.3 format.)

Even though StorNext supplies the
unicode file names with a space on
the end, when StorNext is called by
Windows to delete the file, the file
name supplied does not have the
space on the end. For this reason file
names with spaces or periods as the
last character cannot be deleted using
Windows Explorer.

A partial workaround for this
problem is to use the MS­DOS shell instead of
Windows Explorer as
follows:

del \\?\<drive
letter>:\<directory>\...\<filena
me>

This format directs the del

command to use the NTFS
interface instead of the
WIN32 interface.

This will not work on file
names that contain the
following Windows reserved
characters:

* ? \ < > " : |

In addition, you will not be
able to delete a directory with
a name that ends with a
period or a space.

Known Issues 27

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Operating
System

CR
Number

SR
Number Description Workaround (if applicable)

Windows 15032 n/a If you are using Promise RAID

controllers on a Windows Server 2008
64-bit system, you must install
Promise’s PerfectPath software.

If you do not install this software, you
will be unable to use your Windows
Server 2008 system.

Promise is working on a
solution to this problem, but
in the meantime they have
provided the following
workaround:

1. Install the PerfectPath
software on your Windows
Server 2008 64-bit system.

2. Restart your system. The
login prompt will not
appear after you restart.
Instead, the Windows Boot
Manager screen appears
showing an error message:
“Windows cannot verify
the digital signature for
this file”

(\Windows\system32\DRIV

ERS\ perfectpathdsm.sys)

3. From the Windows Boot
Manager screen, press
Enter to continue. A
second Windows Boot
Manager screen appears,

asking you to choose an
operating system or
specify an advanced
option.

4. On the second Windows
Boot Manager screen,
press F8 to specify
advanced options. The
Advanced Boot Options
screen appears.

5. On the Advanced Boot
Options screen, use the
arrow keys to choose the
option Disable Driver
Signature Enforcement.
Choosing this option will
cause the system to display
the login prompt normally
after you reboot.

6. Restart your system.

Known Issues 28

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Operating
System

CR
Number

SR
Number Description Workaround (if applicable)

All 24852 813172 Setting the buffer cache above 256MB

can result in fragmentation. The

mount option for buffercachecap

should not exceed 256MB.

25551 892030 When running the command cvcp -

xyz, some of the files copied do not

have the mtime updated on the
resulting new files.

StorNext Storage Manager Known Issues

Table 12 lists known issues that are specific to StorNext Storage Manager.

0

This issue will be addressed
in a future StorNext release.

In the meantime, make sure
the mount option for

buffercachecap does not

exceed 256MB.

This issue will be addressed
in a future StorNext release.

A workaround is to set the
environment variable

CV_BULK_SIZE=0. This

stops cvcp from using bulk
create, and the files are
created serially.

Table 12 StorNext Storage
Manager Known Issues

Operating
System

CR
Number

SR
Number

Linux 26608 927346,

912890

Description Workaround (if applicable)

Under heavy load, MSM

processes including CiReply and
LibSched may hang, preventing

tape movement and causing
Storage Manager to lock up.

This issue will be addressed in a
future StorNext release.

In the meantime, use the
following workaround:

Reduce MSM logging by
applying the following settings to

/usr/adic/MSM/logs/log_params:

SL_SYSLOG_FACILITY=1;
SL_SYSLOG_OPTIONS=p;
SL_SYSLOG_MASK=e;
SL_PRODUCT_NAME=snmsm;
SL_TAC_MASK=NNNNNNNNNN;
SL_TRACE_MASK=NNNNNNNNNN;
SL_HISTORY_MASK=NNNNNNNNNN;
SL_PERF_MASK=N;
SL_DTRACE_MASK=NNNNNNNNNN;

Known Issues 29

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Operating
System

CR
Number

SR
Number Description Workaround (if applicable)

Linux 24649 n/a StorNext Storage Manager in a

High Availability configuration
could encounter a problem
reserving tape drives following a
failover. A “target reset” is used
by the newly activated metadata
controller to release “scsi reserve”
device reservations made by the
former metadata controller. The
target reset operation might fail
due to device driver problems on
systems running SUSE Linux
Enterprise Server 10 with tape
drives attached via an LSI fibre
host bus adapter. Any such
reserved drives will not be
accessible by the new metadata
controller.

There are two possible
workarounds, which also apply
to versions of StorNext prior to

3.1.2.

1) Following a failover, release
any tape drive reservations held
by the former metadata
controller. This must be done for
each tape drive still reserved by
the former metadata controller by
running

/usr/adic/TSM/util/fs_scsi

on the metadata controller which
owns the reservation:

# /usr/adic/TSM/util/fs_scsi
Choice==> 10 (list drives)
Choice==> 1 (select drive, e.g. /dev/

sg0)
Choice==> 3 (select Test Ready)
Choice==> 24 (select Release)
Choice==> 0 (select Quit to exit

fs_scsi)

OR

2) Add the following setting to
the

/usr/adic/TSM/config/
fs_sysparm_override
FS_SCSI_RESERVE=none;.

file:

(“none” means don't try to
reserve tape drives.) StorNext
must be restarted for this change
to take effect.

WARNING: This workaround
could leave tape drives exposed
to unexpected access by other
systems, which could lead to data
loss.

Known Issues 30

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Operating
System

CR
Number

SR
Number Description Workaround (if applicable)

Linux 24565 n/a Tapes in drives shared between

systems may unexpectedly
rewind if one or more of those
systems are running RedHat
Enterprise Linux 4 (RHEL4). If the
drives are in use by another
system (which could be running
ANY operating system) when the
rewind occurs, data loss could
occur.

The problem is caused by the
presence of rewind-on-close tape
devices named
example,

/dev/stN (for

/dev/st0). The

workaround provided in the
column to the right eliminates
these devices.

This condition’s cause is
described in Product Alert 16.
(The workaround also appears in
this alert.) StorNext Storage
Manager 3.1.2 and later checks
that this workaround has been
implemented whenever it is
started on a RedHat 4 platform.

Make sure kudzu is disabled by
running the command chkconfig

kudzu off. Use the command
chkconfig --list kudzu to verify that

kudzu is off.

Modify the /etc/udev files used

during system boot as described
below. CAUTION: This
modification is best initially
performed/tested on a non­production system, because an error
could cause a system to not boot.

1) Save the original files:

# cp /etc/udev/rules.d/50-udev.rules /etc/
udev/rules.d/50-udev.rules.bak

# cp /etc/udev/permissions.d/50­udev.permission s /etc/udev/permissions.d/
50-udev.permissions.bak

2) Modify (edit) /etc/udev/rules.d/50­udev.rules to add the following:

KERNEL=”st[0-9]*", BUS=”scsi”,
NAME=”xst%n”

3) Modify (edit) /etc/udev/permissions.d/
50-udev.permissions to change this:

st*:root:disk:0660

to look like this: xst*:root:disk:0660

For additional protection from
undesired access on the local
system, Quantum recommends
changing the 0660 above to 0000.

4) If possible, test. After a reboot,
most system configurations will not

have any files named /dev/st[0-9]*.
Those files should be named /dev/
xst[0-9]* with the permissions

specified above.

5) If any applications use the /dev/st
device files, either the applications
must be modified to use the new /
dev/xst device file names, or the

required device files must be

returned to their original names. /etc/
rc.d/rc.local might be a good choice for

making the latter change, if desired.

CAUTION: Files in /etc/udev may be

overwritten during an upgrade of
RHEL4 to a newer update, in which
case this modification will need to
be applied again.

Known Issues 31

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Operating
System

CR
Number

SR
Number Description Workaround (if applicable)

All 12321 n/a Removing affinities does not

unconfigure them from managed
file systems.

25501 n/a End of Tape/Medium not

detected

25506 n/a End of tape or medium not

correctly detected.

25766 870012,

886856

MSM failed to start with “glibc
double free or corruption”

25837 836242 Running fsmedcopy fails if the

output medium does not have
sufficient space to hold the copies
from the input.

However, the copies successfully
transferred to the new media can

be identified with the fsfileinfo

command.

This issue will be addressed in a
future StorNext release.

This issue will be addressed in a
future StorNext release.

This issue will be addressed in a
future StorNext release.

This issue will be addressed in a
future StorNext release.

The workaround is to remove
outstanding MSM requests stored
in the Request table.

This issue will be addressed in a
future StorNext release.

As a workaround, a few

fsmedcopy runs will get all the

files from the larger input media
to the new (smaller) media.

26279 945058 Running the following SQL query

does not product the desired
results:

SELECT * FROM FILECOMP%s
WHERE file_key=? AND version=?
AND (mediandx,medgen) NOT IN
(SELECT DISTINCT
mediandx,mediagen FROM
OLDMEDIA)

This issue will be addressed in a
future StorNext release.

Known Issues 32

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

StorNext Installation Known Issues

Table 13 StorNext Installation
Known Issues

Operating
System

Linux

CR
Number

24692 n/a When you mount a CD in a Red
(RHEL4 and
RHEL5 only)

Table 13 lists known issues that are specific to the StorNext installation process.

0

SR
Number

Description Workaround (if applicable)

Remount the CD by typing mount

Hat 4 or 5 system, CDs are
mounted by default with a noexec
(non-executable) option which
prevents you from proceeding

with the StorNext installation.

-o remount, exec ...

Alternatively, mount the CD to a
different directory by typing the
following:

# mkdir /mnt/MOUNT_PATH
# mount /dev/cdrom /mnt/

MOUNT_PATH # cd /mnt/
MOUNT_PATH

Known Issues 33

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Operating Guidelines and Limitations 0

Table 14 lists updated information and guidelines for running StorNext, as well as

known limitations in this release.

Table 14 StorNext Operating
Guidelines and Limitations

Operating System / Affected
Component

Windows When a StorNext file system is mounted to a drive letter or a directory,

Description

configure the Windows backup utility to NOT include the StorNext
file system.

If you are using the StorNext client software with Windows Server
2003, Windows Server 2008, Windows XP, or Windows Vista, turn off
the Recycle Bin in the StorNext file systems mapped on the Windows
machine.

You must disable the Recycle Bin for the drive on which a StorNext file
system is mounted. Also, each occurrence of file system remapping
(unmounting/mounting) will require disabling the Recycle Bin. For
example, if you mount a file system on E: (and disable the Recycle Bin
for that drive) and then remap the file system to F:, you must then
disable the Recycle Bin on the F: drive.

As of release 3.5, StorNext supports mounting file systems to a
directory. For Windows Server 2003 and Windows XP you must
disable the Recycle Bin for the root drive letter of the directory-

mounted file system. (For example: For C:\MOUNT\File_System you

would disable the Recycle Bin for the C: drive.) For Windows Server
2008 and Windows Vista you must disable each directory-mounted file
system.

For Windows Server 2003 or Windows XP:

1 On the Windows client machine, right-click the Recycle Bin icon

on the desktop and then click Properties.

2 Click Global.
3 Click Configure drives independently.
4 Click the Local Disk tab that corresponds to the mapped or

directory-mounted file system.

5 Click the checkbox Do not move files to the Recycle Bin. Remove

files immediately when deleted

.

6 Click Apply, and then click OK.

Operating Guidelines and Limitations 34

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Operating System / Affected
Component Description

Windows For Windows Server 2008 and Windows Vista:

1 On the Windows client machine, right-click the Recycle Bin icon

on the desktop and then click Properties.

2 Click the General tab.
3 Select the mapped drive that corresponds to the StorNext mapped

file system. For directory-mounted file systems, select the file
system from the list.

4 Choose the option Do not move files to the Recycle Bin. Remove

files immediately when deleted
5 Click Apply.
6 Repeat steps 3-5 for each remaining directory-mounted file system.
7 When finished, click OK.

.

All Be aware of the following limitations regarding file systems and stripe

groups:

• The maximum number of disks per file system is 512

• The maximum number of disks per data stripe group is 128

• The maximum number of stripe groups per file system is 256

• The maximum number of tape drives is 256

For managed file systems only, the maximum directory capacity is
50,000 files per single directory. (This limitation does not apply to
unmanaged file systems.)

If you use an SDisk or DDisk, you should save at least one other copy
of the data to tape or to another SDisk or Ddisk. Without the second
copy, your stored data will be vulnerable to data loss if you ever have
hardware failure.

Documentation 0

The following documents are currently available for StorNext products:

Document Number Document Title

6-01658-05 StorNext User’s Guide

6-00360-14 StorNext Installation Guide

6-01376-09 StorNext File System Tuning Guide

6-01620-08 StorNext Upgrade Guide

Documentation 35

StorNext 3.1.3 Release Notes

Document 6-00431-23 Rev A

January 2009

Document Number Document Title

6-01688-05 StorNext CLI Reference Guide

6-00361-27 StorNext File System Quick Reference

Guide

6-00361-28 StorNext Storage Manager Quick

Reference Guide

Contacting Quantum 0

More information about this product is available on the Quantum Service and
Support website at
Service and Support website contains a collection of information, including
answers to frequently asked questions (FAQs). You can also access software,
firmware, and drivers through this site.

www.quantum.com/ServiceandSupport. The Quantum

To request a software upgrade, visit www.quantum.com/ServiceandSupport/

Upgrade/Index.aspx. For further assistance, or if training is desired, contact

Quantum Global Services:

North America

UK, France, and Germany

EMEA

World Wide Web

[phone]

00800 4 QUANTUM

[phone]

www.quantum.com/ServiceandSupport

Contacting Quantum 36