Damaged virtual volume details

Use this page to view details about a damaged virtual volume in the IBM® TS7700.

The following information is presented in a table about the damaged virtual volume and should assist in selecting a cluster for a repair action if data is to be retained. The information is presented for each cluster.

Cluster

The cluster name.

Last Modified

Date and time the virtual volume was last modified.

Last Mounted

Date and time the virtual volume was last mounted.

Data Exists

Possible values are:

Exists

The cluster has the consistent (?) data in the cache or tape.

Does not exist

The cluster does not have the consistent date in the cache or tape or cloud.

Data exists in the cloud

The cluster does not have the consistent data in the cache but it's available in the cloud.

-

The cluster is not online so we can't check if the data exists or not.

Size/MiBs

Size of data on the virtual volume in mibibytes.

Note: Refer to the topic Data storage values in the Related Information section for additional information concerning the use of binary prefixes.

Category

Category attribute of the virtual volume. This is used to denote a grouping a virtual volumes.

Media Type

Media type of the virtual volume.

Ownership Takeover Time

Date the last time an ownership takeover occurred for this virtual volume.

Data Level

Every time the virtual volume is written to, this value will increase. Inserted virtual volumes start with a data level of 100. This is a secondary factor to Insert Level when choosing a cluster for the repair policy.

Insert Level

When a group of virtual volumes are inserted, they are assigned an insert level. Later inserts are given a higher insert level. This is the most important factor when choosing a cluster in the repair policy if data is going to be retained. A higher value means higher consistency for the virtual volume's data.

Data Consistent

If the cluster's virtual volume copy's data level is considered the latest data level, then data is consistent.