EMC DiskXtender File System Manager for UNIX/Linux Release 3.5

(1)

EMC Corporation Corporate Headquarters: Hopkinton, MA 01748

-

9103 1

-

508

-

435

-

1000

File System Manager for UNIX/Linux

Release 3.5

Administrator’s Guide

(2)

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

(3)

Tables...7

Preface...9

Chapter 1 Introduction File system-based storage management ... 14

Files always available to applications...14

Data management... 14 Console-based administration ... 16 Console Client ... 16 Flexible topology... 17 Minimum topology ... 17 Complex topology ... 17 Topology guidelines... 18

Chapter 2 Console overview Console software... 20

Console Server... 20

Console Agent ... 20

Console Client ... 21

Management domain ... 22

Single computer domain...22

Multiple computer domain ...23

Console Client ... 24

How to start Console Client ...24

Administration ... 26

How to add a user ... 26

(4)

Monitoring ... 30

Clearing the events window ... 30

Domain events ... 31

Domain activities ... 32

Host events ... 34

File system events... 35

File system activities ... 37

File system state ... 38

Chapter 3 File System Configuration Preliminary tasks ... 44

Back-end module types ... 44

Centera module preliminary tasks ... 45

FTP module preliminary tasks ... 52

NFS module preliminary tasks... 54

Configuring a file system ... 57

Overriding configuration for file system subsets ... 57

How to configure a file system... 57

Centera module ... 64

FTP module ... 67

NFS module... 68

Viewing a file system configuration ... 70

Editing a file system configuration ... 71

Deleting a file system configuration ... 72

Chapter 4 Extended Rules Creating an extended rule ... 74

Match string... 74

How to create an extended rule ... 80

Viewing extended rules ... 86

Editing an extended rule ... 87

How to edit an extended rule ... 87

Deleting an extended rule ... 88

How to delete an extended rule ... 88

Copying extended rules... 89

How to copy extended rules ... 89

(5)

Prune job... 95

Creating a scheduled job ... 96

How to create a scheduled job ...96

Viewing a scheduled job ...98

Editing a schedule... 99

Deleting a schedule... 100

Time elements... 102

Create a new time element ...102

Editing a time element ...107

Deleting a time element ...107

Chapter 6 Advanced UTDM Mount Options EMC Centera data retention ... 110

Performance impact...110

Requirements... 111

Enabling EMC Centera data retention ...111

Setting retention for a file system ...113

Setting retention for a group of files ...114

Restoring incremental backups...115

Read-only ... 117

Mounting read-only... 118

Direct-read... 120

Memory-mapping... 120

Mounting direct-read ...121

Chapter 7 Backup and Recovery What to back up... 124

FSM-related files outside of UTDM file systems...124

Files and data in UTDM file systems ...125

Backup software ... 126

FSM-aware backup software...127

Other backup software...127

Snapshot software... 127

Recovering a lost file system ... 128

Recovering an FTP module file system... 130

How to recover an FTP module file system ...130

EMC NetWorker... 132

Requirements... 132

(6)

Requirements ... 136

Backup... 137

Recovery ... 137

NetBackup software ... 139

NetBackup requirements... 139

Backup with NetBackup software ... 141

Recovery with NetBackup software ... 142

FSM tools... 143

Backup with FSM tools ... 143

Recovery with FSM tools... 144

Snapshots with SnapView... 147

Quiescing a UTDM file system... 147

Resuming UTDM file system activity ... 149

Recovering a UTDM file system snapshot... 149

Import data from SM to FSM ... 151

Chapter 8 Maintenance Processes ... 156

Core processes... 156

Console processes... 162

File administration... 164

Manual migration, purge, and retrieval... 164

Periodic back-end system cleanup ... 167

EMC Centera ... 168

Cleanup on FTP or NFS module back-end systems ... 170

Appendix A Command reference Command quick reference ... 174

Command usage ... 177

Setting the DMAP_ROOT_PATH ... 177

Setting the FSM environment ... 177

Administrative commands... 178

File management commands ... 191

Backup and recovery commands ... 196

(7)

Title Page

1 Tasks permitted for operators and administrators ... 27

2 Columns on the Events for All Hosts window ... 32

3 Columns on the All FSM Activities window ... 33

4 Columns on the Events windows ... 35

5 Columns on the Events windows ... 36

6 Columns on the Activities window ... 38

7 File System State window ... 39

8 Purge tab on the File System State window ... 40

9 Migrate tab on the File System State window... 40

10 Staging tab on the File System State window ... 40

11 Destroy tab on the File System State window... 41

12 Recover tab on the File System State window ... 41

13 Available back-end module types ... 45

14 Choices for the Authentication Type field... 53

15 Determining path of back-end mount point when using Solaris zones.. 55

16 Determining full path when using Solaris zones ... 58

17 Checksum setting choices ... 59

18 Retention Period settings ... 64

19 Descriptions of Collision Avoidance settings ... 66

20 Possible Keyword values in match string expressions ... 75

21 Possible Operator values in match string expressions ... 75

22 Possible Variable values in match string expressions... 77

23 Possible Filesize-Units values in match string expressions ... 78

24 Operator precedence in a match string ... 78

25 Descriptions of Checksum settings... 83

26 Descriptions of Retention Period settings... 84

27 Scheduled job comparison ... 92

28 Components of a schedule ... 93

29 Effect of a scheduled job on file system settings... 94

(8)

31 Components of a time element ... 102

32 Recurrence options ... 103

33 Mounting with EMC Centera data retention ... 112

34 Mounting read-only... 118

35 Mounting direct-read ... 122

36 Supported backup software ... 126

37 FSM recovery commands... 144

38 Mounting a file system for utdm_recdmattrf ... 150

39 Administrative commands ... 174

40 File management commands... 175

41 Backup and restore commands... 175

42 Options for deldmsession ... 179

43 Options for dx_read_log ... 180

44 Severity levels ... 181

45 Brevity levels... 182

46 Options for dxuldmclip... 183

47 Options for dxuldmdelclips ... 185

48 Options for expand_dmattrf... 186

49 Options for getdmattr... 188

50 Options for getfileattr ... 188

51 Options for dxstat ... 189

52 Options for dxprstat ... 189

53 Options for dxhardlink... 190

54 Options for getmiglist... 191

55 Options for getmiglist... 192

56 getmiglist file list columns ... 193

57 Options for getpurgelist ... 194

58 getpurgelist file list columns headings ... 195

59 Options for dxbuildtar ... 197

60 Options for dxcliplink ... 198

61 Options for dxdmload ... 199

62 Options for dxuldm_tar ... 200

63 Options for dmattrrecoverfs... 201

64 Options for getrecoverlist ... 202

65 getrecoverlist file list columns... 202

(9)

As part of an effort to improve and enhance the performance and capabilities of its product lines, EMC periodically releases revisions of its hardware and software. Therefore, some functions described in this document may not be supported by all versions of the software or hardware currently in use. For the most up-to-date information on product features, refer to your product release notes.

If a product does not function properly or does not function as described in this document, please contact your EMC representative.

Audience This guide is part of the EMC DiskXtender File System Manager for UNIX/Linux, release 3.5 documentation set, and is intended for use by system administrators.

Readers of this guide are expected to be familiar with the following topics:

◆ Their organization’s data archiving strategy, in particular: • Average archived file size.

• Anticipated total number of files and total bytes to be archived.

• File access norms: frequency of access during creation, edit, and archive phases.

(10)

◆ The network details of all computer systems and hardware devices to be used, including:

• IP addresses

• TCP/IP routing information

• Switch, router, firewall, and network-attached device configurations

◆ The administration details of all involved storage targets. Related

Documentation

!

(11)

Typographical conventions

EMC uses the following type style conventions in this document: Normal Used in running (nonprocedural) text for:

• Names of interface elements (such as names of windows, dialog boxes, buttons, fields, and menus)

• Names of resources, attributes, pools, Boolean expressions, buttons, DQL statements, keywords, clauses, environment variables, functions, utilities

• URLs, pathnames, filenames, directory names, computer names, filenames, links, groups, service keys, file systems, notifications

Bold Used in running (nonprocedural) text for:

• Names of commands, daemons, options, programs, processes, services, applications, utilities, kernels, notifications, system calls, man pages

Used in procedures for:

• Names of interface elements (such as names of windows, dialog boxes, buttons, fields, and menus)

• What user specifically selects, clicks, presses, or types

Italic Used in all text (including procedures) for: • Full titles of publications referenced in text • Emphasis (for example a new term) • Variables

Courier Used for:

• System output, such as an error message or script • URLs, complete paths, filenames, prompts, and syntax when

shown outside of running text Courier bold Used for:

• Specific user input (such as commands) Courier italic Used in procedures for:

• Variables on command line • User input variables

< > Angle brackets enclose parameter or variable values supplied by the user

[ ] Square brackets enclose optional values

| Vertical bar indicates alternate selections - the bar means “or” { } Braces indicate content that you must specify (that is, x or y or z) ... Ellipses indicate nonessential information omitted from the

(12)

Where to get help EMC support, product, and licensing information can be obtained as follows.

Product information —For documentation, release notes, software updates, or for information about EMC products, licensing, and service, go to the EMC Powerlink website (registration required) at:

http://Powerlink.EMC.com

Technical support —For technical support, go to EMC Customer Service on Powerlink. To open a service request through Powerlink, you must have a valid support agreement. Please contact your EMC sales representative for details about obtaining a valid support agreement or to answer any questions about your account. Your comments Your suggestions will help us continue to improve the accuracy,

organization, and overall quality of the user publications. Please send your opinion of this document to:

(13)

This chapter covers the following topics:

◆ File system-based storage management ... 14

◆ Console-based administration ... 16

◆ Flexible topology... 17

(14)

File system-based storage management

EMC®DiskXtender®File System Manager for UNIX/Linux (FSM), release 3.5 is a data management solution that uses DMAPI-enabled (UTDM) file systems to transparently archive data on the following back-end storage systems:

◆ EMC Centera®Content Addressed Storage System (EMC Centera)

◆ Locally accessible disk resources

FSM transparently manages multiple local UTDM file systems. When necessary, it migrates and purges data from the file systems based on user-defined rules.

FSM frees up space by transferring the actual data associated with a file system object to a back-end system, while retaining the object’s metadata in the file system. This means that a migrated and purged file is fully available through the file system, but uses very little of the file system’s space.

Files always available to applications

When an application starts a read or write operation on data that has been migrated and purged, FSM invisibly triggers a retrieval of that data. The data is returned to the file system and the operation is completed. The user is not required to initiate operations to import or export data. Data written to an FSM file system is fully available for all read and write operations without user intervention.

Access to migrated and purged data is the same as access to locally stored data, except for the possibility of a slight delay during the retrieval of data that has been purged from the file system.

Information that can be provided from the file’s metadata, or from data contained in the locally retained stub file, is available without triggering a retrieval from the back-end system. This enables many queries to be completed at local disk speed, even for large files which have been migrated and purged.

(15)

◆ Interact with the file system.

◆ Manage extended file attribute information.

(16)

Console-based administration

FSM provides a console-style administrative tool to perform most administrative tasks. The tool, the FSM Console, permits the administration of multiple UTDM file systems, UTDM file system hosts, and management domains. A management domain is a logical grouping of UTDM file system hosts controlled by the same FSM Console Server.

Console Client FSM Console Client can be run on any supported host to administer a management domain, as long as it has TCP/IP access to the following management domain components:

◆ Console Server

◆ All UTDM file system hosts

Console Client can be run simultaneously on multiple hosts. You can use Console Client to perform tasks in the following categories:

◆ Administration

◆ Configuration

◆ Extended Rules

(17)

Flexible topology

FSM can be set up with many different combinations of hosts, file systems, protocols, and back-end systems.

An FSM host is a computer where:

◆ Core processes are installed and running.

◆ Console Agent is installed and running.

◆ At least one UTDM file system is available.

Minimum topology A minimal FSM installation involves the following:

◆ FSM host with Console Server installed and running.

◆ One UTDM file system.

◆ One back-end system.

Complex topology A complex management domain might involve all of the following:

◆ One FSM host with Console Server installed and running.

◆ Multiple FSM hosts, including all of the supported operating systems.

◆ Multiple UTDM file systems on each FSM host, including all supported file system types.

◆ Multiple back-end systems, including EMC Centeras, and locally accessible disk resources.

◆ Additional EMC Centeras that act as replication servers.

(18)

Topology guidelines To successfully set up a management domain, the following guidelines must be met:

◆ Only one Console Server may run in the management domain.

◆ All FSM hosts must have Console Agent installed and running.

◆ All FSM hosts must have TCP/IP communication with the Console Server host system.

(19)

(20)

Console software

The Console software provides the interface to work with FSM hosts and UTDM file systems. An administrator can perform the following tasks by using the Console software:

◆ Configure new UTDM file systems.

◆ Edit the configuration of existing UTDM file systems.

◆ Delete the configuration information for existing UTDM file systems.

◆ Copy rule sets between UTDM file systems.

◆ Import and export rule sets.

◆ Create and manage extended rules.

The Console software consists of the following applications:

◆ Console Server

◆ Console Agent

◆ Console Client

Console Server Console Server provides authentication services to a management domain. All FSM hosts in a management domain are controlled by the same Console Server.

Console Server must be installed on only one computer in a

management domain. That computer must have TCP/IP access to all FSM hosts in its domain. Normally the computer on which it is installed also has Console Agent installed.

The computer on which Console Server is installed may also have Console Client installed.

(21)

Console Client Console Client may be installed on any computer with TCP/IP access to the management domain. It provides an administrative interface to the management domain.

Console Client may be active on several computers simultaneously and should be installed on every computer that is used to administer file systems.

(22)

Management domain

A management domain can exist entirely on a single computer or it can include multiple computers. A management domain consists of the following essential components:

◆ One Console Server.

◆ At least one Console Client.

◆ At least one FSM host.

Each FSM host must have the following:

• One set of FSM core processes (core processes) • One FSM Console Agent (Console Agent) • At least one UTDM file system

A UTDM file system is one that is first formatted as a native file system and then initialized to create a DMAPI attributes file in its root directory. The installation guides provide more information about this.

Single computer domain

The following tasks must be completed to set up a management domain on a single computer:

1. Ensure the computer meets the installation requirements. 2. Install the core processes.

3. Install the Console Server. 4. Install a Console Agent. 5. Install the Console Client.

(23)

Multiple computer domain

A management domain can consist of many computers. All of the computers in the management domain must have TCP/IP communication with the following:

◆ Computer that is running Console Server

◆ Each computer that is running Console Client.

A multiple computer management domain might consist of the following separate computers:

◆ Console Server running on a single FSM host computer.

◆ Console Agent running on multiple FSM host computers.

(24)

Console Client

Console Client is an interface application for working with FSM hosts and UTDM file systems. An encrypted username/password

combination (account) is used to authenticate Console Client users and determine permissions.

A default administrative account is provided with Console Client. This default account has the username "system" and the password "system". To increase the security of the management domain, the password for this account should be changed right after the software is installed.“How to change a user's password” on page 29provides information about how to do this.

You can install Console Client on several supported operating systems. The release notes provide a complete list of the operating systems supported by Console Client.

How to start Console Client

To start Console Client:

◆ On UNIX and Linux hosts: 1. Allow X window connections:

xhost +

2. Set the DISPLAY environment variable. setenv DISPLAY local_host:0.0

where local_host is the hostname of the local system or its IP address.

Whether you use the local system’s hostname or its IP address depends upon the configuration of the network. The IP address can be either an IPv4 or IPv6 format IP address to match the protocol used by your network.

3. Run the Console Client application:

/opt/fsm/client/File_System_Manager_Console_Client & where /opt/fsm is the full path to the FSM installation directory. The Login to FSM Console window appears.

(25)

6. In FSM Server, type the hostname or IP address for the management domain’s Console Server.

You can use either an IPv4 or IPv6 format IP address to match the protocol used by your network.

7. Click OK.

The main Console Client window appears.

◆ On Windows: 1. Click:

Start> Programs > File System Manager Console Client > File System Manager Console Client

The Login to FSM Console window appears. 2. In Username, type a valid username.

3. In Password, type the password.

4. In FSM Server, type the hostname or IP address for the management domain’s Console Server.

You can use either an IPv4 or IPv6 format IP address to match the protocol used by your network.

5. Click OK.

The main Console Client window appears.

Security time-out Console Client is configured to close down its connection with Console Server after 20 minutes of inactivity. This security feature cannot be configured.

Online help The online help provides convenient descriptions of Console Client’s menus, shortcuts, windows, and wizards.

To access the online help from the main Console Client window, on the Help menu, click Contents and Index (or press F1).

(26)

Administration

You can use the Console Client Administration menu to manage all user accounts in a management domain. The specific management domain is determined by the name of the Console Server host entered during login.

Use the Administration menu to manage user accounts through the following commands:

◆ Manage User Accounts

◆ Change User Password CAUTION

!

The Console Client application installs with a default account that has the username "system" and the password "system". The role of this default account is Administrator.

This account cannot be deleted. To maintain the security of the management domain, change the default password for the "system" as soon as the software is installed.“How to change a user's password” on page 29provides more information.

How to add a user To add a user:

1. On the Administration menu, select Manage User Accounts. 2. In Username, type the new username.

A valid username is five to eight characters with at least one alphabetic character. A new username cannot match the following:

• Any other username in the management domain. • The password of the currently logged-in user. 3. In Password, type the new password.

A valid password is five to eight characters with at least one alphabetic character. It cannot match the password of the current logged-in user.

(27)

5. In Role, select a role for the new user account.

Choose either Operator or Administrator. Refer toTable 1 on page 27to view the functions available for each role.

6. Click Add. 7. Click OK.

Note:Use Clear on the Manage User Accounts window to clear the following fields: Username, Password, and Confirm Password.

Table 1 Tasks permitted for operators and administrators

Task Operator Administrator

View all activities Yes Yes

View all events Yes Yes

Monitor file system Yes Yes

View file system configuration Yes Yes

View file system events Yes Yes

Change own password Yes Yes

View Help Yes Yes

View About Yes Yes

Manage user accounts No Yes

Create new file system configuration No Yes Edit file system configuration No Yes

Export rule set No Yes

Import rule set No Yes

Commit changes No Yes

Delete file system configuration No Yes

(28)

How to remove a user

To remove a user account:

1. On the Administration menu, select Manage User Accounts. The Manage User Accounts window appears.

2. From the Username list, select the username of the account to be removed.

Note:The "system" account cannot be removed. Delete is not available when this account is selected.

3. Click Delete.

The Delete User prompt appears. 4. Click Yes.

The account is removed. 5. Click OK.

How to change your password

To change your password:

1. On the Administration menu, select Change User Password. The Change Password window appears.

2. In Password, type your new password.

(29)

How to change a user's password

An administrator may change a user's password:

1. On the Administration menu, select Manage User Accounts. The Manage User Accounts window appears.

2. From the Username list, select a username. 3. In Password, type the new password.

4. In Confirm Password, type the new password. 5. Click Update.

(30)

Monitoring

To view events, activities, and status in a management domain, use the monitoring windows.

The following regions may be monitored:

◆ Domain Events

◆ Domain Activities

◆ Host Events

◆ File System Events

◆ File System Activities

◆ File System State

Note:Events and state information for file systems on an FSM host are cleared when that FSM host is restarted. Restarting an FSM host also clears that host’s events from the Events for All Hosts window.

Clearing the events window

An administrator can clear all events, or select events to clear from any of the Events windows.

All Events

To clear all events, click Clear All Events.

All events clear, including events that are not displayed under the currently selected event type.

Select Events

To clear a group of events:

1. In the Filter field, select an event type to display. 2. Select each event to be cleared.

(31)

Domain events The events for all file systems in a management domain may be viewed. The displayed events do not include the following:

◆ Events that were cleared.

◆ Events that occurred before the host computer was last restarted. How to view domain events

To display the events for a management domain: 1. On the View menu, select All Events.

The Events for All Hosts window appears.

2. (Optional) On the View menu, select Refresh to refresh the display.

The Last Refreshed value changes and the Events for All Hosts window updates.

3. (Optional) In the Filter field, select a severity level to display a subset of the events.

The following severity levels may be selected: • All • None • Low • Medium • High • Extreme

The filtered events appear.

(32)

Domain activities The activities for all file systems in a management domain may be viewed.

To display all activities in a management domain: 1. On the View menu, select All Activities.

The All FSM Activities window appears at the top of the workspace pane.

2. In the Filter field, select the type of activities to display. The activities are filtered to show only the type of activities selected.

Table 2 Columns on the Events for All Hosts window Column Description

Host Name of the host on which the event occurred. File System Name of the file system that generated the event. Severity Severity level of the event.

Severity is one of the following: • None

• Low • Medium • High • Extreme

Timestamp Date and time that the event occurred. Event Type Type of event.

(33)

The following activities types may be selected: • All • Purge • Migrate • Staging • Destroy • Recover

The filtered domain activities appear.

Table 3 on page 33provides a description of the columns on the All FSM Activitieswindow.

Table 3 Columns on the All FSM Activities window Column Description

Host Name of the host for the activity. File System Name of the file system for the activity. File System ID File system ID for the activity. Backend Level Priority of the back-end system.

Either Level 1 (primary) or Level 2 (secondary). Backend Type Back-end module type, which is one of the following:

• Centera • FTP • NFS

Activity Type Activity type, which is one of the following: • Purge

• Migrate • Stage • Destroy • Recover

Filename Name of the file that is the subject of the activity.

(34)

Host events The events for an individual host may be viewed. The displayed events do not include the following:

◆ Events that occurred before the host computer was last restarted. How to view events for a host

To display all events for a host: 1. On the tree pane, select the host. 2. On the View menu, select Events.

The Events window appears.

The Last Refreshed value changes and the Events window updates.

The events are filtered to show only the selected severity level. The following severity levels may be selected:

• All • None • Low • Medium • High • Extreme

The filtered events appear.

(35)

File system events The events for an individual file system may be viewed. The displayed events do not include the following:

◆ Events that occurred before the host computer was last restarted. How to view events for a file system

To display all events for a file system: 1. On the tree pane, select the file system. 2. On the View menu, select Events.

The Events window appears at the top of the workspace pane.

Table 4 Columns on the Events windows Column Description Host Name of the host.

File System Name of the file system that generated the event. Severity Severity level of the event.

• Low • Medium • High • Extreme

Timestamp The date and time that the event occurred. Event Type Type of event.

(36)

The Last Refreshed value changes and the Events window updates.

The events are filtered to show only the severity level selected. The following severity levels may be selected:

• All • None • Low • Medium • High • Extreme

The filtered events appear.Table 5 on page 36provides a description of the columns on the Events window.

Table 5 Columns on the Events windows (page 1 of 2) Column Description

Host Name of the host.

File System Name of the file system that generated the event. Severity Severity level of the event.

(37)

File system activities You can use Console Client to view the activities for a file system. To display all activities for a file system:

1. On the tree pane, select the file system. 2. On the View menu, select Monitoring.

The Activities window appears at the bottom of the workspace pane.

3. In the Filter field, select the type of activities to display. The activities are filtered to show only the type of activities selected.

The following activities types may be selected: • All • Purge • Migrate • Staging • Destroy • Recover

The filtered activities appear.Table 6 on page 38provides a description of the columns on the Activities window. Timestamp Date and time that the event occurred.

Event Type Type of event.

Event type is one of the following: • Debug • Info • Notice • Warning • Error • Critical • Alert • Emergency Message Description of the event.

(38)

File system state You can use Console Client to view information about the state of a managed file system.

To display the state of a file system: 1. On the tree pane, select the file system. 2. On the View menu, select Monitoring.

The File System State window appears at the top of the workspace pane. General state information appears on the left side of the window.Table 7 on page 39provides a description of the available information.

Table 6 Columns on the Activities window Column Description

Activity Type Type of activity. Type is one of the following: • Purge

• Migrate • Stage • Destroy • Recover

Backend Level Priority of the back-end system.

Either Level 1 (primary) or Level 2 (secondary). Backend Type Back-end module type, which is one of the following:

• Centera • FTP • NFS

Filename Name of the file that is the subject of the activity.

(39)

3. (Optional) From the View menu, select Refresh to refresh the display.

The Last Refreshed value changes, and the File System State window and the Activities window update.

4. On the File System State window, select a tab to display information for a specific activity type.

The following tabs are available:

• Purge, described inTable 8 on page 40. • Migrate, described inTable 9 on page 40. • Staging, described inTable 10 on page 40. • Destroy, described inTable 11 on page 41. • Recover, described inTable 12 on page 41.

Table 7 File System State window Field Name Description

File System Name Name of the file system. File System ID File system ID.

Module Module type for the file system.

File System Path Full path to the mount point for the file system. Total Size Total size of the file system.

Used Space Number of megabytes of data in the file system. High Watermark Value set for the file system's high-water mark. Used Space

(graphical display)

Graphical display showing the percentage of file system space used.

Maximum Inodes Total number of inodes allowed in the file system. Used Inodes Total number of file system inodes used. Used Inodes

(graphical display)

(40)

Table 8 Purge tab on the File System State window Field Description

Purge Attempts Number of attempts to purge files from the file system. Purge Errors Number of errors during all of the file system's purge attempts. Purge Attempts on

Purged Files

Number of purge attempts on previously purged files.

Bytes Purged Since Last Reboot

Total bytes purged since the last time the file system's host was started.

Table 9 Migrate tab on the File System State window Field Description

Migration Attempts

Number of attempts to migrate files from the file system.

Migration Errors Number of errors during all of the file system's migration attempts. Migration

Attempts on Migrated Files

Number of migration attempts on previously migrated files.

Bytes Migrated Since Last Reboot

Total bytes migrated since the last time the file system's host was started.

Table 10 Staging tab on the File System State window Field Description

Staging Attempts Number of attempts to stage files into the file system.

Staging Errors Number of errors during all of the file system's staging attempts. Staging Attempts

on Staged Files

Number of staging attempts on previously staged files.

Bytes Staged Since Last Reboot

(41)

Table 11 Destroy tab on the File System State window Field Description

Files Destroyed Total number of files reclassified on the back-end system as destroyed, after being deleted from the file system.

Files Not Renamed

Total number of files that could not be renamed on the back-end system.

“Periodic back-end system cleanup” on page 167provides more information about renaming deleted files on the back-end system.

Table 12 Recover tab on the File System State window Field Description

Recovery Attempts

Number of attempts to recover file data from the back-end system, after a recovery from backup is completed in the file system.

(42)

(43)

This chapter covers the following topics:

◆ Preliminary tasks... 44

◆ Configuring a file system... 57

◆ Viewing a file system configuration... 70

◆ Editing a file system configuration... 71

◆ Deleting a file system configuration ... 72

(44)

Preliminary tasks

A UTDM file system’s configuration is a set of attributes that defines how it is managed. Each file system has its own set of required and optional attributes.

Console Client simplifies file system configuration tasks by displaying all relevant attributes, checking all entered values, and applying configuration changes to the file system.

Before you can configure a file system, you must complete the following:

◆ Create a native file system, initialize the file system for UTDM, and mount the file system on an FSM host.

These tasks are described in the installation guides.

◆ Decide on a Level 1 back-end type and optionally, a Level 2 back-end type to use with the file system.

◆ Perform any preliminary setup steps required for each selected back-end system.

Back-end module types

This release allows you to designate either one or two back-end systems for a file system. When two back-end systems are selected, migrated file data is written to both. Data is retrieved from the Level 1 (primary) back-end system unless it is unavailable. If the Level 1 back-end system is unavailable, then data is retrieved from the Level 2 (secondary) back-end system.

The steps required to configure a file system differ slightly based on which back-end type is selected as primary and, optionally, which is selected as secondary.

(45)

A mixture of back-end module types can be used for a file system, for the file systems on a host, and for all file systems in a management domain.

Each back-end module type has preliminary tasks that must be completed before you configure a file system to use it. Those tasks are described in the following sections:

◆ “Centera module preliminary tasks” on page 45

◆ “FTP module preliminary tasks” on page 52

◆ “NFS module preliminary tasks” on page 54

Centera module preliminary tasks

The Centera module requires the following preliminary tasks:

◆ Ensure that the FSM host can establish a connection with the EMC Centera’s interface addresses. If replication is used, also confirm that there is a connection with the replication server’s interface addresses.

◆ Create a EMC Centera pool to use with FSM file systems.

◆ Configure the EMC Centera to grant the appropriate permissions to FSM. If replication is used, also configure the replication server.

◆ If Pool Entry Authorization (PEA) is used, create and install a valid PEA file on the FSM host. If replication is used, create a PEA file that authenticates FSM with both the primary EMC Centera and the replication server.

◆ Enable EMC Centera data retention.

Table 13 Available back-end module types Back-end module types Description

Centera EMC Centera

FTP Standards-compliant FTP or FTPS servera

NFS Standards-compliant NFS accessible disk resources

(46)

Check connectivity FSM uses TCP/IP to communicate with EMC Centeras. Before configuring a UTDM file system to use a EMC Centera, and optionally a EMC Centera replication server, confirm that there is a connection between the FSM host and the IP addresses of the EMC Centeras.

EMC Centeras do not respond to ping packets. A tool to confirm that there is a connection with a EMC Centera is provided with the FSM software.

To confirm connectivity:

1. Log in as root on the FSM host system. 2. Set the FSM environment.

To set the environment, refer to“Setting the FSM environment” on page 177.

3. For each EMC Centera IP address, run the dxuldmcenteraping command:

dxuldmcenteraping -a emc-address [emc-address...] where emc-address is an IP address for a network interface on the EMC Centera, in IPv4 format. Additional IP addresses, separated by spaces, may be specified.

For more information about this command, see

“dxuldmcenteraping” on page 182.

Failure to connect to the IP addresses for a EMC Centera indicates a network problem that should be corrected before the file system is configured.

Create a EMC Centera pool for FSM

FSM file systems can use the default EMC Centera pool but it is recommended that you create a pool that is used only by FSM file systems. An FSM-only pool simplifies EMC Centera to EMC Centera migrations, such as when you move the back-end data to a newer generation EMC Centera.

Configure EMC Centera permissions

FSM requires read, write, and query permissions on a EMC Centera. This set of permissions can be provided in one of the following ways:

(47)

Use of the Anonymous profile eliminates the PEA file requirement. However, the Anonymous profile constitutes a potential security hazard since it does not authenticate applications during the PEA process. It should be disabled.

◆ Use the PEA process to create an application profile for FSM that grants the necessary permissions.

For more information on this choice, see the next section:“Create and install a PEA file” on page 47.

Create and install a PEA file

The PEA process is used by a EMC Centera to grant access rights to applications. The specific access rights that are granted are

determined by application profiles created on the EMC Centera. The application profile that is used by FSM must have the following access rights:

◆ Read (r)

◆ Write (w)

◆ Exist (e)

In order to be authorized to use an application profile, FSM must provide the EMC Centera with the profile’s name and key. FSM reads the information from a PEA file located on the FSM host and passes it to the EMC Centera during the PEA process.

To create and install a PEA file:

1. On the EMC Centera, create an application profile that grants Read, Write, and Exist rights.

Application profiles are created by using the EMC Centera’s CLI commands profile create or profile update.

In order to have the profile create or profile update commands output a PEA file, type yes when asked if a Pool Entry

Authorization should be created.

For more information about application profile creation, refer to the EMC Centera’s documentation.

2. Copy the resultant PEA file from the CLI host to the FSM host. 3. As root, limit access to the PEA file:

chmod 600 _/path/my.pea

(48)

4. For each file system that uses the Centera module, type the full path of the PEA file in the Authentication Path option.

Authentication Pathis described in“Centera module” on page 64.

Verify PEA access

To verify that a PEA file can be used to access a EMC Centera: 1. Log in as root on the host system.

2. Set the FSM environment.

For information on setting the FSM environment, see“Setting the FSM environment” on page 177.

3. Run dxuldmcenteraping:

dxuldmcenteraping -a centeraIP?pathtopea where:

• centeraIP is one of the IP addresses on the EMC Centera, in IPv4 format.

• pathtopea is the full path to the PEA file.

Note:This command verifies that the PEA file may be used to access the EMC Centera. It does not check whether the correct permissions are provided by the PEA file.

For more information about dxuldmcenteraping, see

“dxuldmcenteraping” on page 182.

Centera pool entry authorization for replication

The PEA process may be used with Centera replication as a way to authenticate FSM on both the primary and replication EMC Centeras. The PEA file used in a replication environment must provide

authentication information for each of the EMC Centeras. The composition of a PEA file used in a replication environment depends on whether you provide the path to a random-bit file when you run the profile create or profile update commands. The

random-bit file can be used as additional input during key generation.

The following methods may be used:

(49)

The same file must be used on each EMC Centera. This method creates a PEA file with a single key that is accepted on each EMC Centera.

◆ Generate the key without providing a random-bit file.

A different key is created on each EMC Centera based on various machine-based values. Each key must be copied into the PEA file. This creates a PEA file with several keys, one for each EMC Centera.

Replication PEA file created with a random-bit file

To use a replication PEA file created with a random-bit file: 1. On the primary EMC Centera, create an application profile by

using a random-bit file.

The application profile must grant Read, Write, and Exist rights. In order to have the profile create or profile update commands output a PEA file, type yes when asked if a Pool Entry

For more information about application profile creation, refer to the EMC Centera’s documentation.

2. On each replication system, create an application profile by using the same random-bit file.

The application profile on each replication system should use the same name as the one on the primary system. The profile should, at a minimum, grant Read and Exist rights.

3. Copy the PEA file created with the primary system from the CLI host to the FSM host.

4. As root, limit access to the PEA file: chmod 600 /path/my.pea

where /path/my.pea is the full path of the PEA file.

5. For each file system that uses the Centera module, type the full path of the PEA file in the Authentication Path option.

This is described in“Configuring a file system” on page 57. 6. For each file system that uses the Centera module, type the IP

(50)

7. Verify access using the PEA file.

This task is described in“Verify PEA access” on page 48. Replication PEA file created without the use of a random-bit file To use a replication PEA file created without the use of a random-bit file:

1. On the primary EMC Centera, create an application profile without using a random-bit file.

The application profile must grant Read, Write, and Exist rights. In order to have the profile create or profile update commands output a PEA file, type yes when asked if a Pool Entry

The EMC Centera’s documentation provides more information about application profile creation.

2. On each replication system, create an application profile without using a random-bit file.

The application profile on each replication system should use the same name as the one on the primary system. The profile should, at a minimum, grant Read and Exist rights.

3. Copy the key portion of the PEA file created with each replication system into the PEA file created with the primary system, as shown inExample 1 on page 50.

Example 1 Replication environment PEA file created without a random-bit file The primary EMC Centera PEA file without the key from a replication server looks like this:

<pea version="1.0.0"> <defaultkey name="FSM1"> <credential id="csp1.secret" enc="base64">TXlQYXNzd29yZA==</credential> </defaultkey> <key type="cluster" id="74cf2446-1dd2-11b2-bee7-9e82e41faa5c" name="FSM1"> <credential id="csp1.secret" enc="base64">TXlQYXNzd29yZA==</credential> </key> </pea>

(51)

<pea version="1.0.0"> <defaultkey name="FSM1"> <credential id="csp1.secret" enc="base64">TXlQYXNzd29yZA==</credential> </defaultkey> <key type="cluster" id="74cf2446-1dd2-11b2-bee7-9e82e41faa5c" name="FSM1"> <credential id="csp1.secret" enc="base64">TXlQYXNzd29yZA==</credential> </key> <key type="cluster" id="d76d509c-1dd1-11b2-b10d-bd6b5ed0b4e6" name="FSM1"> <credential id="csp1.secret" enc="base64

">YqgqywOqJ9nsKC7uQFeztUyFcM</credential> </key>

</pea>

4. Copy the resulting PEA file from the CLI host to the FSM host. 5. As root, limit access to the PEA file:

chmod 600 /path/my.pea

where /path/my.pea is the full path of the PEA file.

6. For each file system that uses the Centera module, type the full path of the PEA file in the Authentication Path option.

This is described in“Configuring a file system” on page 57. 7. For each file system that uses the Centera module, type the IP

address, in IPv4 format, for each available interface on each replication server in the Replication Server Addresses option. This is described in“Configuring a file system” on page 57. 8. Verify access using the PEA file.

This task is described in“Verify PEA access” on page 48. Enable EMC Centera data retention

Retention of data from a UTDM file system that is migrated to a EMC Centera is enabled by using the Retention Period or the Retention Class settings. However, unless EMC Centera data retention is enabled for the file system, these retention settings do not protect data in the file system.

(52)

FTP module preliminary tasks

Use of the FTP module requires the following preliminary tasks:

◆ Ensure that the FSM host can establish a connection to the back-end server:

• FTP server (FTP Protocol set to Native FTP) • FTPS server (FTP Protocol set to Native FTP)

◆ Create a username/password combination on the back-end server for the file system.

◆ Obtain the full path to the target directory.

◆ Ensure that the file system host can obtain local disk-like access to the back-end server.

Check connectivity Connectivity between the FSM host and the back-end server can be confirmed by using ping. Use the ping command with the same interface address or hostname that you will use in FTP Host. To confirm connectivity:

1. Log in as root on the FSM host system. 2. Run ping:

ping backendIP

where backendIP is the value to be used in FTP Host. This is normally the IP address of the back-end server, in either IPv4 or IPv6 as dictated by the network. Alternatively, if the back-end server’s hostname is to be used, replace backendIP with the hostname in the above command.

Failure to connect to the IP address indicates a network problem that should be corrected before the file system is configured. Failure to connect to the hostname usually indicates a name service problem. FTP username and password

FSM authenticates itself with the back-end server by using a

(53)

A single username/password combination can be used by all UTDM file systems, or individual combinations can be used by each FSM host or each UTDM file system.

Target Path Before configuring a file system, determine the full path of the directory on the back-end server that is to be the top-level migration target. Enter this path as the Target Path value for the file system. The Target Pathvalue is described in“FTP module” on page 67.

The path is in UNIX format and is relative to the root of the FTP server.

Another commonly used target path naming convention is

/FSM/file_system, where:

◆ / is the root of the FTP directory structure on the FTP server.

◆ file_system is the name of the file system.

Choose an authentication type

This release provides a choice between a standard FTP connection or a secure FTP connection for native FTP servers.

IMPORTANT

!

The FTP module supports only active mode. When deciding on an authentication type be aware that using an encrypted control channel can prevent a firewall from opening a port for the data channel.

Table 14provides information about these choices.

To successfully use either TLS or SSL the back-end server must provide a public key certificate.

Table 14 Choices for the Authentication Type field

Authentication Type Control channel encrypted Data channel encrypted Cryptographic protocol

None No No None

TLS Yes No Transport layer security

(54)

Local disk-like access

Local disk-like access is normally established by using the NFS protocol but other protocols are allowed, as long as the directory specified in the target path can be mounted locally by the FSM host.

NFS module preliminary tasks

Use of the NFS module requires the following preliminary tasks:

◆ Determine the mount point of the back-end system.

◆ Create an NFS check directory on the back-end system.

Back-end mount point The module can be used with a disk resource that acts as a back-end system, such as any of the following:

◆ Local secondary disk

◆ Network Attached Storage (NAS) disk

◆ Storage Area Network (SAN) disk

When the NFS module is used, determine the full path to the local mount point of the back-end system. Enter this path as the Target Pathvalue for the file system. Configuring a file system’s Target Path value is described in“NFS module” on page 68.

◆ To mount a disk resource as a back-end system, refer to the instructions provided with the hardware.

Once the back-end system is mounted, the mount point can easily be determined by using mount.

To determine the mount point:

1. Log in as root on the FSM host system.

2. On the command line, type mount without any options: mount

All mounted file systems are listed, with their mount point. Determining back-end mount point when using Solaris zones For Solaris zones the expression of the full path to the mount point of the back-end system depends upon the zone in which FSM is

installed and the zone in which the back-end system is mounted.

(55)

Create an NFS check directory

The NFS check directory is an empty subdirectory at the top level of the back-end mount point. The NFS check directory must be named UTDMNFS, and be all uppercase. No specific permissions are required for the check directory.

FSM uses the NFS check directory to ensure that the exported directory is properly mounted on the FSM Host. The NFS check directory can be seen by FSM only when the exported directory is properly mounted on the FSM host. FSM will not migrate files until it sees the NFS check directory.

Note:Although a disk resource back-end system may not use the NFS protocol, the core processes will not migrate data unless the NFS check directory is found at the top level of the mount point.

To create an NFS check directory:

1. Log in as root on the FSM host system.

2. To ensure the back-end system is mounted, type mount without any options:

mount

If the back-end system is not listed as one of the mounted file systems, then do the following:

• For a disk resource back-end system, mount the resource as described in the instructions provided with the hardware.

Table 15 Determining path of back-end mount point when using Solaris zones

Configuration Path

• FSM installed in global zone • Back-end system is mounted in

global zone

Use the global zone full path of the mount point.

• FSM installed in global zone • Back-end system is mounted in local

zone

Use global representation of the local mount point.

Example: Local zone is mounted at /export/zone01 and the back-end system’s local mount point is /mnt/backend01, then the full path to the mount point is

/export/zone01/mnt/backend01. • FSM installed in local zone

• Back-end system is mounted in same local zone

Use local representation of the local mount point.

(56)

3. Change the current working directory to the top level of the back-end system.

(57)

Configuring a file system

Configuring a file system is the final step in the process of preparing to manage a UTDM file system.

With this release you can configure a Level 1 and a Level 2 back-end system. When you configure both, migrated data is written to both. The Level 1 back-end system is the file system’s primary back-end system. Data is always retrieved from the Level 1 back-end system unless that back-end system is unavailable to the file system. If the Level 1 back-end system is unavailable, then data is retrieved from the Level 2 back-end system.

When you configure two back-end systems for a file system you can select from any of the module types for each. Normally you should configure the back-end type that stages data fastest as the Level 1 back-end system.

Overriding configuration for file system subsets

When you configure a file system you create settings that tell FSM how to manage the files in that file system. You can override those settings for subsets of the files using extended rules.“Extended Rules” on page 73provides information about:

◆ Defining a file system subset

◆ Creating an extended rule

◆ Working with extended rules

How to configure a file system

Configuring a file system:

1. Create, initialize, and mount a UTDM file system. The installation guides describe these procedures.

2. Start Console Client and log in to the management domain that controls the file system’s FSM host.

(58)

4. Select File > New > File System Configuration.

5. Select the Level 1 (primary) back-end type from the following choices: Centera, FTP, or NFS.

6. (Optional) Check the Level 2 box.

7. (Optional) Select the Level 2 (secondary) back-end type. 8. Click OK.

9. In File System Name, type a reference name for the file system. The name may be any combination of ASCII characters, from 1 to 64 characters in length. The name cannot match the name of any other file system on the host.

10. In File System Path, type the path for the UTDM file system. Use the full path to the UTDM file system's mount point. For Solaris zones the expression of a file system’s full path depends upon the zone in which FSM is installed and the zone of the file system.Table 16 on page 58describes how to determine the full path when using Solaris zones.

Table 16 Determining full path when using Solaris zones

Configuration Path

• FSM installed in global zone • File system installed in global zone

Use the global zone full path of the file system.

• FSM installed in global zone • File system installed in local zone

Use global representation of the local file system's path.

Example: Local zone is mounted at /export/zone01 and the file system's local path is /mnt/filesystem01, then the path required is /export/zone01/mnt/filesystem01. • FSM installed in local zone

• File system installed in same local zone

Use local representation of the file system's path.

(59)

11. In Checksum, select a checksum setting as described inTable 17 on page 59.

When the value of Checksum is changed to either Checksum During Migrationor Checksum During Migration and Staging, a checksum is not calculated for files that were migrated while the value of Checksum was No Checksumming. Checksums are calculated only for files that are migrated after the change. Note:Checksumming is disabled for back-end systems that use the Centera module and have Enable Multiple Streams Per File Stage selected.

12. Click Next.

13. (Optional) In Delay Until Purge Candidacy, set the number of minutes after a migrated file is last accessed before it can be purged.

The range is 1 to 2,147,483,647 minutes. The default is 10 minutes. 14. (Optional) In Minimum File Size to Purge, set the minimum size

a file must be before it can be purged.

The range is 0 to 2,147,483,647 bytes (2 GB). The default is 0. 15. (Optional) In Sleep Interval Until Next Purge, set the number of

minutes, after a system-initiated purge run completes, before the file system is again checked for files that can be purged.

Table 17 Checksum setting choices

Choice Description

No checksumming Checksums will not be generated.

Use this setting to decrease the CPU requirements caused by data movement. This is the default setting because of its lower CPU requirements.

Checksum during migration Checksum is generated for each file as it is migrated.

This is the recommended setting. It creates a checksum for each migrated file without the additional CPU impact caused by creating a checksum during staging.

Checksum during migration and staging Checksum is generated for each file as it is migrated. The checksum is regenerated and compared to the original as the file is staged.

Use this setting if increased CPU impact is not an issue, if file integrity is critical, or to troubleshoot migration and staging problems.

(60)

The range is 1 to 5,256,000 minutes. The default is 10 minutes. Note:When the sleep interval elapses, the file system is checked against its high-water mark. If the high-water mark is met or exceeded, a purge eligibility check is conducted.

16. (Optional) In Concurrent Files Purged, set the number of purge threads that can be started.

The range is 1 to 128 files. The default is 1.

Note:When the maximum number of threads is reached, files are queued until a thread becomes free.

17. (Optional) In File Stub Size, set the number of kilobytes of a file that are left in the file system when the file is purged.

The range is 0 to 131,072 KB (128 MB). The default is 0. Note:The data is measured in kilobytes from the head of the file. 18. (Optional) In High Watermark, set the percent of file system

capacity that is reached before automatic purging is started. The range is 1 to 100 percent, but must be higher than the value of low-water mark. The default is 90 percent.

19. (Optional) In Low Watermark, set the percent of file system capacity that is reached before automatic purging is stopped. The range is 1 to 100 percent, and must be less than the high-water mark. The default is 80 percent.

20. In the File Time Purge Policy section, select either Purge on Last Modification Timeor Purge on Last Access Time.

This setting determines the starting point for the Delay Until Purge Candidacyperiod:

• Purge on Last Modification Time starts the period after the last modification of a file.

• Purge on Last Access Time starts the period after the last time the file was accessed.

(61)

22. (Optional) In Delay Until Migrate Candidacy, set the number of minutes after a file is last modified before it can be migrated. The range is 1 to 2,147,483,647 minutes. The default is 30 minutes. 23. (Optional) In Minimum File Size to Migrate, set the minimum

number of bytes a file must be before it can be migrated. The range is 0 to 2,147,483,647 bytes (2 GB). The default is 0. 24. (Optional) In Sleep Interval Until Next Migration, set the

number of minutes after a system-initiated migration run completes before the file system is again checked for files to migrate.

The range is 1 to 5,256,000 minutes. The default is 30 minutes. 25. (Optional) In Concurrent Files Migrated, set the number of

migration threads that can be started. The range is 1 to 128 files. The default is 8.

26. (Optional) Set the Purge After Migrate:

• Select to enable immediate purging of migrated files.

• Clear it to enable purging only after the number of minutes set in Delay Until Purge Candidacy.

27. (Optional) Select Enable Data Compression and set a data compression level.

When you enable this setting file system data is compressed before it is migrated.

The compression level range is 0 to 9. Level 1 gives the fastest throughput, level 9 gives the greatest compression, and level 0 gives no compression at all (the input data is simply copied a block at a time).

Level 6 represents a good compromise between speed and compression.

(62)

Note:Selecting Enable Data Compression prevents the use of the staging settings: Partial Read Size and Full File Staging.

28. In the File Time Migration Policy section, select either Migrate on Last Modification Timeor Migrate on Last Access Time. This setting determines the starting point for the Delay Until Migrate Candidacyperiod:

• Migrate on Last Modification Time starts the period after the last modification of a file.

• Migrate on Last Access Time starts the period after the last time the file was accessed.

29. Click Next.

30. (Optional) Clear Full File Staging, to set a partial read size. The default is full file staging, which means that all data for a file is returned to the file system when the file is staged.

Full File Stagingis disabled if Enable Data Compression is selected in the migration settings.

31. (Optional) In Partial Read Size, set the size in megabytes of file data chunks to return to the file system when a file is staged. Partial Read Sizeis disabled if Enable Data Compression is selected in the migration settings, or if Full File Staging is selected on the staging settings.

The Checksum during Migration and Staging setting is overridden when Partial Read Size is enabled. A checksum is calculated only on files when they are migrated because partial staging prevents checksum calculations during staging.

The range is 1 to 2048 MB (2 GB). The range of data staged spans the offset of the data requested.

Data is retrieved in chunks from the highest "partial read size boundary" immediately before the requested data to the lowest "partial read size boundary" immediately after the requested data.

(63)

Example 2 Partial read size

A file is 1,073,741,824 bytes (1 GB). The file system’s Partial Read Size is set to 2,097,152 bytes (2 MB). The data requested is 4 MB in size and is located at offset 104,857,601 bytes (1 byte past the 100 MB block boundary).

The data staged is the data from offset 104,857,600 bytes (100 MB is the highest "partial read size boundary" immediately before the requested data) to 111,149,056 bytes (106 MB is the lowest "partial read size boundary" immediately after the requested data). Note: Partial Read Sizedoes not apply when the FTP module is used with the Native FTP protocol.

32. (Optional) In Concurrent Files Staged, set the number of staging threads that can be started.

33. Click Next.

34. (Optional) In Concurrent Files Destroyed, set the number of threads that can be started to flag back-end data as deleted, for files that have been deleted from the file system.

Deletion flags are described in“Periodic back-end system cleanup” on page 167.

35. Click Next.