Organization of multiple snapshot copies in a data storage system

• US 6,934,822 B2
• Filed: 08/06/2002
• Issued: 08/23/2005
• Est. Priority Date: 08/06/2002
• Status: Active Grant

• Current Assignee: Emc IP Holding Company LLC (Dell Technologies Inc.)
• Original Assignee: EMC Corporation (Dell Technologies Inc.)
• Inventors: Potnis, Ajay S., Bergant, Milena, Wang, Hongmei, Armangau, Philippe, Angelone, Raymond A.
• Primary Examiner(s): CHACE, CHRISTIAN
• Application Number:
  US10/213,242
• Publication Number:
  US 20040030727A1
• Time in Patent Office: 1,113 Days
• Field of Search: 707/10, 707201-205, 709/104, 711/161, 711/162, 711/156, 711/165, 714/6, 714/15, 714/20
• US Class Current: 711/162
• CPC Class Codes: G06F 11/1435 using file system or storage system metadata
• CPC Class Codes: G06F 11/1458 Management of the backup or restore process
• CPC Class Codes: G06F 11/1469 Backup restoration techniques
• CPC Class Codes: G06F 16/137 Hash-based content-based indexing of textual data G06F16/31
• CPC Class Codes: G06F 2201/84 Using snapshots, i.e. a logical point-in-time copy of the data
• CPC Class Codes: Y10S 707/99952 Coherency, e.g. same view to multiple users

Abstract

A file server maintains a production file system supported by a clone volume, and multiple snapshot file systems supported by respective save volumes in a snapshot queue. Before a data block is modified for the first time after creation of the youngest snapshot, the data block is copied from the clone volume to the save volume of the youngest snapshot. A bit map indicates the blocks that have already been copied, and a block map shows the save block address for each corresponding clone block address. When a new snapshot is created, the bit and block maps are converted to a hash index that is kept linked to the save volume of what had been the youngest snapshot. When other than the oldest snapshot file system is deleted, the respective save volume is retained as a hidden object until it becomes the oldest save volume.

Claims

1. A file server for providing access to a production file system and a plurality of snapshot file systems, each of the snapshot file systems being the state of the production file system at a respective point in time when said each of the snapshot file systems was created,

said file server comprising storage containing a clone volume of data blocks supporting the production file system, and the storage containing, for said each of the snapshot file systems, a respective save volume of data blocks supporting said each of the snapshot file systems,

the respective save volume of said each of the snapshot file systems containing data blocks having resided in the clone volume at the respective point in time when said each of the snapshot file systems was created,

the file server being programmed for maintaining the save volumes in a snapshot queue in a chronological order of the respective points in time when the snapshot file systems were created, the save volume supporting the oldest one of the snapshot file systems residing at the head of the snapshot queue, and the save volume supporting the youngest one of the snapshot file systems residing at the tail of the snapshot queue,

the file server being programmed for performing a read access upon the production file system by reading the clone volume,

the file server being programmed for performing a write access upon the production file system by writing to the clone volume but before modifying a block of production file system data in the clone volume, copying the block of production file system data from the clone volume to the save volume at the tail of the snapshot queue if said block of production file system data in the clone volume has not yet been modified since the respective point in time of creation of the snapshot file system supported by the save volume at the tail of the snapshot queue,

the file server being programmed for performing a read access upon a specified data block of a first specified one of the snapshot file systems by reading the save volume supporting the first specified one of the snapshot file systems if the specified data block is found in the save volume supporting the first specified one of the snapshot file systems, and if the specified data block is not found in the save volume supporting the first specified one of the file systems, searching for the specified data block in a next subsequent save volume in the snapshot queue, and if the specified data block is found in the next subsequent save volume in the snapshot queue, reading the specified data block from the next subsequent save volume in the snapshot queue, and if the specified data block is not found in any subsequent save volume in the snapshot queue, then reading the specified data block from the clone volume;

wherein the file server is programmed for deleting a second specified one of the snapshot file systems that is supported by a save volume that is not at the head of the snapshot queue by deleting the second specified one of the snapshot file systems while retaining the save volume having supported the second specified one of the snapshot file systems, the save volume having supported the second specified one of the snapshot file systems being retained until the save volume having supported the second specified one of the snapshot file systems becomes the oldest save volume in the snapshot queue.

2. The file server as claimed in claim 1, wherein the save volume having supported the second specified one of the snapshot file systems becomes the next save volume subsequent to the save volume at the head of the snapshot queue, and thereafter the save volume having supported the second specified one of the snapshot file systems is deleted by the file server in response to the deletion of the save volume at the head of the snapshot queue.

3. The file server as claimed in claim 2, wherein the file server is programmed for deleting the save volume at the head of the snapshot queue when the snapshot file system supported by the save volume at the head of the snapshot queue is deleted.

4. The file server as claimed in claim 1, wherein the file server is programmed for deleting the second specified one of the snapshot file systems in response to a request from a client that specifies the second specified one of the snapshot file systems and requests the file server to delete the second specified one of the snapshot file systems.

5. The file server as claimed in claim 1, wherein the file server is programmed for maintaining a bit map having a respective bit for each block of production file system data in the clone volume, the respective bit indicating whether or not said each block of production file system data in the clone volume has not yet been modified since the respective point in time of creation of the snapshot file system supported by the save volume at the tail of the snapshot queue, and the file server is programmed to convert the bit map to a hash index in response to creation of a new snapshot file system of the production file system.

6. The file server as claimed in claim 5, wherein the file server is programmed for keeping the hash index linked to said save volume at the tail of the snapshot queue so that the hash index is linked to said save volume at the tail of the snapshot queue after a new save volume supporting the new snapshot file system becomes the save volume at the tail of the snapshot queue.

7. The file server as claimed in claim 6, wherein the file server is programmed for using the hash index during a read access of at least one of the snapshot file systems that is created at a respective point of time before the creation of the new snapshot file system in order to determine whether or not at least one specified data block resides in the save volume to which the hash index is linked.

8. The file server as claimed in claim 7, wherein the hash index includes a mapping of clone block addresses to respective addresses of blocks in the save volume to which the hash index is linked.

9. The file server as claimed in claim 5, wherein the file server is programmed for using the hash index for locating at least one specified data block during a read access of at least one of the snapshot file systems created at a respective point of time before the creation of the new snapshot file system.

10. The file server as claimed in claim 1, wherein the snapshot queue includes a plurality of save volumes supporting a plurality of snapshot file systems of the production volume, and data blocks of the plurality of save volumes are inter-mixed in a collective snapshot volume in the storage of the file server.

11. The file server as claimed in claim 10, wherein the file server is programmed for allocating an initial extent of data blocks to the collective snapshot volume, and for allocating a number of the data blocks of the collective snapshot volume to the plurality of save volumes, and for increasing the extent of the collective snapshot volume when the number of data blocks of the collective snapshot volume allocated to the plurality of save volumes reaches a high water mark.

12. The file server as claimed in claim 11, wherein the high water mark is a predetermined fraction of the extent of the collective snapshot volume.

13. The file server as claimed in claim 1, wherein the file server is programmed for refreshing other than the oldest one of the snapshot file systems so that the content of said other than the oldest one of the snapshot file systems is changed to that of a newly-created snapshot file system without changing a file system identifier of said other than the oldest one of the snapshot file systems.

14. A file server for providing access to a production file system and a plurality of snapshot file systems, each of the snapshot file systems being the state of the production file system at a respective point in time when said each of the snapshot file systems was created,

said file server comprising storage containing a clone volume of data blocks supporting the production file system, and the storage containing, for said each of the snapshot file systems, a respective save volume of data blocks supporting said each of the snapshot file systems,

the respective save volume of said each of the snapshot file systems containing data blocks having resided in the clone volume at the respective point in time when said each of the snapshot file systems was created,

the file system being programmed for maintaining the save volumes in a snapshot queue in a chronological order of the respective points in time when the snapshot file systems were created, the save volume supporting the oldest one of the snapshot file systems residing at the head of the snapshot queue, and the save volume supporting the youngest one of the snapshot file systems residing at the tail of the snapshot queue,

the file server being programmed for performing a read access upon the production file system by reading the clone volume,

the file server being programmed for performing a write access upon the production file system by writing to the clone volume but before modifying a block of production file system data in the clone volume, copying the block of production file system data from the clone volume to the save volume at the tail of the snapshot queue if said block of production file system data in the clone volume has not yet been modified since the respective point in time of creation of the snapshot file system supported by the save volume at the tail of the snapshot queue,

the file server being programmed for performing a read access upon a specified data block of a specified one of the snapshot file systems by reading the save volume supporting the first specified one of the snapshot file systems if the specified data block is found in the save volume supporting the first specified one of the snapshot file systems, and if the specified data block is not found in the save volume supporting the first specified one of the snapshot file systems, searching for the specified data block in a next subsequent save volume in the snapshot queue, and if the specified data block is found in the next subsequent save volume in the snapshot queue, reading the specified data block from the next subsequent save volume in the snapshot queue, and if the specified data block is not found in any subsequent save volume in the snapshot queue, then reading the specified data block from the clone volume;

wherein the file server is programmed for maintaining a bit map having a respective bit for each block of production file system data in the clone volume, the respective bit indicating whether or not said each block of production file system data in the clone volume has not yet been modified since the respective point in time of creation of the snapshot file system supported by the save volume at the tail of the snapshot queue, and the file server is programmed for converting the bit map to a hash index in response to creation of a new snapshot file system of the production file system.

15. The file server as claimed in claim 14, wherein the file server is programmed to keep the hash index linked to said save volume at the tail of the snapshot queue so that the hash index is linked to said save volume at the tail of the snapshot queue after a new save volume supporting the new snapshot file system becomes the save volume at the tail of the snapshot queue.

16. The file server as claimed in claim 15, wherein the file server is programmed for using the hash index during a read access of at least one of the snapshot file systems created at a respective point of time before the creation of the new snapshot file system in order to determine whether or not at least one specified data block resides in the save volume to which the hash index is linked.

17. The file server as claimed in claim 16, wherein the hash index includes a mapping of clone block addresses to respective addresses of blocks in the save volume to which the hash index is linked.

18. The file server as claimed in claim 14, wherein the file server is programmed for using the hash index for locating at least one specified data block during a read access of at least one of the snapshot file systems created at a respective point of time before the creation of the new snapshot file system.

19. The file server as claimed in claim 14, wherein the file server is programmed for deleting at least one of the snapshot file systems that is supported by a save volume that is not at the head of the snapshot queue by deleting said at least one of the snapshot file systems while retaining the save volume having supported the second specified one of the snapshot file systems, the save volume having supported said at least one of the snapshot file systems being retained until the save volume having supported said at least one of the snapshot file systems becomes the oldest save volume in the snapshot queue.

20. The file server as claimed in claim 14, wherein the snapshot queue includes a plurality of save volumes supporting a plurality of snapshot file systems of the production volume, and data blocks of the plurality of save volumes are inter-mixed in a collective snapshot volume in the storage of the file server.

21. The file server as claimed in claim 20, wherein the file server is programmed for allocating an initial extent of data blocks to the collective snapshot volume, and for allocating a number of the data blocks of the collective snapshot volume to the plurality of save volumes, and for increasing the extent of the collective snapshot volume when the number of data blocks of the collective snapshot volume allocated to the plurality of save volumes reaches a high water mark.

22. The file server as claimed in claim 21, wherein the high water mark is a predetermined fraction of the extent of the collective snapshot volume.

23. The file server as claimed in claim 14, wherein the file server is programmed for refreshing other than the oldest one of the snapshot file systems so that the content of said other than the oldest one of the snapshot file systems is changed to that of a newly-created snapshot file system without changing a file system identifier of said other than the oldest one of the snapshot file systems.

24. A data storage system for providing access to a production data set and a plurality of snapshot data sets, each of the snapshot data sets being the state of the production data set at a respective point in time when said each of the snapshot data sets was created,

said data storage system comprising storage containing a clone volume of data blocks supporting the production data set, and the storage containing, for said each of the snapshot data sets, a respective save volume of data blocks supporting said each of the snapshot data sets,

the respective save volume of said each of the snapshot data sets containing data blocks having resided in the clone volume at the respective point in time when said each of the snapshot data sets was created,

wherein at least one of the save volumes has a respective hash index for indicating whether or not a specified data block having resided in the clone volume resides in said at least one of the save volumes, and if a specified data block having resided in the clone volume resides in said at least one of the save volumes, for indicating the block address in said at least one of the save volumes where said specified data block having resided in the clone volume resides in said at least one of the save volumes;

and

wherein the data storage system is programmed for using said respective hash index for a read access of the snapshot data set supported by said at least one of the save volumes.

25. The data storage system as claimed in claim 24, wherein the hash index includes a hash table indexed by a hashing of a clone volume block address, the hash table including hash table entries pointing to hash lists, the hash lists having hash list entries, at least some of the hash list entries each including a clone volume block address and a corresponding save volume block address.

26. The data storage system as claimed in claim 24, wherein the data storage system is programmed for maintaining the save volumes in a snapshot queue in a chronological order of the respective points in time when the snapshot data sets were created, the save volume supporting the oldest one of the snapshot data sets residing at the head of the snapshot queue, and the save volume supporting the youngest one of the snapshot data sets residing at the tail of the snapshot queue, and

the data storage system is programmed for maintaining a bit map having a respective bit for each block of production data set data in the clone volume, the respective bit indicating whether or not said each block of production data set data in the clone volume has not yet been modified since the respective point in time of creation of the snapshot data set supported by the save volume at the tail of the snapshot queue, and

the data storage system is programmed to convert the bit map to a hash index in response to creation of a new snapshot data set of the production data set.

27. The data storage system as claimed in claim 26, wherein the data storage system is programmed for linking the hash index to said save volume at the tail of the snapshot queue so that the hash index remains linked to said save volume at the tail of the snapshot queue when a new save volume supporting the new snapshot data set becomes the save volume at the tail of the snapshot queue.

28. A method of operating a file server providing access to a production file system and a plurality of snapshot file systems, each of the snapshot file systems being the state of the production file system at a respective point in time when said each of the snapshot file systems was created, the file server having storage containing a clone volume of data blocks supporting the production file system, and the storage containing, for each snapshot file system, a respective save volume of data blocks supporting said each of the snapshot file systems, the respective save volume of said each of the snapshot file systems containing data blocks having resided in the clone volume at the respective point in time when said each of the snapshot file systems was created, said method comprising:

maintaining the save volumes in a snapshot queue in a chronological order of the respective points in time when the snapshot file systems were created, the save volume supporting the oldest one of the snapshot file systems residing at the head of the snapshot queue, and the save volume supporting the youngest one of the snapshot file systems residing at the tail of the snapshot queue,

performing a read access upon the production file system by reading the clone volume,

performing a write access upon the production file system by writing to the clone volume but before modifying a block of production file system data in the clone volume, copying the block of production file system data from the clone volume to the save volume at the tail of the snapshot queue if said block of production file system data in the clone volume has not yet been modified since the respective point in time of creation of the snapshot file system supported by the save volume at the tail of the snapshot queue,

performing a read access upon a specified data block of a first specified one of the snapshot file systems by reading the save volume supporting the first specified one of the snapshot file systems if the specified data block is found in the save volume supporting the first specified one of the snapshot file systems, and if the specified data block is not found in the save volume supporting the first specified one of the snapshot file systems, searching for the specified data block in a next subsequent save volume in the snapshot queue, and if the specified data block is found in the next subsequent save volume in the snapshot queue, reading the specified data block from the next subsequent save volume in the snapshot queue, and if the specified data block is not found in any subsequent save volume in the snapshot queue, then reading the specified data block from the clone volume; and

deleting a second specified one of the snapshot file systems that is supported by a save volume that is not at the head of the snapshot queue by deleting the second specified one of the snapshot file systems while retaining the save volume having supported the second specified one of the snapshot file systems, the save volume having supported the second specified one of the snapshot file systems being retained until the save volume having supported the second specified one of the snapshot file systems becomes the oldest save volume in the snapshot queue.

29. The method as claimed in claim 28, wherein the save volume having supported the second specified one of the snapshot file systems becomes the next save volume subsequent to the save volume at the head of the snapshot queue, and thereafter the save volume having supported the second specified one of the snapshot file systems is deleted in response to the deletion of the save volume at the head of the snapshot queue.

30. The method as claimed in claim 29, which includes deleting the save volume at the head of the snapshot queue when the snapshot file system supported by the save volume at the head of the snapshot queue is deleted.

31. The method as claimed in claim 28, which includes deleting the second specified one of the snapshot file systems in response to a request from a client that specifies the second specified one of the snapshot file systems and requests the file server to delete the second specified one of the snapshot file systems.

32. The method as claimed in claim 28, which includes maintaining a bit map having a respective bit for each block of production file system data in the clone volume, the respective bit indicating whether or not said each block of production file system data in the clone volume has not yet been modified since the respective point in time of creation of the snapshot file system supported by the save volume at the tail of the snapshot queue, and

converting the bit map to a hash index in response to creation of a new snapshot file system of the production file system.

33. The method as claimed in claim 32, which includes keeping the hash index linked to said save volume at the tail of the snapshot queue so that the hash index is linked to said save volume at the tail of the snapshot queue after a new save volume supporting the new snapshot file system becomes the save volume at the tail of the snapshot queue.

34. The method as claimed in claim 33, which includes using the hash index during a read access of at least one of the snapshot file systems that was created at a respective point of time before the creation of the new snapshot file system in order to determine whether or not at least one specified data block resides in the save volume to which the hash index is linked.

35. The method as claimed in claim 34, wherein the converting of the bit map to a hash index in response to creation of a new snapshot file system of the production file system includes incorporating into the hash index a mapping of clone block addresses to respective addresses of blocks in the save volume to which the hash index is linked.

36. The method as claimed in claim 32, which includes using the hash index for locating at least one specified data block during a read access of at least one of the snapshot file systems that was created at a respective point of time before the creation of the new snapshot file system.

37. The method as claimed in claim 28, wherein the snapshot queue includes a plurality of save volumes supporting a plurality of snapshot file systems of the production volume, and the method includes inter-mixing data blocks of the plurality of save volumes in a collective snapshot volume in the storage of the file server.

38. The method as claimed in claim 37, which includes allocating an initial extent of data blocks to the collective snapshot volume, and allocating a number of the data blocks of the collective snapshot volume to the plurality of save volumes, and increasing the extent of the collective snapshot volume when the number of data blocks of the collective snapshot volume allocated to the plurality of save volumes reaches a high water mark.

39. The method as claimed in claim 38, which includes maintaining the high water mark as a predetermined fraction of the extent of the collective snapshot volume.

40. The method as claimed in claim 28, which includes refreshing other than the oldest one of the snapshot file systems so that the content of said other than the oldest one of the snapshot file systems is changed to that of a newly-created snapshot without changing a file system identifier of said other than the oldest one of the snapshot file systems.

41. A method of operating a file server providing access to a production file system and a plurality of snapshot file systems, each of the snapshot file systems being the state of the production file system at a respective point in time when said each of the snapshot file systems was created, the file server having storage containing a clone volume of data blocks supporting the production file system, and the storage containing, for each snapshot file system, a respective save volume of data blocks supporting said each of the snapshot file systems, the respective save volume of said each of the snapshot file systems containing data blocks having resided in the clone volume at the respective point in time when said each of the snapshot file systems was created, wherein said method comprises:

maintaining the save volumes in a snapshot queue in a chronological order of the respective points in time when the snapshot file systems were created, the save volume supporting the oldest one of the snapshot file systems residing at the head of the snapshot queue, and the save volume supporting the youngest one of the snapshot file systems residing at the tail of the snapshot queue,

performing a read access upon the production file system by reading the clone volume,

performing a write access upon the production file system by writing to the clone volume but before modifying a block of production file system data in the clone volume, copying the block of production file system data from the clone volume to the save volume at the tail of the snapshot queue if said block of production file system data in the clone volume has not yet been modified since the respective point in time of creation of the snapshot file system supported by the save volume at the tail of the snapshot queue,

performing a read access upon a specified data block of a specified one of the snapshot file systems by reading the save volume supporting the specified one of the snapshot file systems if the specified data block is found in the save volume supporting the specified one of the snapshot file systems, and if the specified data block is not found in the save volume supporting the specified one of the snapshot file systems, searching for the specified data block in a next subsequent save volume in the snapshot queue, and if the specified data block is found in the next subsequent save volume in the snapshot queue, reading the specified data block from the next subsequent save volume in the snapshot queue, and if the specified data block is not found in any subsequent save volume in the snapshot queue, then reading the specified data block from the clone volume; and

wherein said method includes maintaining a bit map having a respective bit for each block of production file system data in the clone volume, the respective bit indicating whether or not said each block of production file system data in the clone volume has not yet been modified since the respective point in time of creation of the snapshot file system supported by the save volume at the tail of the snapshot queue, and

converting the bit map to a hash index in response to creation of a new snapshot file system of the production file system.

42. The method as claimed in claim 41, which includes keeping the hash index linked to said save volume at the tail of the snapshot queue so that the hash index is linked to said save volume at the tail of the snapshot queue after a new save volume supporting the new snapshot file system becomes the save volume at the tail of the snapshot queue.

43. The method as claimed in claim 42, which includes using the hash index during a read access of at least one of the snapshot file systems created at a respective point of time before the creation of the new snapshot file system in order to determine whether or not at least one specified data block resides in the save volume to which the hash index is linked.

44. The method as claimed in claim 43, wherein the converting of the bit map to a hash index in response to creation of a new snapshot file system of the production file system includes incorporating into the hash index a mapping of clone block addresses to respective addresses of blocks in the save volume to which the hash index is linked.

45. The method as claimed in claim 41, which includes using the hash index for locating at least one specified data block during a read access of at least one of the snapshot file systems that was created at a respective point of time before the creation of the new snapshot file system.

46. The method as claimed in claim 41, which includes deleting at least one of the snapshot file systems that is supported by a save volume that is not at the head of the snapshot queue by deleting said at least one of the snapshot file systems while retaining the save volume having supported said at least one of the snapshot file systems, the save volume having supported said at least one of the snapshot file systems being retained until the save volume having supported said at least one of the snapshot file systems becomes the oldest save volume in the snapshot queue.

47. The method as claimed in claim 41, wherein the snapshot queue includes a plurality of save volumes supporting a plurality of snapshot file systems of the production volume, and the method further includes inter-mixing data blocks of the plurality of save volumes in a collective snapshot volume in the storage of the file server.

48. The method as claimed in claim 47, which includes allocating an initial extent of data blocks to the collective snapshot volume, and allocating a number of the data blocks of the collective snapshot volume to the plurality of save volumes, and increasing the extent of the collective snapshot volume when the number of data blocks of the collective snapshot volume allocated to the plurality of save volumes reaches a high water mark.

49. The method as claimed in claim 48, wherein the high water mark is a predetermined fraction of the extent of the collective snapshot volume.

50. The method as claimed in claim 41, which includes refreshing other than the oldest one of the snapshot file systems so that the content of said other than the oldest one of the snapshot file systems is changed to that of a newly-created snapshot without changing a file system identifier of said other than the oldest one of the snapshot file systems.

51. A method of operating a data storage system for providing access to a production data set and a plurality of snapshot data sets, each of the snapshot data sets being the state of the production data set at a respective point in time when said each of the snapshot data sets was created, the data storage system having storage containing a clone volume of data blocks supporting the production data set, and the storage containing, for said each of the snapshot data sets, a respective save volume of data blocks supporting said each of the snapshot data sets, the respective save volume of said each of the snapshot data sets containing data blocks having resided in the clone volume at the respective point in time when said each of the snapshot data sets was created, wherein said method comprises:

creating, for at least one of the save volumes, a respective hash index for indicating whether or not a specified data block having resided in the clone volume resides in said at least one of the save volumes, and if a specified data block having resided in the clone volume resides in said at least one of the save volumes, for indicating the block address in said at least one of the save volumes where said specified data block having resided in the clone volume resides in said at least one of the save volumes; and

using said respective hash index for a read access of the snapshot data set supported by said at least one of the save volumes.

52. The method as claimed in claim 51, wherein the hash index includes a hash table indexed by a hashing of a clone volume block address, the hash table includes hash table entries pointing to hash lists, and the hash lists have hash list entries, and

the creating of the hash index includes incorporating, into each of at least some of the hash list entries, a respective clone volume block address and a corresponding save volume block address.

53. The method as claimed in claim 52, which includes maintaining the save volumes in a snapshot queue in a chronological order of the respective points in time when the snapshot data sets were created, the save volume supporting the oldest one of the snapshot data sets residing at the head of the snapshot queue, and the save volume supporting the youngest one of the snapshot data sets residing at the tail of the snapshot queue, and

maintaining a bit map having a respective bit for each block of production data set data in the clone volume, the respective bit indicating whether or not said each block of production data set data in the clone volume has not yet been modified since the respective point in time of creation of the snapshot data set supported by the save volume at the tail of the snapshot queue, and

wherein the bit map is converted into the hash index in response to creation of a new snapshot data set of the production data set.

54. The method as claimed in claim 53, which includes linking the hash index to said save volume at the tail of the snapshot queue so that the hash index remains linked to said save volume at the tail of the snapshot queue when a new save volume supporting the new snapshot data set becomes the save volume at the tail of the snapshot queue.