Difference between DISK and FILE device classes and their performance during various TSM operations

Any type of storage devices which you want to use in IBM Tivoli Storage Manager (TSM) server storage, it should be first defined as a DEVICE CLASS. This device class specifies a device type and media management information, such as recording format, estimated capacity, and labeling prefixes. IBM TSM supports many types of device classes where DISK (Random Access) and FILE (Sequential Access) play major role in any kind of TSM environment. 

The DISK device class is preconfigured in Tivoli Storage Manager and you don't have to define it again, you should only configure disk volumes and storage pools with the default DISK device class. Whereas to define FILE device class TSM allows you to create sequential volumes by creating files on disk storage. To the server, these files have the characteristics of a tape volume. 
DISK vs FILE device classes
The advantage of private FILE volumes is that they can reduce disk fragmentation and maintenance overhead. In this post we will see their characteristics and some of the advantages and disadvantages of using DISK & FILE device classes in different kinds of TSM server functions and processes.

Performance of DISK and FILE device class on different TSM functions

Storage space allocation
The data in DISK device class is stored and tracked in the form of disk blocks and in FILE device class data is stored and tracked in the form of volumes. DISK needs more database storage space and more processing power compared to FILE device class. However, both the device class volumes can be concurrently accessed by different operations. DISK volumes are restricted to the defined location whereas FILE volumes can be specified in multiple directories.

Single & Multi-session Restores
DISK allows only one session per restore whereas FILE allows multiple concurrent sessions accessing different volumes simultaneously on both the server and the storage agent.

Also Read: TSM Server Performance Tuning Parameters

LANFree Backup operations
DISK device class cannot be used for LANFree backup operations where backup sent through Storage Area Network connection. FILE device class can be used for LANFree backup by using another TSM product called Tivoli SANenergy. 

Defining volumes
TSM administrators has to define all the DISK volumes by using DEFINE VOLUME command with the specified size to be used, or can also define space triggers which automatically allocates space when required. Whereas for FILE device class TSM server will automatically define new scratch volumes if the MAXSCRATCH parameter is set to greater than zero while defining FILE storage pools.

DISK Caching
Only available in DISK device classes but extra processing time is needed to delete the cached space. Using cache in DISK storage pools will increase client restore performance with some limitations on TSM server processing.

Also Read: TSM Storage Pool Concepts (V7 Revised)

Copy & Active-data storage pools
Disk device class cannot be used for defining copy and active-data storage pools whereas FILE device class can be used for both the types of storage pools.

Migration
On DISK storage pools, migration is done according to the client node data stored. Whereas on FILE storage pools, migration is performed according to volumes. Files are not migrated from a volume until all files on the volume have met the threshold for migration delay as specified for the storage pool. Multiple migration process can be started for both DISK and FILE storage pools.

Also Read: 6 types of device classes which are supported by IBM TSM

Backup Storage-pool
For DISK device class, storage pool backup is performed by node and filespace. Every storage pool backup operation must check every file in the primary pool to determine whether the file must be backed up. For FILE device classes, storage pool backup is performed by volume and scanning of every object in a primary pool volume is not required every time the pool is backed up to a copy storage pool.

Copying Active data
For DISK device class, copying of active client data is performed by node and filespace. Every storage pool copy operation must check every file in the primary pool to determine whether the file must be copied. Whereas for FILE device classes, copying active data is performed by volume. For a primary pool, there is no need to scan every object in the primary pool every time the active data in the pool is copied to an active-data pool.

Also Read: How TSM Server determines the eligibility of files during different types of backup ?

Collocation
If collocation is enabled on DISK storage pools, the time for migration process can be reduced to half because migration sends data according to nodes which is already sorted out by enabling collocation. Whereas for FILE storage pools no much difference in processing times will be observed by enabling or disabling collocation. Enabling collocation will improve client restore performance but uses more tapes volumes if tapes are used.

Deduplication
Deduplication can only be enabled on FILE storage pools. You cannot use DISK or TAPE storage pools for any type of TSM data deduplication. 

REUSEDELAY
You cannot set reuse delay parameter for DISK storage pools. REUSEDELAY parameter can be used for FILE storage pool volumes to retain volumes in a pending state. Volumes are not rewritten until the specified number of days have elapsed. Very important parameter if you are taking TSM DB backup to a FILE volumes. During database restoration, if the data is physically present, it can be accessed after DSMSERV RESTORE DB.

Also Read: 11 tips to increase restore performance

Shredding
DISK storage pools supports shredding whereas FILE storage pools don't. If shredding is enabled on DISK storage pools , sensitive data is destroyed after it is deleted from a storage pool. Write caching on a random access devices should be disabled if shredding is enforced. 

0 Comment to "Difference between DISK and FILE device classes and their performance during various TSM operations"

Post a Comment