Patent Publication Number: US-2023161505-A1

Title: System and method for shallow copy

Description:
PRIORITY CLAIM 
     This application claims priority to U.S. Provisional Application No. 63/282,094, filed Nov. 22, 2021, which application is hereby incorporated by reference in its entirety. 
    
    
     BACKGROUND 
     In some embodiments, an object store is an internet-scale, high-performance storage platform that offers reliable and cost-efficient data durability. The object store can store an unlimited amount of unstructured data of any content type, including analytic data and rich content, like images and videos. 
     SUMMARY 
     Aspects of the present disclosure relate generally to a computing environment, and more particularly to a system and method for performing a shallow copy. 
     An illustrative embodiment disclosed herein is an apparatus including a processor having programmed instructions to create a global region that is associated with a first bucket partition and a second bucket partition different from the first bucket partition, provide, to the global region, region information of a source region in which a source object is stored, create a destination region in which a destination object is stored, and provide, to the destination region, from the global region, the region information of the source region. In some embodiments, the source region is in the first bucket partition and the destination region is in the second bucket partition. 
     In some embodiments, the programmed instructions further cause the processor to copy, from the source object to the destination object, object metadata using the region information of the source region. In some embodiments, the region information of the source region includes a bucket identifier, a partition identifier, and a region identifier. In some embodiments, the programmed instructions further cause the processor to determine that the destination region is in a different partition than the partition of the source region, and create the global region in response to determining that the destination region is in the different partition than the partition of the source region. In some embodiments, providing, to the global region, the region information of the source region includes creating a pointer pointing from the global region to the source region, and providing, to the destination region, from the global region, the region information of the source region includes creating a pointer pointing from the destination region to the global region. In some embodiments, the programmed instructions further cause the processor to determine that the global region points to the source region in response to deletion of the source object in the source region, and, based on the determination, preserve the source region, such that a memory of the source region is not reclaimed. In some embodiments, the region information of the source region includes a physical disk location. 
     Another illustrative embodiment disclosed herein is a non-transitory computer readable storage medium including instructions stored thereon that, when executed by a processor, cause the processor to create a global region that is associated with a first bucket partition and a second bucket partition different from the first bucket partition, provide, to the global region, region information of a source region in which a source object is stored, create a destination region in which a destination object is stored, and provide, to the destination region, from the global region, the region information of the source region. In some embodiments, the source region is in the first bucket partition and the destination region is in the second bucket partition. 
     In some embodiments, the programmed instructions further cause the processor to copy, from the source object to the destination object, object metadata using the region information of the source region. In some embodiments, the region information of the source region includes a bucket identifier, a partition identifier, and a region identifier. In some embodiments, the programmed instructions further cause the processor to determine that the destination region is in a different partition than the partition of the source region, and create the global region in response to determining that the destination region is in the different partition than the partition of the source region. In some embodiments, providing, to the global region, the region information of the source region includes creating a pointer pointing from the global region to the source region, and providing, to the destination region, from the global region, the region information of the source region includes creating a pointer pointing from the destination region to the global region. In some embodiments, the programmed instructions further cause the processor to determine that the global region points to the source region in response to deletion of the source object in the source region, and, based on the determination, preserve the source region, such that a memory of the source region is not reclaimed. In some embodiments, the region information of the source region includes a physical disk location. 
     Another illustrative embodiment disclosed herein is a method including creating a global region that is associated with a first bucket partition and a second bucket partition different from the first bucket partition, providing, to the global region, region information of a source region in which a source object is stored, creating a destination region in which a destination object is stored, and providing, to the destination region, from the global region, the region information of the source region. In some embodiments, the source region is in the first bucket partition and the destination region is in the second bucket partition. 
     In some embodiments, the method includes causing the processor to copy, from the source object to the destination object, object metadata using the region information of the source region. In some embodiments, the region information of the source region includes a bucket identifier, a partition identifier, and a region identifier. In some embodiments, the method includes determining that the destination region is in a different partition than the partition of the source region, and creating the global region in response to determining that the destination region is in the different partition than the partition of the source region. In some embodiments, providing, to the global region, the region information of the source region includes creating a pointer pointing from the global region to the source region, and providing, to the destination region, from the global region, the region information of the source region includes creating a pointer pointing from the destination region to the global region. In some embodiments, the method includes determining that the global region points to the source region in response to deletion of the source object in the source region, and, based on the determination, preserving the source region, such that a memory of the source region is not reclaimed. In some embodiments, the region information of the source region includes a physical disk location. 
     Further details of aspects, objects, and advantages of the disclosure are described below in the detailed description, drawings, and claims. Both the foregoing general description and the following detailed description are exemplary and explanatory, and are not intended to be limiting as to the scope of the disclosure. Particular embodiments may include all, some, or none of the components, elements, features, functions, operations, or steps of the embodiments disclosed above. The subject matter which can be claimed comprises not only the combinations of features as set out in the attached claims but also any other combination of features in the claims, wherein each feature mentioned in the claims can be combined with any other feature or combination of other features in the claims. Furthermore, any of the embodiments and features described or depicted herein can be claimed in a separate claim and/or in any combination with any embodiment or feature described or depicted herein or with any of the features of the attached claims. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG.  1    illustrates an example block diagram of an object store environment, in accordance with some embodiments; 
         FIG.  2    illustrates an example block diagram of a bucket environment, in accordance with some embodiments of the present disclosure; 
         FIG.  3 A  is an example block diagram of a first type of shallow copy, in accordance with some embodiments of the present disclosure; 
         FIG.  3 B  is an example block diagram of a second type of shallow copy, in accordance with some embodiments of the present disclosure; and 
         FIG.  4    is an example swim lane diagram of a method for performing the second type of shallow copy, in accordance with some embodiments of the present disclosure; 
         FIG.  5    is an example method for selecting a type of shallow copy, in accordance with some embodiments of the present disclosure; 
         FIG.  6    is an example method for performing the first type of shallow copy, in accordance with some embodiments of the present disclosure; 
         FIG.  7    is an example method for performing the second type of shallow copy, in accordance with some embodiments of the present disclosure; and 
         FIG.  8    is a block diagram depicting an implementation of a computing device that can be used in connection with the systems depicted in  FIGS.  1 ,  2 ,  3 A and  3 B , and the methods depicted in  FIG.  4 - 7   , in accordance with some embodiments of the present disclosure. 
     
    
    
     The foregoing and other features of the present disclosure will become apparent from the following description and appended claims, taken in conjunction with the accompanying drawings. Understanding that these drawings depict only several embodiments in accordance with the disclosure and are, therefore, not to be considered limiting of its scope, the disclosure will be described with additional specificity and detail through use of the accompanying drawings. 
     DETAILED DESCRIPTION 
     In the following detailed description, reference is made to the accompanying drawings, which form a part hereof. In the drawings, similar symbols typically identify similar components, unless context dictates otherwise. The illustrative embodiments described in the detailed description, drawings, and claims are not meant to be limiting. Other embodiments may be utilized, and other changes may be made, without departing from the spirit or scope of the subject matter presented here. It will be readily understood that the aspects of the present disclosure, as generally described herein, and illustrated in the figures, can be arranged, substituted, combined, and designed in a wide variety of different configurations, all of which are explicitly contemplated and make part of this disclosure. 
     In some embodiments lacking the improvements disclosed herein, a copy object application programming interface (API) is implemented as a deep object copy, meaning that the underlying object data is copied. A deep copy can be an inefficient copy mechanism that wastes a significant amount of cluster throughput, especially when copying large objects. In particular, deep copies can be costly with Hadoop workloads or any legacy application that might use file system “move” semantics. What is needed is to perform a shallow copy, which is a metadata-only copy, to improve copy workflow latency and avoid unnecessarily consuming additional storage. 
     Disclosed herein are embodiments of a system and method for performing a shallow copy of an object. In some embodiments, a region location is copied from a source object to a destination object. Advantageously, object data of the source object need not be copied. The shallow copy speeds up copy time and reduces an amount of storage consumed. In some embodiments, in translating file system operations to object storage operations, such as translating a move operation to a copy operation and a delete operation, the shallow copy can be used to implement the copy operation. In some embodiments, the shallow copy can be used to implement a native object copy operation. Additionally, shallow copying can be applied to composable objects. 
     In some embodiments, objects are partitioned into different bucket partitions. Each bucket partition has its own garbage collection workflow. In some embodiments lacking the improvements disclosed herein, implementing shallow copies across bucket partitions results in the underlying object data being deleted after garbage collection is performed on the reference bucket partition. After the underlying object data is deleted, the destination object can be left with dangling pointers and no underlying object data to point to. What is needed is a shallow copy implementation that does not result in deletions of the underlying object data or dangling pointers. 
     Disclosed herein are embodiments of a system and method for performing a shallow copy of an object across bucket partitions. In some embodiments, a global region is created that is associated with multiple bucket portions. In some embodiments, the global region points to the source region in the source bucket partition. In some embodiments, a destination region in the destination bucket partition is created that points to the global region. In some embodiments, via the global region, the source object can be copied to the destination object using source region information provided via the global region. Advantageously, embodiments of the system and method are compliant with the metadata being separated by bucket partitions and allow for cross reference across partitions without permitting dangling pointers or expensive data copies. 
       FIG.  1    illustrates an example block diagram of an object store environment  100 , in accordance with some embodiments. The object store environment  100  includes an object store  105 . The object store  105  can be referred to as an object storage platform. The object store  105  can store objects. An object can be composed of the object itself (e.g., object data) and metadata about the object (e.g., object metadata). An object can include unstructured data. An object can include immutable data. The object store  105  can include buckets which are logical constructs where the objects are stored. Each bucket can be associated with a single set of resources. Each bucket can be associated with a single set of policies. The buckets can be backed by virtual disks (vdisks). The vdisks can be partitioned into regions. The object data can be stored in a region. 
     The object store  105  can have a flat hierarchy (e.g., no directory, sub-folders, or sub-buckets). The object store  105  can have a single namespace or a unique namespace for each of multiple tenants (e.g., users). Objects can be managed using a representational state transfer (RESTful) application programming interface (API) build on hypertext transfer protocol (HTTP) verbs (e.g., standard HTTP verbs such as GET, PUT, DELETE). Users can define object names when they upload an object. The object store  105  can prepend an object store namespace string and a bucket name to the object name. A directory structure can be simulated by adding a prefix string that includes a forward slash. 
     In some embodiments, the object store environment  100  includes the object store  105  and a vdisk controller  110  coupled to the object store  105 . The vdisk controller  110  can be executed in a hypervisor that virtualizes resources of one or more nodes (e.g., hosts, machines, servers, storage nodes, hyperconverged nodes, etc.). The vdisk controller  110  can be executed in user space or kernel space of the hypervisor. The vdisk controller  110  can be executed in a virtual machine or container. In some embodiments, the object store  105  includes an object controller  115 , a region manager  120 , a metadata service  125 , and a metadata store  130 . 
     The object controller  115  may include a processor having programmed instructions (hereinafter, the object controller  115  may include programmed instructions) to receive and serve object requests from a client, including requests to create, read, write, and delete. The object controller  115  may serve object requests corresponding to multiple buckets or bucket partitions. The client object request may be in accordance with REST API protocol. The client object request may include parameters associated with the object such as an object identifier, a bucket identifier, and/or a bucket partition identifier. 
     The object controller  115  may include programmed instructions to store any object data associated with the client request in memory. The memory may on the node that is hosting the object controller  115 . The memory may be physical or virtual. In some embodiments, the object controller  115  maintains a checksum for the object data. In some embodiments, the object controller  115  computes an MD5sum of the data. 
     The object controller  115  may include programmed instructions to send a request to the region manager  120  to allocate a region (e.g. a space/portion/chunk of one or more vdisks) to a bucket. The allocated region may be allocated for writing and reading objects of the bucket. Responsive to the region manager  120  allocating the region to the bucket, an endpoint vdisk controller, such as the vdisk controller  110 , or a component thereon, may include programmed instructions to write to and read from the region. The object controller  115  may include programmed instructions to send a request to the region manager  120  to receive an identifier of (and/or identifier of a node associated with) the endpoint vdisk controller for requesting vdisk reads and vdisk writes. 
     Once the endpoint vdisk controller is determined, the object controller  115  may include programmed instructions to send a request to the endpoint vdisk controller. The endpoint vdisk controller may be the vdisk controller that hosts the vdisk. The request may include a request to open the vdisk, to read an object from the vdisk, and/or to write an object to the vdisk. In some embodiments, the object controller  115  populates metadata associated with the object and writes the metadata to a metadata server (e.g. the metadata service  125  and/or the metadata store  130 ). The metadata may include an object identifier, a bucket identifier, a region identifier, a partition identifier, an object handle, an object key, an object key-value pair, a life-cycle policy, a retention policy, other object or region attributes, a vdisk location and/or identifier, and/or a physical disk location and/or identifier, among others. 
     The object controller  115  may include programmed instructions to send a second request to the region manager  120  to close the region. Responsive to the region being in a closed state, the endpoint vdisk controller may deny further write requests from the object controller  115 . The object controller  115  may include programmed instructions to request vdisk reads of closed vdisks from a second vdisk controller, for example, through a proxy vdisk controller on the second vdisk controller. 
     The region manager  120  may include a processor having programmed instructions (hereinafter, the region manager  120  may include programmed instructions) to manage region allocations for a cluster of one or more vdisks. The region manager  120  may include programmed instructions to load balance vdisk allocations across vdisk controllers and region allocations across vdisks. The region manager  120  may include programmed instructions to provide APIs for region allocation to the object controller  115 . 
     In some embodiments, the region manager  120  runs as a part of a metadata service acting in a master slave model where all the region allocations and vdisk allocations are handled centrally by the master. The object controller  115  may issue remote procedure calls (RPCs) to the region manager  120  to perform a region allocation. In some embodiments, the region manager  120  runs inside an object store  105  process. In some embodiments, region manager  120  running inside the object store  105  process handles vdisk allocations and region allocations for the object store  105  locally. 
     The metadata service  125  may include a processor having programmed instructions (hereinafter, the metadata service  125  may include programmed instructions) to serve requests for looking up/reading) or writing (e.g., updating) metadata associated with an object read request or an object write request from the object controller  115 , respectively. The metadata service  125  may be assigned to metadata of objects that reside in a subset of buckets or bucket partitions. The metadata service  125  may include programmed instructions to serve the metadata update request by storing the metadata in a data structure in the metadata store  130 . The metadata service  125  may include programmed instructions to serve the metadata lookup or update request by looking up or updating a metadata entry that is located at an index in the data structure in the metadata store  130 . The index may be a key derived from a hash of one or more object parameters associated with the object. The metadata service  125  may receive from the object controller  115  the index associated with the metadata lookup. 
     The metadata store  130  is a log-structured-merge (LSM) based key-value store including key-value data structures in memory and/or persistent storage. The data structures may be implemented as indexed arrays including metadata entries and corresponding indices. The indices may be represented numerically or strings. Each metadata entry includes a key-value pair including a key and one or more values. The key may be a hash of an object handle associated with an object whose metadata is stored in the metadata entry. The object handle may include the object identifier, the bucket identifier, the bucket partition identifier, and the like. The data structures may be implemented as separate arrays for each object. The data structures may be implemented as multi-dimensional arrays, where each object is assigned to a row and each version of the object is assigned to a column in that row. In some embodiments, the metadata store  130  stores metadata in persistent storage by sending a request to the vdisk controller  110  to write the metadata to a vdisk. In some embodiments, the metadata store  130  reads metadata from the persistent storage by sending a request to the vdisk controller  110  to read the metadata from the vdisk. 
     Although one object store  105 , one vdisk controller  110 , one object controller  115 , one region manager  120 , one metadata service  125 , and one metadata store  130  are shown in the object store environment  100 , in other embodiments, greater than any of the one vdisk controller  110 , one object controller  115 , one region manager  120 , one metadata service  125 , and one metadata store  130  may be used. 
       FIG.  2    illustrates an example block diagram of a bucket environment  200 , in accordance with some embodiments of the present disclosure. The bucket environment  200  includes a bucket  202 . In some embodiments, the bucket  202  includes a number of objects  204 . In some embodiments, object data  206  is stored in the bucket  202 . In some embodiments, the object data  206  of the object  204  is stored in a region  208  of a vdisk and the region  208  is included, or otherwise associated with, the bucket  202 . 
     In some embodiments, the bucket  202  includes metadata  210 . In some embodiments, the metadata  210  includes object info  212  (e.g., object metadata) of the object  204 . The object info  212  can include attributes of the object data  206 . For example, the object info  212  includes region location  214  (e.g., one or more of a partition identifier, a bucket identifier, a region identifier), the object handle, time stamps (e.g., time created, time of expiry), policies (e.g., object life-cycle policy, retention policy), a check sum, permissions, a key (e.g., including a partition identifier, a bucket identifier), a key-value pair, etc. In some embodiments, the region location  214  points to (e.g., identifies, locates, etc.) the region  208 , or a portion thereof, as shown with pointer  218 . A pointer here can refer to an address or other reference where the data of interest (e.g., the object data  206 ) can be found. In some embodiments, a location of the object data  206  can be determined from the region location  214 . In some embodiments, a garbage collection workflow includes scanning all of the region locations (e.g., the region location  214 ) in a bucket partition and using the region locations to reclaim space partially or completely from the regions (e.g., the region  208 ) in that partition. Bucket partitions are further described with respect to  FIGS.  3 A and  3 B . 
     In some embodiments, the metadata  210  includes region info  216 . Region info  216  can include attributes of the region  208 . For example, the region info  216  includes one or more attributes of the region location  214 , time stamps, policies (e.g., region life-cycle policy, retention policy), a check sum, permissions, etc. In some embodiments, the region info  216  points to the region  208  as shown with pointer  220 . In some embodiments, a location of the object data  206  can be determined from the region info  216 . 
       FIG.  3 A  is an example block diagram of an environment  300  for a first type of shallow copy, in accordance with some embodiments of the present disclosure. The environment  300  includes a bucket partition  301 . In some embodiments the object metadata (e.g., object info  212 ) and the region metadata (e.g., region info  216 ) of any bucket partition such as the bucket partition  301  is self-sufficient within the key-range of that bucket partition. Having self-sufficient bucket partitions can enable a partition-based garbage collection. 
     The bucket partition  301  includes the bucket  202  of  FIG.  2    and a bucket  302  including an object  304 .  FIG.  3 A  shows the environment  300  after the object  204  is shallow copied to an object  304 . A shallow copy is a copy of metadata such that a destination object (e.g., object  304 ) references a source object (e.g., object  204 ). In some embodiments, the object  304  includes a region location  314 . The region location  314  can be copied from the region location  214 . Thus, the object  304  can be a reference to the object  204 . In some embodiments, the region location  314  points to the region  208  as shown with pointer  318 . In some embodiments, the object  304  includes object info  312 . The object info  312  can be copied from the object info  212  using the region location  314 . 
     Garbage collection is a process in which memory of a region is reclaimed after an object (e.g., object metadata) or its associated region (e.g., region metadata) is deleted. In some embodiments, if object  204  (e.g., object info  212 ) is deleted, garbage collection is not triggered to reclaim memory of the region  208  since there is a reference in the partition  301  to the region  208 . 
       FIG.  3 B  is an example block diagram of an environment  350  for a second type of shallow copy, in accordance with some embodiments of the present disclosure. The environment  300  includes the bucket partition  301  of  FIG.  3 A  and a bucket partition  351 . In some embodiments, the bucket partition  351  includes a bucket  352 . In some embodiments, the bucket  352  includes a region  358 , metadata  360 , which includes object info  362  and region info  366 . In some embodiments, the region info  366  is associated with the region  358  (e.g., includes attributes of the region  358 ). In some embodiments, the object info includes a region location  364  that points to the region  358  (see pointer  368 ). 
     In some embodiments, the bucket partition  351  includes a global region  370  and global region info  372 , which can include attributes of the global region  370 . A global region info can be region metadata that isn&#39;t associated with any one partition-bucket pair. In some embodiments, the region info  366  associated with the region  358  includes a pointer to the global region info (see pointer  374 ). In some embodiments, the region info  226  includes a pointer to a global region (see pointer  376 ). Region info  226  can include region attributes such as life-cycle and retention policies. In some embodiments, the global region info  372  includes a pointer to the region info  226  (see pointer  378 ). The pointer  378  can be referred to as a back-pointer. Global region info  372  can include metadata that represents physical data locations. Global region info  372  can be stored as a separate column family (e.g., in the metadata store  130 ) than that of region info  366  or region info  226 . 
     The region info  226  and the region info  366  can be referred to as pointer region info or symlink region info. The region info  226  and the region info  366  can act as proxies for a region in a different partition. In some embodiments, via the pointer represented by  378 , the region info  226  can provide a location of the region  208  (e.g., the object data  206 ) to the global region info  372  and, via the pointer represented by  374 , the global region info  372  can provide a location of the region  208  (e.g., the object data  206 ) to the region info  366 . The object info  362  can be copied from the object info  212  using the region info  366 . 
     In some embodiments, if the object  204  is deleted but the object  354  has not yet been deleted, garbage collection is not triggered to reclaim memory of the region  208  since the object store  105  (e.g., the region manager  120  or the object controller  115 ) can detect that the global region  372  still has at least one reference (e.g., the pointer  374 , the region info  366 , or a pointer from global region info  372  pointing to the region info  366 ). Therefore, in some embodiments, the object  354  does not include a dangling pointer. In some embodiments, if the object  204  and the object  354  are deleted, the object store  105  determines that the object data in the region is un-referenced, which can trigger garbage collection to reclaim memory of the region  208 . In some embodiments, the garbage collection to reclaims memory of the global region  370 . In some embodiments, the garbage collection deletes the pointers (e.g., pointer  374 , pointer  376 , and/or the pointer  378 ). 
       FIG.  4    is an example swim lane diagram of a method  400  of executing the second type of shallow copy, in accordance with some embodiments of the present disclosure. The method  400  can include additional, fewer, or different operations. In some embodiments, at  402 , the object controller  115  (e.g., of the bucket partition  301 ) sends a request to the metadata service  125  (e.g., of the bucket partition  301 ) to write object  204 . This can trigger creation of metadata entries where metadata such as object info  212  is stored. In some embodiments, at  404 , the object controller  115  can send a request to the metadata service  125  to shallow copy object  204  to object  354  located in the bucket partition  351 . 
     In some embodiments, the metadata service  125  grabs a lock of the object  204 . This fences (e.g., prevents) any deletes of the object  204 . In some embodiments, the metadata service  401  acknowledges and confirms performance of the requested action. In some embodiments, the metadata service  125  looks up the object info  212  to determine that the object  204  is stored in the region  208 . In some embodiments, at  406 - 410 , the metadata service  125  facilitates copies/clones region info  226  of the object  204  to preserve object/region metadata locality and avoid dangling pointers. 
     In some embodiments, at  406 , the metadata service  125  sends a request to the metadata service  401  (e.g., of the bucket partition  351 ) to create a global region  370 . In some embodiments, the request is sent/forwarded to a region manager associated with the bucket partition  351 . In some embodiments, the metadata service  401  or the region manager acknowledges and confirms performance of the requested action. In some embodiments, the metadata service  125  or the region manager creates an entry in global region info  372  that is a clone of, and having a back-pointer ( 378 ) to, the region info  226 . In some embodiments the entry in the global region info  372  returns a region identifier. In some embodiments, if an entry of the region info  226  is a pointer  376 , the pointer  376  is traversed and returns the global region  370 . In some embodiments, the metadata locality of the global region  370  is determined by the region identifier. 
     In some embodiments, at  408 , the metadata service  125  sends a request to the metadata service  401  or the region manager to link the region  208  to the global region  370 . In some embodiments, the metadata service  401  or the region manager acknowledges and confirms performance of the requested action. In some embodiments, the metadata service  401  or the region manager converts the region info  216  (e.g., a legacy region info) associated with the region  208  of  FIG.  3 A  into the region info  226  (e.g., a pointer region info) associated with the region  208  of  FIG.  3 B . At this point, the region  208  (e.g., the region info  226 ) references the global region  370  (e.g., the global region info  372 , see pointer  376 ). 
     In some embodiments, at  410 , the metadata service  125  sends a request to the metadata service  401  or the region manager to allocate the linked region  358 . In some embodiments, the metadata service  401  or the region manager allocates a region identifier and create a region info  366  that includes an entry that points to the global region  370  (e.g., the global region info  372 ). In some embodiments, the metadata service  401  or the region manager acknowledges and confirms performance of the requested action. 
     In some embodiments, at  412 , the metadata service  125  sends a request to the metadata service  401  to write object info  362  of the object  354 . In some embodiments, the metadata service  401  acknowledges and confirms performance of the requested action. In some embodiments, the metadata service  401  writes the object info  362  using the region info  226  (e.g., global region info  372 , region info  366 , etc.) of the region  208 . In some embodiments, the metadata service  401  locates the object info  212  using the region info of the region  208  and copies the object info  212  to the object info  362 . In some embodiments, the metadata service  125  acknowledges and confirms performance of the shallow copy to the object controller  115 . 
       FIG.  5    is an example method  500  for selecting a type of shallow copy, in accordance with some embodiments of the present disclosure. The method  500  may be implemented using, or performed by one or more of the systems (e.g., the object store environment  100 , the bucket environment  200 , the environment  200 , the environment  300 , or the computing device  800 ), one or more components (e.g., the object store  105 , the object controller  115 , the region manager  120 , the metadata service  125 , the metadata service  401 , etc.) of one or more of the systems, or a processor associated with one or more of the systems or one or more components. Additional, fewer, or different operations may be performed in the method  500  depending on the embodiment. Additionally, or alternatively, two or more of the blocks of the method  500  may be performed in parallel. 
     In some embodiments, at operation  505 , a processor (e.g., a processor associated with the object store  105 ) determines whether a source object and a destination object are in a same bucket partition. In some embodiments, at operation  510 , responsive to determining that the source object and destination object are in the same bucket partition, the processor performs one or more of the operations of the method  600  described below. In some embodiments, at operation  515 , responsive to determining that the source object and destination object are not in the same bucket partition, the processor performs one or more of the operations of the method  700  described below. In some embodiments, the processor determines whether the source object is below a threshold amount of data. In some embodiments, responsive to determining whether the source object is below the threshold amount of data, the processor performs a deep copy. 
       FIG.  6    is an example method for performing the first type of shallow copy, in accordance with some embodiments of the present disclosure. The method  600  may be implemented using, or performed by one or more of the systems (e.g., the object store environment  100 , the bucket environment  200 , the environment  200 , the environment  300 , or the computing device  800 ), one or more components (e.g., the object controller  115 , the region manager  120 , the metadata service  125 , the metadata service  401 , etc.) of one or more of the systems, or a processor associated with one or more of the systems or one or more components. Additional, fewer, or different operations may be performed in the method  600  depending on the embodiment. Additionally, or alternatively, two or more of the blocks of the method  600  may be performed in parallel. 
     In some embodiments, at operation  605 , a processor (e.g., a processor associated with the object store  105 ) copies, from a source object (e.g., object  204 ) to a destination object (e.g., object  304 ), a location identifier (e.g., the region location  214 ) identifying a location of a region in which the source object is stored, wherein the source object and the destination object are in a same bucket partition. In some embodiments, copying the region location  214  generates a region location  314  in the destination object. In some embodiments, the location identifier includes a bucket identifier, a partition identifier, and a region identifier. In some embodiments, at operation  610 , the processor copies, from the source object to the destination object, object metadata using the location identifier. 
       FIG.  7    is an example method for performing the second type of shallow copy, in accordance with some embodiments of the present disclosure. The method  700  may be implemented using, or performed by one or more of the systems (e.g., the object store environment  100 , the bucket environment  200 , the environment  200 , the environment  300 , or the computing device  800 ), one or more components (e.g., the object controller  115 , the region manager  120 , the metadata service  125 , the metadata service  401 , etc.) of one or more of the systems, or a processor associated with one or more of the systems or one or more components. Additional, fewer, or different operations may be performed in the method  700  depending on the embodiment. Additionally, or alternatively, two or more of the blocks of the method  700  may be performed in parallel. 
     In some embodiments, at operation  705 , a processor (e.g., a processor associated with the object store  105 ) creates a global region (e.g., global region  370 ) that is associated with multiple bucket partitions (e.g., the bucket partitions  301  and  351 ). In some embodiments, at operation  710 , the processor provides, to the global region, region information of (e.g., associated with) a source region (e.g., the region  208 ) in which a source object (e.g., object  204 ) is stored. In some embodiments, the region information of the source region includes a bucket identifier, a partition identifier, and a region identifier. In some embodiments, at operation  715 , the processor creates a destination region (e.g., region  358 ) in which a destination object (e.g., object  354 ) is stored. In some embodiments, the destination region is created in a different (e.g., separate) partition (e.g., partition  351 ) than a partition (e.g., partition  301 ) that includes the source region. In some embodiments, at operation  720 , the processor provides, to the destination region, from the global region, the region information (e.g., region info  226 ) of the source region. In some embodiments, the processor copies, from the source object to the destination object, object metadata (e.g., object info  212 ) using the region information of the source region. 
       FIG.  8    depicts block diagrams of a computing device  800  useful for practicing an embodiment of the object store  105 , the object controller  115 , the region manager  120 , the metadata service  125 , the metadata service  401 , etc. As shown in  FIG.  8   , each computing device  800  can include a central processing unit  818 , and a main memory unit  820 . As shown in  FIG.  8   , a computing device  800  can include one or more of a storage device  836 , an installation device  832 , a network interface  834 , an I/O controller  822 , a display device  830 , a keyboard  824  or a pointing device  826 , e.g. a mouse. The storage device  836  can include, without limitation, a program  840 , such as an operating system, software, or software associated with the object store  105 . 
     The central processing unit  818  is any logic circuitry that responds to and processes instructions fetched from the main memory unit  820 . The central processing unit  818  can be provided by a microprocessor unit. The computing device  800  can be based on any of these processors, or any other processor capable of operating as described herein. The central processing unit  818  can utilize instruction level parallelism, thread level parallelism, different levels of cache, and multi-core processors. A multi-core processor can include two or more processing units on a single computing component. 
     Main memory unit  820  can include one or more memory chips capable of storing data and allowing any storage location to be directly accessed by the microprocessor  818 . Main memory unit  820  can be volatile and faster than storage  836  memory. Main memory units  820  can be Dynamic random access memory (DRAM) or any variants, including static random access memory (SRAM). The memory  820  or the storage  836  can be non-volatile; e.g., non-volatile read access memory (NVRAM). The memory  820  can be based on any type of memory chip, or any other available memory chips. In the example depicted in  FIG.  8   , the processor  818  can communicate with memory  820  via a system bus  838 . 
     A wide variety of I/O devices  828  can be present in the computing device  800 . Input devices  828  can include keyboards, mice, trackpads, trackballs, touchpads, touch mice, multi-touch touchpads and touch mice, microphones, multi-array microphones, drawing tablets, cameras, or other sensors. Output devices  828  can include video displays, graphical displays, speakers, headphones, or printers. 
     I/O devices  828  can have both input and output capabilities, including, e.g., haptic feedback devices, touchscreen displays, or multi-touch displays. Touchscreen, multi-touch displays, touchpads, touch mice, or other touch sensing devices can use different technologies to sense touch, including, e.g., capacitive, surface capacitive, projected capacitive touch (PCT), in-cell capacitive, resistive, infrared, waveguide, dispersive signal touch (DST), in-cell optical, surface acoustic wave (SAW), bending wave touch (BWT), or force-based sensing technologies. Some multi-touch devices can allow two or more contact points with the surface, allowing advanced functionality including, e.g., pinch, spread, rotate, scroll, or other gestures. Some touchscreen devices, including, e.g., Microsoft PIXELSENSE or Multi-Touch Collaboration Wall, can have larger surfaces, such as on a table-top or on a wall, and can also interact with other electronic devices. Some I/O devices  828 , display devices  830  or group of devices can be augmented reality devices. The I/O devices can be controlled by an I/O controller  822  as shown in  FIG.  8   . The I/O controller  822  can control one or more I/O devices, such as, e.g., a keyboard  824  and a pointing device  826 , e.g., a mouse or optical pen. Furthermore, an I/O device can also provide storage and/or an installation device  832  for the computing device  800 . In embodiments, the computing device  800  can provide USB connections (not shown) to receive handheld USB storage devices. In embodiments, an I/O device  828  can be a bridge between the system bus  838  and an external communication bus, e.g. a USB bus, a SCSI bus, a FireWire bus, an Ethernet bus, a Gigabit Ethernet bus, a Fibre Channel bus, or a Thunderbolt bus. 
     In embodiments, display devices  830  can be connected to I/O controller  822 . Display devices can include, e.g., liquid crystal displays (LCD), electronic papers (e-ink) displays, flexile displays, light emitting diode displays (LED), or other types of displays. In some embodiments, display devices  830  or the corresponding I/O controllers  822  can be controlled through or have hardware support for OPENGL or DIRECTX API or other graphics libraries. Any of the I/O devices  828  and/or the I/O controller  822  can include any type and/or form of suitable hardware, software, or combination of hardware and software to support, enable or provide for the connection and use of one or more display devices  830  by the computing device  800 . For example, the computing device  800  can include any type and/or form of video adapter, video card, driver, and/or library to interface, communicate, connect or otherwise use the display devices  830 . In embodiments, a video adapter can include multiple connectors to interface to multiple display devices  830 . 
     The computing device  800  can include a storage device  836  (e.g., one or more hard disk drives or redundant arrays of independent disks) for storing an operating system or other related software, and for storing application software programs such as any program related to the systems, methods, components, modules, elements, or functions depicted in  FIGS.  1 ,  2 ,  3 A , or  3 B. Examples of storage device  836  include, e.g., hard disk drive (HDD); optical drive including CD drive, DVD drive, or BLU-RAY drive; solid-state drive (SSD); USB flash drive; or any other device suitable for storing data. Storage devices  836  can include multiple volatile and non-volatile memories, including, e.g., solid state hybrid drives that combine hard disks with solid state cache. Storage devices  836  can be non-volatile, mutable, or read-only. Storage devices  836  can be internal and connect to the computing device  800  via a bus  838 . Storage device  836  can be external and connect to the computing device  800  via an I/O device  828  that provides an external bus. Storage device  836  can connect to the computing device  800  via the network interface  834  over a network. Some client devices may not require a non-volatile storage device  836  and can be thin clients or zero client systems. Some Storage devices  836  can be used as an installation device  832  and can be suitable for installing software and programs. 
     The computing device  800  can include a network interface  834  to interface to the network through a variety of connections including, but not limited to, standard telephone lines LAN or WAN links (e.g., 802.11, T1, T3, Gigabit Ethernet, Infiniband), broadband connections (e.g., ISDN, Frame Relay, ATM, Gigabit Ethernet, Ethernet-over-SONET, ADSL, VDSL, BPON, GPON, fiber optical including FiOS), wireless connections, or some combination of any or all of the above. Connections can be established using a variety of communication protocols (e.g., TCP/IP, Ethernet, ARCNET, SONET, SDH, Fiber Distributed Data Interface (FDDI), IEEE 802.11a/b/g/n/ac/ax, CDMA, GSM, WiMax and direct asynchronous connections). The computing device  800  can communicate with other computing devices  800  via any type and/or form of gateway or tunneling protocol e.g. Secure Socket Layer (SSL), Transport Layer Security (TLS) or QUIC protocol. The network interface  834  can include a built-in network adapter, network interface card, PCMCIA network card, EXPRESSCARD network card, card bus network adapter, wireless network adapter, USB network adapter, modem or any other device suitable for interfacing the computing device  800  to any type of network capable of communication and performing the operations described herein. 
     A computing device  800  of the sort depicted in  FIG.  8    can operate under the control of an operating system, which controls scheduling of tasks and access to system resources. The computing device  800  can be running any operating system configured for any type of computing device, including, for example, a desktop operating system, a mobile device operating system, a tablet operating system, or a smartphone operating system. 
     The computing device  800  can be any workstation, telephone, desktop computer, laptop or notebook computer, netbook, ULTRABOOK, tablet, server, handheld computer, mobile telephone, smartphone or other portable telecommunications device, media playing device, a gaming system, mobile computing device, or any other type and/or form of computing, telecommunications or media device that is capable of communication. The computing device  800  has sufficient processor power and memory capacity to perform the operations described herein. In some embodiments, the computing device  800  can have different processors, operating systems, and input devices consistent with the device. 
     In embodiments, the status of one or more machines (e.g., machines associated with the object store  105 ) in the network can be monitored as part of network management. In embodiments, the status of a machine can include an identification of load information (e.g., the number of processes on the machine, CPU and memory utilization), of port information (e.g., the number of available communication ports and the port addresses), or of session status (e.g., the duration and type of processes, and whether a process is active or idle). In another of these embodiments, this information can be identified by a plurality of metrics, and the plurality of metrics can be applied at least in part towards decisions in load distribution, network traffic management, and network failure recovery as well as any aspects of operations of the present solution described herein. 
     The processes, systems and methods described herein can be implemented by the computing device  800  in response to the CPU  818  executing an arrangement of instructions contained in main memory  820 . Such instructions can be read into main memory  820  from another computer-readable medium, such as the storage device  836 . Execution of the arrangement of instructions contained in main memory  820  causes the computing device  800  to perform the illustrative processes described herein. One or more processors in a multi-processing arrangement may also be employed to execute the instructions contained in main memory  820 . Hard-wired circuitry can be used in place of or in combination with software instructions together with the systems and methods described herein. Systems and methods described herein are not limited to any specific combination of hardware circuitry and software. 
     Although an example computing system has been described in  FIG.  8   , the subject matter including the operations described in this specification can be implemented in other types of digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. 
     It is to be understood that any examples used herein are simply for purposes of explanation and are not intended to be limiting in any way. 
     The herein described subject matter sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely exemplary, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively “associated” such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as “associated with” each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being “operably connected,” or “operably coupled,” to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being “operably couplable,” to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and/or physically interacting components and/or wirelessly interactable and/or wirelessly interacting components and/or logically interacting and/or logically interactable components. 
     With respect to the use of substantially any plural and/or singular terms herein, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. The various singular/plural permutations may be expressly set forth herein for sake of clarity. 
     It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as “open” terms (e.g., the term “including” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “includes” should be interpreted as “includes but is not limited to,” etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases “at least one” and “one or more” to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim recitation to disclosures containing only one such recitation, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an” (e.g., “a” and/or “an” should typically be interpreted to mean “at least one” or “one or more”); the same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should typically be interpreted to mean at least the recited number (e.g., the bare recitation of “two recitations,” without other modifiers, typically means at least two recitations, or two or more recitations). Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc.” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., “a system having at least one of A, B, and C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). In those instances where a convention analogous to “at least one of A, B, or C, etc.” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., “a system having at least one of A, B, or C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). It will be further understood by those within the art that virtually any disjunctive word and/or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B.” Further, unless otherwise noted, the use of the words “approximate,” “about,” “around,” “substantially,” etc., mean plus or minus ten percent. 
     The foregoing description of illustrative embodiments has been presented for purposes of illustration and of description. It is not intended to be exhaustive or limiting with respect to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of the disclosed embodiments. It is intended that the scope of the disclosure be defined by the claims appended hereto and their equivalents.