Browse Prior Art Database

Quick/Read Only Flash Copy

IP.com Disclosure Number: IPCOM000030622D
Original Publication Date: 2004-Aug-20
Included in the Prior Art Database: 2004-Aug-20
Document File: 4 page(s) / 68K

Publishing Venue

IBM

Abstract

Reducing the number of operations required when performing a write to the original dataset for a flash copy by internally swapping the original and copy datasets. An additional advantage is that the mapping can be restarted using the original dataset since it is preserved whilst the flash copy is active.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 41% of the total text.

Page 1 of 4

Quick/Read Only Flash Copy

Disclosed is a system for improving performance of a flash copy operation. The major benefits of this disclosure are the ability to

    1) retain the data set at the point that a FlashCopy was taken so that a new FlashCopy can be taken;

2) minimise the cost of IO to the original data set after this point.

    Before describing the invention a brief outline of flash copy is given. This details the basic read and write operations whilst the flash copy is active.

    The equivalent operations are then described for a system that implements the invention described in this disclosure.

Prior Art:

    Flash copy mappings typically consist of original and copy data sets. The copy acts as an instant (flash) image of the original. This is usually done by dividing the data sets into contiguous areas of data (grains), each grain having a bit in a bitmap associated with it. The bit indicates whether the grains worth of data on the original data set has been written to the copy data set. If it has, the grain can be said to be split.

    If the grain is split, the client IO is dealt with in the normal way, i.e. writes to the original data set -- just do the write reads to the original data set -- just do the read writes to the copy data set -- just do the write reads to the copy data set -- just do the read

    If the grain is not split, the client IO is dealt with thus:- full or partial grain writes to the original data set -- read the original data set, write the copy data set, write the original data set and mark the grain as split (3 operations) reads to the original data set -- read the original data set (1 operation) partial grain writes to the copy data set -- read the original data set, merge the data, write the copy data set and mark the grain as split (2 operations) full grain writes to the copy data set - write the copy data set and mark the grain as split reads to copy data set -- redirect the read to the original data set (1 operation)

For more details of flash copy see (GB8-2002-0334).

The problem

    There is an overhead associated with maintaining the flash copy mapping. Where a large proportion of the source data set is changing this overhead is significant.

    An example of this would be a database tracking the current share prices. These share prices will be changing throughout the day and would be stored in the source data set. If the client wanted to perform a calculation on a snapshot of the data base they would start a flash copy mapping and perform the calculation on the copy data set. They may then choose to save the copy (e.g. daily closing prices) or throw away the snapshot once the calculation has been performed.

    In the situation described above, this invention reduces the overhead by 50% As shown in Figure 1 before the flashcopy is started, the client's original data set (ODS) is mapped to the physical location physical data set 1 (PDS1). Physical data set 2 (PDS2) is unused.

Page 2 of 4

Original Data Set

(ODS)

Unused Da...