Patent Publication Number: US-10769102-B2

Title: Disk storage allocation

Description:
BACKGROUND 
     Computing systems, devices, and electronic components in general may utilize content in the form of digital files. Systems may create files, store files, or receive files, as examples. A user may retain or have access to a large number of files stored across a multitude of devices, systems, ecosystems, accounts, and/or platforms. In some systems, a file may be written and/or stored in separate parts or chunks. Failure of a single disk component at either the hardware or software level may have a significant impact on a user. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates a disk container exposure count module and data storage containers including an exposure count, according to an example of the present disclosure; 
         FIG. 2  illustrates a flowchart of storing a new data chunk in a container, according to an example of the present disclosure; and 
         FIG. 3  illustrates a schematic representation of a computing device that may be used as a platform for storing a new data chunk in a container, according to an example of the present disclosure. 
     
    
    
     DETAILED DESCRIPTION 
     Various examples described below provide for allocating disk storage space on a drive or drives according to, for example, an allocation policy. An allocation policy may specify that a specific disk container or other storage element on a disk may only store data related to a limited number of data items or data chunks, such that if the container were to fail, the “exposure” or impact on a user would be minimized. 
     Generally, computer systems include storage devices to store parts of a data item or entity such as a file, database table, memory page, communication stream, or other data for subsequent retrieval. In some examples, data items may be written and/or stored as separate parts in multiple storage locations, e.g., as data chunks. In some systems, the number of data items stored across a disk or disks may number in the billions, and may be stored across a complex configuration of hardware and software elements. 
     Data may also be de-duplicated or compressed to save disk storage space. For example, a single chunk of data that is replicated across multiple files may be stored only once, with the associated files or data items having a pointer or reference to the storage location of the common data chunk in general, various techniques may be used on a disk system, including across multiple disks, to optimize data storage, read and write times, efficiency, and other metrics affecting performance, reliability, and other factors. 
     While such techniques improve the overall user and management experience and lower storage costs, they may increase the impact that failure of a disk, component, or disk sector could have on the overall system. For example, a disk may store a large number of data chunks in a single container on the disk. A container may be, in an example, an internal file used by a disk storage system to store data. 
     Data chunks in a container may relate to or “map” to a larger number of data items, particularly in the case where the data chunks are stored once and mapped to multiple data items in a one-to-many or even many-to-many relationship or dependencies. If, for example, the disk sector or disk area storing that container were to fail, e.g., such as a hardware failure or a software-level corruption, the large number of data items storing data chunks in that container could be damaged, unrepairable, or unrecoverable based on a failure of the single container. 
     A user or administrator of a system may desire to minimize the number of data items that can be lost should a single container fail, corrupt, or otherwise be unreadable or unrecoverable by limiting the number of data chunks and/or data items that may be written to a single container. Such an exposure count limit may be expressed as an absolute number, e.g., only one item may be lost from a single failure, or may expressed as a proportion or percentage, e.g., only 10% of data items stored on a disk may be lost from a single failure. 
     In another example, a combination of criteria may be used to determine an exposure count limit, such as that only 10% of items, but in no case no more than 5 items, may be lost due to a single failure. In other examples, the limit may be adaptive in nature based on, for example, whether data is stored on a personal or enterprise system, whether data is classified as mission critical, whether data is stored on one disk or across many disks, or whether data is stored on a system enabled with a redundant array of inexpensive disks or RAID. 
     In an example of allocating storage on a disk or disks to minimize the impact of data storage failure, when writing a new data chunk to a disk, a count of items stored in a container, e.g., an exposure count, is determined for each container that is available or accessible to store the new data chunk. An optimal container, e.g., a container with the lowest exposure count, is then determined such that new data may be stored in a container that would minimize impact on a user should the container fail. 
     In such an example, in the event that the exposure count of the optimal container is less than an exposure count limit set in the allocation policy, the new data chunk may be stored to the container with the lowest exposure count, e.g., the optimal container. If the exposure count is equal to or greater than the exposure count limit in the allocation policy, a new container may be created and the new data chunk may be stored in the new container. 
       FIG. 1  illustrates a disk container exposure count module and data storage containers including an exposure count, according to an example of the present disclosure. 
     A disk storage system (hereinafter simply a “disk”) may comprise a container or containers, e.g., containers  108  and  110 , which may be internal files stored on the disk for purposes of housing a data item or items, or a data chunk or data chunks. For example, a disk may store data items or files  102 ,  104 , and  106 , which may be comprised of data chunks  102   a - d ,  104   a - d , and  106   a - d , respectively. 
     Disk container exposure count module  112  may contain instructions to store the data chunks  102   a - d ,  104   a - d , and  106   a - d  across containers on the disk, including on, but not limited to, containers  108  and  110 . The instructions stored in disk container exposure count module  112  are discussed below in more detail with respect to  FIGS. 2 and 3 . 
     In the example of  FIG. 1 , an allocation policy for the disk, or more generally for a system or systems housing or accessing the disk of  FIG. 1 , may indicate that the maximum number of data items exposed to a container is two. More specifically, the allocation policy controlling the disk of  FIG. 1  may indicate that once chunks from two data items, e.g., two sources, are stored in a single container, attempts to store data chunks from a third data item will result in an instruction to store the data chunks of the third item in a different container that has not exceeded the exposure count limit of the allocation policy. 
     For example, in  FIG. 1 , data chunks  102   a - d  and  104   a - d  may be stored in container  1 , resulting in an exposure count of 2 for container  1 . However, the allocation policy of the disk shown in  FIG. 1  would then store data chunks  106   a - d  in a different container, e.g., container  2 , or a new container if no containers that satisfied the allocation policy exposure count limit were available. 
       FIG. 2  illustrates a flowchart of storing a new data chunk in a container, according to an example of the present disclosure. 
     In block  202 , a request to store a new data chunk (or chunks) in a container is received. The request may originate from an operating system, disk system, disk controller, software program or application, network communication, user input, or other system, application, or protocol capable of instructing a disk to write data. 
     In block  204 , a loop through containers available for storage on the disk may be commenced. For each container, in block  206 , a determination may be made as to whether the container already stores a data chunk from the same data item or source as the new data chunk to be written to the disk. 
     In block  210 , if the container already stores a data chunk from the same data item or source as the new data chunk to be written to the disk, the existing exposure count for the container is fetched. In such cases, the exposure count of the container would not be increased by storing the new data chunk to the container, since a data chunk from the data item is already stored in the container and thus the data item is already exposed. 
     In block  208 , if the container does not already store a data chunk from the same data item or source as the new data chunk to be written to the disk, the existing exposure count for the container is fetched and incremented by one. In such an example, storing the new data chunk to the container would increase the exposure count of the container, since no data from that data item has been stored in the container. 
     In some examples, the flow of blocks  204  through  210  may be executed each time a data chunk is to be stored, or at a particular interval. In some examples, the exposure counts may be stored on a disk system, while in other examples the exposure counts may be stored in an indexed database. 
     In block  212 , an optimal container to store the new data chunk is determined. In some examples, the optimal container may be the container on the disk with lowest exposure count in examples where multiple containers have equally low exposure counts, other factors may influence or determine which of those containers are selected, such as disk storage optimization techniques. 
     In block  214 , a determination is made as to whether the optimal container has an exposure count that is less than the exposure count limit set in the allocation policy. In the event that the exposure count of the container is less than the exposure count limit, the new data chunk may be stored in the optimal container. In the event that the exposure count is equal to or greater than the exposure count limit, a new container may be created, and the new data chunk may be stored in the new container. 
       FIG. 3  illustrates a schematic representation of a computing device that may be used as a platform for storing a new data chunk in a container, according to an example of the present disclosure. 
     In an example, device  300  comprises a storage device or storage controller  302 , memory (or machine-readable medium)  304 , processing resource or CPU  306 , and power source  308 , all of which may be coupled by a bus or other interconnect. In some examples, device  300  may also comprise a computer readable medium, which may comprise an operating system, network applications, and/or disk storage allocation module. 
     Some or all of the operations set forth in the figures may be contained as machine-readable instructions as a utility, program, or subprogram in any desired computer readable storage medium, or embedded on hardware. In addition, the operations may be embodied by machine-readable instructions. For example, they may exist as machine-readable instructions in source code, object code, executable code, or other formats. The computer readable medium may also store other machine-readable instructions, including instructions downloaded from a network or the internet. 
     The computer-readable medium may also store machine-readable instructions that may perform basic tasks such as recognizing input from input devices, such as a keyboard or a keypad; sending output to a display; keeping track of files and directories on a computer readable medium; and managing traffic on a bus. The network applications may include various components for establishing and maintaining network connections, such as machine readable instructions for implementing communication protocols including but not limited to TCP/IP, HTTP, HTTPS, Ethernet, USB, and FireWire. 
     In an example where the device of  FIG. 3  is a device for allocating disk storage, device  300  may include instructions, e.g., instructions  312 , to carry out the steps of  FIG. 2 . 
     In another example, instructions  312  may fetch a disk storage allocation policy, which as discussed above may include an exposure count limit for the disk. Instructions  312  may receive a request to store a new data item, such as from an operating system, disk system, disk controller, software program or application, network communication, user input, or other system, application, or protocol capable of instructing a disk to write data. 
     Instructions  312  may then determine a list of containers available to store the new data item and an exposure count for each of the containers. An optimal container to store the new data item may then be determined. 
     A new container may be created on the disk, e.g., new storage container  310 , in the event that the optimal container exposure count is equal to or greater than an exposure count limit. The new data item or data chunks may then be stored in the new container. 
     The above discussion is meant to be illustrative of the principles and various embodiments of the present disclosure. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.