Managing data storage reservations on a per-family basis

Patent metadata

Field	Value
Publication number	US-9916102-B1
Application number	US-201615197064-A
Country	US
Kind code	B1
Filing date	Jun 29, 2016
Priority date	Jun 29, 2016
Publication date	Mar 13, 2018
Grant date	Mar 13, 2018

Abstract

A technique for managing storage space in a data storage system generates liability values on a per-family basis, with each family including files in the file system that are related to one another by snapping. Each family thus groups together files in the file system that share at least some blocks among one another based on snapshot activities. Distinct files that do not share blocks based on snapping are provided in separate families. The file system leverages the snap-based relationships among family members to produce more accurate estimates of liability than would otherwise be feasible.

First claim

What is claimed is:

1. A method of managing storage space in a data storage system, the method comprising:
storing, in a file system built upon a pool of storage resources, multiple version families, each version family including a respective set of files that are related to one another by file snapping but that have no block-sharing relationships induced by file snapping with files in other version families;
in response to receiving a command to perform an action that affects storage requirements of one or more files in a version family, generating a family liability value, the family liability value providing an estimate of storage space required for that version family if the action were performed;
conducting an insurance-requesting operation, the insurance-requesting operation configured to (i) grant insurance to the version family when the pool has enough available storage space to guarantee the family liability value and (ii) deny insurance to the version family when the pool does not have enough available storage space to guarantee the family liability value; and
executing the command to perform the action based at least in part on the insurance-requesting operation granting the insurance to the version family.

2. The method of claim 1 , further comprising generating liability values for other version families in the file system, the liability value of the version family differing from the liability values of other version families in the file system.

3. The method of claim 2 , wherein generating the family liability value of a version family includes providing, as the family liability value, a value not greater than a sum of (i) all blocks allocated to all files in the version family and (ii) a summation of all shared blocks and holes in all thick files, if any, in the version family, where in a thick file is a file having a predetermined maximum size in blocks, and wherein a hole in a thick file is an address within the predetermined maximum size of the thick file for which no block is allocated or shared.

4. The method of claim 3 , further comprising maintaining, by the file system, a blocksAllocated metadata value that stores a count all blocks allocated to all files in the version family.

5. The method of claim 4 , wherein maintaining the blocksAllocated metadata value includes monitoring a set of write operations to all files in the version family and incrementing the blocksAllocated value each time a new block is allocated during any of the set of write operations.

6. The method of claim 4 , wherein each file in the version family has an inode in the file system, wherein the version family has at least one thick file, and wherein the method further comprises tracking, in the inode of each thick file in the version family, an attribute indicating a lower bound of a number of blocks allocated uniquely (blocksAllocatedUniquely) to that thick file.

7. The method of claim 6 , further comprising incrementing the blocksAllocatedUniquely attribute in the inode of each thick file in the version family in response to a write operation directed to a shared block or hole in that thick file.

8. The method of claim 7 , wherein generating the family liability value of a version family further includes providing, as the family liability value, a value not greater than a sum of (i) a summation across all thick files in the version family of all predetermined maximum sizes of those thick files and (ii) a summation across all thin files, if any, in the version family of all mapped blocks in those thin files, wherein a thin file is a file that is identified as thin in the file system and that is not fully space-guaranteed to any predetermined maximum size.

9. The method of claim 8 , wherein the inode of each file in the version family stores an attribute designating whether that file is thick or thin.

10. The method of claim 2 , wherein generating the family liability value of a version family includes providing, as the family liability value, a minimum of:
(A) a sum of (i) a summation across all thick files in the version family of all predetermined maximum sizes of those thick files and (ii) a summation across all thin files, if any, in the version family of all mapped blocks in those thin files; and
(B) a sum of (i) all blocks allocated to all files in the version family and (ii) a summation of all shared blocks and holes in all thick files, if any, in the version family,
wherein a thick file is a file that is identified as thick in the file system and that is fully space-guaranteed to a predetermined maximum size in blocks,
wherein a thin file is a file that is identified as thin in the file system and that is not fully space-guaranteed to any predetermined maximum size, and
wherein a hole in a thick file is an address within the predetermined maximum size of the thick file for which no block is allocated or shared.

11. The method of claim 10 , further comprising generating an overhead liability value for an overhead family in the file system, the overhead family including metadata structures shared by the version families but not specific to any one version family.

12. The method of claim 11 , further comprising generating a family metadata liability, the family metadata liability indicating a number of indirect blocks required to support storage of file data represented by the family liability.

13. The method of claim 12 , where each of the files in the version family is a container file that provides a complete realization of one of (i) a LUN (Logical UNit), (ii) a file system, or (iii) a virtual machine disk.

14. A data storage system, comprising control circuitry that includes a set of processing units coupled to memory, the control circuitry constructed and arranged to:
store, in a file system built upon a pool of storage resources, multiple version families, each version family including a respective set of files that are related to one another by file snapping but that have no block-sharing relationships induced by file snapping with files in other version families;
in response to receiving a command to perform an action that affects storage requirements of one or more files in a version family, generate a family liability value, the family liability value providing an estimate of storage space required for that version family if the action were performed;
conduct an insurance-requesting operation, the insurance-requesting operation configured to (i) grant insurance to the version family when the pool has enough available storage space to guarantee the family liability value and (ii) deny insurance to the version family when the pool does not have enough available storage space to guarantee the family liability value; and
execute the command to perform the action based at least in part on the insurance-requesting operation granting the insurance to the version family.

15. A computer program product including a set of non-transitory, computer-readable media having instructions which, when executed by control circuitry of a data storage system, cause the control circuitry to perform a method for managing storage space in a data storage system, the method comprising:
storing, in a file system built upon a pool of storage resources, multiple version families, each version family including a respective set of files that are related to one another by file snapping but that have no block-sharing relationships induced by file snapping with files in other version families;
in response to receiving a command to perform an action that affects storage requirements of one or more files in a version family, generating a fami

Assignees

• Emc Corp
• Emc Ip Holding Co Llc

Inventors

• Bassov Ivan
• Forrester Walter C
• Marko Michal
• Rashid Ahsan

Classifications

• G06F3/0619 Primary

  in relation to data integrity, e.g. data losses, bit errors · CPC title

• G06F3/0653

  Monitoring storage devices or systems · CPC title

• G06F3/065

  Replication mechanisms · CPC title

• G06F3/0665

  at area level, e.g. provisioning of virtual or logical volumes · CPC title

• G06F3/067 Primary

  Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS] · CPC title