Managing data storage reservations on a per-family basis

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.

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 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. 
 
     
     
       16. The computer program product of  claim 15 , 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. 
     
     
       17. The computer program product of  claim 16 , 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. 
     
     
       18. The computer program product of  claim 17 , 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. 
     
     
       19. The computer program product of  claim 18 , 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. 
     
     
       20. The computer program product of  claim 19 , wherein the method further comprises 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.