Patent Publication Number: US-2022237151-A1

Title: Fast and efficient storage system implemented with multiple cloud services

Description:
FIELD OF INVENTION 
     The field of invention pertains generally to the computing sciences, and, more specifically, to a fast and efficient storage system implemented with multiple cloud services. 
     BACKGROUND 
     With the emergence of big data, low latency access to large volumes of information is becoming an increasingly important parameter of the performance and/or capability of an application that processes or otherwise uses large volumes of information. Moreover, cloud services have come into the mainstream that allow networked access to high performance computing component resources such as CPU and main memory resources (execute engine), database resources and/or storage resources. 
    
    
     
       FIGURES 
       A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, in which: 
         FIG. 1  shows a sparse file; 
         FIG. 2  shows a storage system that uses different types of cloud services; 
         FIGS. 3 a , 3 b  and 3 c    shows a method of accessing of a file with the storage system of  FIG. 2 ; 
         FIGS. 4 a , 4 b , 4 c , 4 d  and 4 e    show depict a snapshot process performed on the storage system of  FIG. 2 ; 
         FIG. 5  shows a method performed by the storage system of  FIG. 2   
         FIG. 6  shows a computing system. 
     
    
    
     DETAILED DESCRIPTION 
     1. Introduction 
     Referring to  FIG. 1 , as is known in the art, a sparse file can be a single file  101  whose storage resources are broken down into smaller units of storage, referred to as “stripes”  102 _ 1  through  102 _N. Individual stripes  102 _ 1 ,  102 _ 2 , . . .  102 _N within the file  101  are uniquely identified by an offset. Sparse files have been used to make more efficient use of physical storage resources. For example, stripes that are actually written to contain their respective data in physical storage, while, stripes that have not been written to do not consume any (or very little) physical storage resources. As such, the size of the overall file  101  is reduced as compared to a traditional file (in which physical storage resources sufficient to fill the entire file had to be allocated or otherwise reserved). 
     Thin provisioning generally refers to storage systems whose file structures are designed to consume less storage space than what their users believe has been allocated to them by breaking down units of storage (e.g., files) into smaller pieces (e.g., stripes) that can be uniquely accessed, written to and read from. If a smaller piece is not actually written to, it consumes little/no physical storage space thereby conserving physical storage resources. 
     For the sake of illustrative convenience, the following discussion will pertain mainly to sparse file system implementations. However, the reader should understand the discussion herein is also applicable to thin provisioned systems other than sparse file systems. 
     In the case of high performance (e.g., data center) environments certain users may desire advanced storage system functions that run “on top of” the file system such as snapshots (which preserves the state of the storage system at a specific point in time). 
     Additionally, it is often desirable that certain meta data be tracked for the folders and files within a sparse file system. For example, some indication of the folder&#39;s/file&#39;s type of content (e.g., text, image, etc.), size, time of last access, time elapsed since last access, time of last write, whether the folder/file is read-only, etc. is tracked. Here, e.g., each time a folder/file is accessed or updated (written to), its meta data is typically updated. 
     Finally, different types of cloud services are readily available to those who implement or use high performance storage systems (such as data center administrators). A cloud service provider typically provides some kind of computing component (e.g., CPU processing power, storage, etc.) that is accessible through a network such as the Internet. Here, the different types of cloud services that are commonly available can exhibit different kinds of performance and/or cost tradeoffs with respect to their role/usage within a sparse file storage system. 
     2. Storage System Embodiments 
       FIG. 2  shows a new sparse file storage system architecture  200  that uses different kinds of cloud services  201 ,  202 ,  203 ,  204  to strike an optimized balance between the associated tradeoffs of the cloud services  201 ,  202 ,  203 ,  204  and the role they play in the overall sparse file storage system  200 . 
     In the particular example shown in  FIG. 2 , the three different kinds of cloud services  201 ,  202 ,  203 ,  204  include: 1) an “execution” or “compute engine” cloud service  201  that is used as a front end to receive user requests for the storage system, comprehend/keep the storage system&#39;s respective directory or other structured/hierarchical organization of, e.g., folders and files, and, navigate through the same; 2) a database cloud service  202  that is used to keep representations of the storage system&#39;s folders and files; 3) a higher performance object storage cloud service  203  having fast access times, meta data (e.g., either or both of user defined and system defined) that stores meta information for the system&#39;s folders and files (referred to hereafter as meta data) and versioning capability to support snapshots (as described further below); and, 4) a lower performance object storage cloud service  204  having, e.g., lower access times than the higher performance object storage cloud service  203  that stores individual stripes as units of stored data (stripes are uniquely call-able in the lower performance cloud storage service  204 ). 
     Here, the first cloud service  201  is implemented with a scalable compute engine cloud service. As is known in the art, a compute engine cloud service essentially dispatches or otherwise allocates central processing unit (CPU) compute power to users of the cloud service  201 . Examples include Amazon Elastic Compute Cloud (Amazon EC2), the Google Cloud Compute Engine and the compute services of Microsoft&#39;s Azure web services platform. 
     Some or all of these services may dispatch one or more virtual machines or containers to their respective users where, e.g., each virtual machine/container is assigned to a particular user thread, request, function call, etc. Here, the allocation of a virtual machine or container typically corresponds to the allocation of some amount of underlying CPU resource (e.g., software thread, hardware thread) to the user. The amount of allocated CPU resource can be maintained quasi-permanently for a particular user or can be dynamically adjusted up or down based on user need or overall demand being placed on the service  201 . 
     Regardless, because of the ability of the allocated CPU resources to quickly execute complex software logic, a compute engine service  201  is the better form of cloud service for the handling of potentially large and/or bursty numbers of user requests and their navigation through the storage system&#39;s organizational hierarchy (e.g., directory) because such functions typically require fast processing of complicated software logic. 
     Here, in various embodiments, the compute engine service  201  is able to service requests received from users of the storage system (e.g., client application software programs, client computers, etc.) that have been provided with interfaces  204  to one or more specific types of file systems (e.g., NFSv3, NFSv4, SMB2, SMB3, FUSE, CDMI, etc.). Each interface is implemented, e.g., as an application program interface (API) that provides a user with a set of invokable commands and corresponding syntax, and their returns (collectively referred to as “protocols”), that are defined for the particular type of file system being presented. In one embodiment, instances of interfaces execute on the user side and the compute engine service  201  receives user requests from these interfaces. 
     The compute engine  201  also maintains an understanding of the organization of a particular storage system. Here, for example, file systems use a filepath to identify a particular stored item. If a user is presented a file system interface  204 , the compute engine  201  maintains and comprehends the storage system&#39;s organization of folders and files so that any filepath specified by the user can be resolved, e.g., to a particular stripe in a particular file in a particular folder. 
     In various embodiments, the second cloud service  202  is implemented as a database cloud service such as any of Amazon Aurora, Amazon DynamoDB and Amazon RDS offered by Amazon; Cloud SQL offered by Google; Azure SQL Database and/or Azure Cosmos DB offered by Microsoft. Other possible cloud database services include MongoDB, FoundationDB and CouchDB. A database includes a tree-like structures (e.g., a B− tree, a B+ tree, or a log structured merge (LSM) tree) at its front end which allows sought for items to be accessed very quickly (a specified item can be accessed after only a few nodal hops through the tree). In essence, each node of the tree can spawn many branches to a large set of next lower children nodes. “Leaf nodes” exist at the lowest nodal layer and contain the items being stored by the database. 
     In various embodiments, as mentioned above, the database cloud service  202  is used to store representations of the storage system&#39;s folders and files which can be implemented, e.g., as pages or documents (eXtensive Markup Language (XML) pages, or JSON)). Here, again, because the tree structure at the head of the database is able to quickly access information, low-latency access to a representation of any folder or file can be readily achieved. 
     To the extent that a user keeps its “customer data” in a file within a folder, such data is not physically kept in a folder representation within the second cloud service  202  database. 
     Rather, the folder representation only contains a small amount of information that is used by the storage system to fetch the folder&#39;s meta data and implement the snapshot function. 
     According to one embodiment, the contents of a file or folder representation include: 1) a pointer to or other kind of identifier, referred to as an “inode”, for the file&#39;s/folder&#39;s meta data that is kept in the third cloud service  203 ; 2) the file/folder type (e.g., sparse for files and directory, regular, special for folders); 3) a snapshot number; and, 4) a tombstone flag. The purpose of each of these items will be made more clear in the following discussion. 
     The third cloud service is a cloud storage service  203 . Here, unlike the compute engine cloud service  201  (which is optimized for logic execution) and the database cloud service  202  (which is optimized for fast access to file/folder representations), the third cloud service  203  is optimized for high performance storage. 
     Here, the optimization for high performance storage can be exemplified by the high performance object storage system  203  having faster access times (lower latencies) than the lower performance object storage service  204 . Moreover, in various embodiments, the high performance object storage service  203  supports versioning while the lower performance object storage service  204  does not support versioning. Additionally, the high performance storage service  203  may exhibit costs that are more expensive than the lower performance object storage service  204 . 
     Faster access times can be achieved, for example, with faster underlying storage technologies (e.g., flash memory instead of solid state disk drives). Versioning is the ability to keep a history of different versions of a same folder or file. For example, if a folder or file A is changed twice over time, the folder/file can be said to have three different versions over time (A, A′ and A″). A storage system having versioning capability is able to keep all three versions of the folder/file even though the most recent version of the folde/filer (A″) is the active/current version of the folder/file. 
     In various embodiments, the higher performance cloud storage service  203  is implemented with a high performance cloud object storage service. Examples include Azure Premium Blob Storage from Microsoft or similar high performance object storage extensions from other vendors (e.g., a “premium” Amazon Simple Storage Service (Amazon S3) or Google Cloud Storage account), or a high performance object storage system built as described in U.S. Pat. No. 9,524,302 assigned to Scality, S. A. of Paris, France (and particularly as described in Section 3.4.ii with respect to implementation of sparse files), hereinafter referred to as &#39;302 patent, and which is hereby incorporated by reference. 
     As is known in the art, in the case of object storage systems, units of stored information (“objects”) are identified with unique identifiers (“object IDs”). Thus, whereas a traditional file system identifies a targeted stored item with a path that flows through a directory hierarchy (“filepath”) to the item, by contrast, in the case of object storage systems, targeted stored items are identified with a unique ID for the object (that can take sometimes the appearance of a path but which, in fact, is only a flat name/ID). 
     According to various embodiments of the system of  FIG. 2 , the higher performance object storage system  203  is used to store the meta data for the storage system&#39;s folders and files. Here, each individual instance of meta data for any folder or file is stored as a separate object, having a unique object ID, in the higher performance object storage system  203 . The content of each such object can include one or more pages or documents (eXtensive Markup Language (XML) pages, or JSON) that contain the corresponding meta data. 
     Thus, in various embodiments, the inode for a folder or file that is obtained from the folder&#39;s/file&#39;s representation in the database cloud service  202  is used as the object ID to obtain the folder&#39;s unit of meta data (referred to as a “main chunk”) in the high performance object storage service  203 . In other embodiments, rather than being directly used as the object ID, the inode is used to construct or generate the object ID (e.g., the object ID is a field in a larger object ID structure, a hash of the inode is taken to generate the object ID, etc.). For ease of discussion, the following description assumes the inode is directly used as the object ID for the object containing the folder&#39;s meta data. 
     Regardless, the processing of any particular request includes quickly accessing the targeted folder&#39;s/file&#39;s representation from the database cloud service  202  and then using the inode object ID found within the folder/file representation to access the folder&#39;s/file&#39;s “main chunk” in the high performance object storage cloud service  203  (where, the main chunk contains the folder&#39;s/file&#39;s meta data). Meta data for a folder/file is commonly updated each time the folder/file is accessed. 
     A main chunk in the higher performance object storage service  203  should have its inode registered (within) at least one folder representation in the database service  202 . If folders are to be shared or accessible through more than one directory path, then the inode for a single main chunk can be registered with multiple folder representation instances in the database service  202 . 
     In various embodiments the main chunk includes the following meta-data (or “attributes”) for a folder/file: 1) uid (user ID (which, e.g., can be a large corporate user who is using the entire infrastructure as a cloud storage service)); 2) gid (group ID (e.g., multiple users can belong to a same group)); 3) atime (last access time in reading); 4) ctime (last modification of attributes); 5) mtime (last modification of content or attribute); 6) perms (permission such as unix permissions); 7) ACLS (extended permissions); 7) xattr (user defined attributes); 8) nlink (hardlink reference count management). 
     If only a file is to be accessed as a smallest unit of access (no striping), the file&#39;s content is kept in the lower performance object storage service  204 , and, the inode/object ID for the content is found in the main chunk of the folder that contains the file. 
     In the case of sparse files, in various embodiments, each stripe also has its own inode/object ID which allows individual access for each stripe on a stripe by stripe basis. The inodes/object IDs for the stripes are stored in the higher performance cloud service  203  and are linked with the meta data for the file that the stripes are components of. The actual content of the stripes are physically kept in the lower performance object storage cloud service  204 . Thus, the object IDs for the stripes are applied to the lower performance object storage cloud service  204  to actually access the stripes. 
     In various implementations spares files are implemented as described in the &#39;302 patent. As described in the &#39;302 patent, each sparse file has an associated hierarchy of meta data pages. For example, the top or root of the hierarchy is a page of pointers that each point to a separate next, lower page in the hierarchy. Each next lower intermediate page points contains pointers to next lower pages such that the hierarchy fans out akin to B tree. The lowest layer of pages (leaf pages) contain inodes/object IDs for the individual stripes which, as mentioned above, are kept in the lower performance object storage system  204 . 
     In an embodiment, the contents of a main chunk (and sparse file page hierarchy) are mutable within the higher performance storage system  203  so that the corresponding meta data (and/or sparse file hierarchy) can be modified. In order to take snapshots of the storage system, as explained in more detail further below, in various embodiments, the higher performance object system  203  also supports versioning of main chunks (and sparse file page hierarchies). 
     In an embodiment, files and stripes that are stored in the lower performance object storage service  204  are immutable meaning they cannot be modified. However, such files and stripes can be soft deleted meaning they can be marked/flagged as “deleted” or “not present” and their content is not immediately removed or written over but are or removed/written over later on (e.g., the lower performance object storage system  204  periodically cleans the system of objects marked for deletion or non presence). In essence, a soft deleted object/stripe physically remains in the storage system after it has been “deleted” (users are thereafter presented with a view that does not include the deleted stripe/object). Here, the immutable and soft delete characteristics of the files and stripes allows for an effective form of versioning of the files and stripes which, as described in more detail further below, can be used to support snapshots of the larger storage system. 
     In other embodiments, the lower performance object storage system  204  can implement versioning and/or the higher performance object storage system  203  is an immutable storage system with soft deletes (to ultimately effect deletion at least from a user perspective) and effectively implement versioning. 
     Notably, storage systems other than object storage systems (e.g., traditional file system(s)) can be used for either or both of the higher performance storage system  203  and lower performance storage system  204 . 
     As described above, each of the cloud services  201 ,  202 ,  203 ,  204  are commercially available cloud services. In various other embodiments one or more of the cloud services  201 ,  202 ,  203 ,  204  is private (a cloud service is more generally an arrangement of computing resources (e.g., CPU execution/computation, database, storage) that can be invoked/used via request over a network that is coupled to the arrangement). As such, referring to  FIG. 2 , networks  201 ,  202 ,  203 ,  204  can each be composed of the Internet, one or more private network(s), or some combination thereof. 
     3. Embodiment of Stripe Access Method 
       FIGS. 3 a , 3 b  and 3 c    depict any embodiment of a method for accessing a storage system as described above. Initially a user  300  (such as a corporate entity or individual) sends  1  a request having a filepath “A/foo/bar/file 1 ”. Here, the user is attempting to access a file (file 1 ) within a folder (bar) that is within a second, higher folder (foo). The second, higher folder (foo) is underneath the main root directory (A). 
     The request is received by the compute engine  301 . The compute engine  301 , as described above, presents a file system interface to the user  300 , so that, from the perspective of the user  300 , the user is accessing a traditional file system. The request  1  conforms to a format/syntax that complies with the interface provided by the compute engine  301 . 
     The compute engine  301  is capable of presenting many different filesystems to same or different users. As such, there compute engine can assign customized root addresses for each of the file systems that is presents. In the instant example, the file system “A” as defined by the user is uniquely identified in the emulated system presented by the compute engine  301  with root node “ 131 ” (requests having directory root “A” are in fact identified with root node “ 131 ” deeper in the system). 
     As such, the compute engine  301 , in response to receiving the request  1 , sends a Get command  2  to the database service  301  to receive the folder representation for the first folder specified in the filepath (foo). As such, the Get request  2  has an argument (“primary key”) constructed from the internal root node and the first folder in the filepath ( 131 /foo). Here, in an embodiment, Get primary keys presented to the database service  302  take the form of [(name of higher node)/(hash of name of target node)/(name of target node)]. 
     As such, in order to emulate navigation from the higher root node  131  to the next lower folder foo, the primary key is articulated as “ 131 /(hash(foo)/foo” where: 1) “ 131 ” is the root node of the file system and the immediately higher node of the folder foo; 2) hash(foo) is a hash operation performed on the name “foo”; and, 3) “foo” is the name of the target folder foo. Incorporating a hash into the primary key helps, e.g., avoid collisions with similarly named filepaths. 
     In response to the Get command, the database service  303  returns  3  the folder representation for foo which includes the inode/object ID for foo (=V). The compute engine  301 , in response to its receipt of the inode for foo, sends  4  a Get request to the higher performance object storage system  303  for the meta data (main chunk) of the folder foo. The Get request specifies the just received inode (V) as the object ID for the desired main chunk. 
     In response to the Get request, the high performance object storage service  303  returns  5  the main chunk for foo. The compute engine  301  can then update any meta data in the main chunk as appropriate and write back to the higher performance object storage system  303  (not depicted for illustrative ease). 
     Having navigated through the first nodal hop in the filepath, the compute engine  301  constructs  6  the primary key “foo/hash(bar)/bar” so that it can request the folder representation for the next folder (bar) specified in the filepath from the database service  302 . In various embodiments, the compute engine  301  maintains (e.g., in local storage and/or memory) the organized folder hierarchy (and file content of each folder) of the storage system, e.g., so that it can confirm that the specified filepath is valid (e.g., if a user deletes or adds any folder or file, the compute engine&#39;s local representation of the storage system&#39;s organization heirarchy is likewise updated). 
     In response to receiving the Get request  7  for the folder representation of bar, the database service returns  8  the inode (=W) for bar&#39;s main chunk. The compute engine  301 , in response, sends  9  a Get request to the higher performance object storage system  303  for the meta data (main chunk) of the folder bar. The Get request specifies the just received inode (W) as the object ID for the desired main chunk. 
     In response to the Get request, the high performance object storage service  303  returns  10  the main chunk for bar. The compute engine  301  can then update any meta data in the main chunk as appropriate and write back to the higher performance object storage system  303 . 
     Having navigated through the first nodal hop in the filepath, the compute engine  301  constructs  11  the primary key “bar/hash(filel)/file 1 ” so that it can request  12  the file representation for the target file (file 1 ) specified in the filepath from the database service  302 . 
     In response to the Get command, the database service  303  returns  13  the file representation for filel which includes the inode/object ID for filel (=X). The compute engine  301 , in response to its receipt of the inode for filel, sends  14  a Get request to the higher performance object storage system  303  for the meta data (main chunk) of file 1 . The Get request  14  specifies the just received inode (X) as the object ID for the desired main chunk. The high performance object storage system  303  returns  15  the main chunk for filel. 
     In response to the receipt of the file&#39;s main chunk, the compute engine  301  sends  16  a response to the user  300  that includes a file descriptor (fd=Y) for file  1 . The user  300  then sends  17  the compute engine  301  the file descriptor and corresponding offset (=Z) to identify a particular stripe of filel as per nominal sparse file accessing protocols. 
     Importantly, along with a file&#39;s nominal attributes, in an embodiment, the main chunk for filel that was returned  15  by the high performance object storage system  303  also includes an object ID for the root page of the sparse file&#39;s hierarchy of pages. 
     The compute engine  301  presents the object ID of the root page to the high performance object storage system which returns the root page, and, the compute engine proceeds to navigate through the hierarchy of pages  18 . 
     Here, each higher page contains objectlDs for next lower pages. The compute engine  301  identifies the object ID on a higher page for the correct next lower page that leads to the targeted stripe, and, sends the object ID to the high performance object storage system  303  which returns the requested page. The process continues until the leaf page is reached having objects IDs for various stripes including the targeted stripe. The compute engine  301  selects the object ID for the targeted stripe (=Z) and sends  19  a Get stripe request to the low performance object storage system  304  which returns the requested stripe. 
     Notably, in the above discussion, the terms “inode” and “object ID” were used interchangeably when referring to files or folders because the inode of a file/folder could be directly used to fetch the meta data for the file/folder from the high performance object storage system. By contrast, note that only object IDs (and not inodes) were mentioned in the immediately above discussion in relation to the hierarchy of pages for a sparse file and for the stripes themselves. 
     Here, the term “inode” has traditionally been used to refer to the meta data for a file or folder. Because the object ID that is applied to the high performance object storage system for a file or folder returns the meta data for the file or folder, it could likewise also be referred to as an “inode”. 
     By contrast, in an embodiment, because meta data is not kept for stripes individually, neither the object IDs used to fetch the stripes from the low performance object storage system nor the object IDs used to fetch the hierarchy of pages from the high performance object storage system are referred to as “inodes” (only object IDs). 
     In further embodiments, the meta data for files and folders can be made accessible to users of the storage system, whereas, the hierarchy of pages are kept internal to the storage system. 
     In further embodiments, each time a folder or file representation is obtained from the database, the compute engine service confirms that the request has permission to access the folder or file (e.g., standard POSIX user ID and group ID permission check(s) is/are performed). 
     Notably, any number of users can be granted access to a particular directory file system that is implemented with the different cloud services as described above, including, e.g., concurrent and/or parallel access to the same directory by different users (e.g., so long as their file paths do not collide, which the compute engine can monitor and control). 
     4. Embodiment of Snapshot Method 
       FIGS. 4 a  through 4 e    depict a method for taking a snapshot of a file system implemented on a storage system that operates as described above.  FIG. 4 a    shows an initial state of a sparse file implementation with the storage system. For illustrative ease, the folder that contains the sparse file, and any higher level folders are not depicted (they are discussed at the end of the present description, however). 
       FIG. 4 a    shows an initial state of the sparse file implementation. Consistent with the above teachings, the database cloud service contains a representation  411  of the file that includes an inode (object ID) for the file&#39;s meta data  412  within the higher performance object storage system. The file&#39;s meta data  412  includes objectIDs for individual stripes A, B of the sparse file (e.g., on a leaf page of the sparse file&#39;s hierarchy of pages). 
     As observed in  FIG. 4 a    the file representation  411  includes a snapshot level (= 41 ) that is equal to the storage system&#39;s “global” snapshot level. As will be more clear in the following discussion, when the snapshot level of a folder or file is the same as the file system&#39;s global snapshot level, modifications (e.g., deletions/additions/modifications made to folders/files/stripes) can be exercised within the storage system without concern of preserving previous information/state. That is, the state prior to the change need not be preserved. As such, any changes made to the file while the global snapshot level retains a value of  41  can be made without regard for the file&#39;s previous state. 
       FIG. 4 b    shows the file state after a first change is made to stripe A. Here, as described above, in an embodiment, the objects of the lower object storage system are immutable (objects cannot be overwritten with new information). As such, in order to effect a modification to stripe A, a new object is created in the lower performance object storage system A′ that is a copy of A but incorporates the change made to A. The meta data for the file  412  is updated to include a new object ID that corresponds to the object ID for A′ rather than A. The snapshot level remains at  41 . As such, object A in the low performance object storage system can be marked for soft deletion (and/or flagged as “not present”). 
       FIG. 4 c    shows the file state after a second change is made to stripe A. As such, another new object A″ is created in the lower performance object storage system that is a copy of A′ but includes the new change made to stripe A. Again, the meta data  412  for the file is updated to include a new object ID that corresponds to the object ID for A″ rather than A′. The snapshot level remains at  41 , thus object A′ in the low performance object storage system can be marked for soft deletion (and/or flagged as “not present”). 
       FIG. 4 d    shows that a snapshot of the file system has been taken (global snapshot now =42) when the state of the file has remained as in  FIG. 4 c   . Because the snapshot level of the file representation (=41) is different than the current snapshot level (=42), a next change to the file will trigger preserving the file&#39;s state so that the state of the file system as it existed when the snapshot of  FIG. 4 d    was taken is preserved. 
       FIG. 4 e    shows the file after the first change made to the file after the snapshot was taken. Here, as can be seen in  FIG. 4 e   , a second file representation  421  is created in the database service that becomes the current or “active” representation of the file. The new file representation includes a new object ID (=Y) that corresponds to the object ID for a new meta data main chunk  422  for the file in the high performance object storage system. Here, the versioning capability of the high performance object storage system is utilized to create a new version  422  of the main chunk from the old version of the main chunk  421 . 
     The new main chunk  422  reflects the change made to the file that triggered the snapshot preservation actions. In particular, with the change being a change made to stripe B, the new main chunk  422  includes a new object ID for stripe B that corresponds to an object ID for a new object ID (B′) that has been newly created in the low performance object storage system consistent with the operations described in  FIGS. 4 b  and 4 c   . As such, file representation  421  and main chunk  422  correspond to the current state of the file and are used for subsequent nominal accesses to the file (that are not requests to access a previous snapshotted state of the file) 
     The earlier representation of the file  411 , the earlier main chunk  412  and objects A″ and B correspond to the state of the file when the snapshot was taken ( FIG. 4 d   ) and are preserved in the system. The state of the file as it existed when the snapshot was taken can therefore be easily accessed by using file representation  411  rather than file representation  412 . Here, by labeling the file representations  411 ,  412  with their appropriate snapshot level, any prior snapshot level or current file state can be readily accessed. 
     Here, again, to obtain the current state of the file, the file representation with the highest snapshot level is used (one or more snapshots can be taken in the future over which no changes to the file are made resulting in a highest file representation snapshot level that is less than the current snapshot level). By contrast, if a particular snapshot level is desired, the file representation having a snapshot level that is the closest to the desired snapshot level (without being greater than the desired snapshot level) is utilized. 
     In various embodiments, the primary key that is submitted to the database service for a particular snapshot level includes the desired snapshot level (along with the primary key as described above), and, the database service includes logic that returns the representation that is closest to the desired snapshot level without exceeding the desired snapshot level. 
     In various embodiments, snapshots of folders are handled similarly as described just above. That is, a folder&#39;s representation includes an inode for a particular main chunk that contains the folder&#39;s meta data. The folder&#39;s representation also includes a snapshot level. Upon a first change to a folder after a snapshot is taken, the folder&#39;s representation in the database service is preserved and a new (current) folder representation is created. 
     Likewise, the folder&#39;s main chunk in the high performance object storage system is preserved and a new version of the main chunk is created in the high performance object storage system. The preserved folder representation includes its original inode that points to the preserved main chunk. The newly created folder representation includes an inode that points to the newly created main chunk which reflects the change made to the folder that triggered the snapshot activity. 
     In further embodiments, the folder and file representations include a tombstone flag (not depicted). A tombstone flag indicates whether or not the represented folder/file was deleted, and, if so, what the global snapshot value was when the item was deleted. Here, the item will be available/preserved for any access that corresponds to an earlier snapshot but will not be available for any access that corresponds to the snapshot value or later. 
     As mentioned above in section  2 , the immutable and soft delete characteristics of the files and stripes within the lower performance object storage system allows for an effective form of versioning of the files and stripes support the snapshot feature (older versions needed for a snapshot are not soft deleted). In other embodiments, the lower performance object storage system can implement versioning and/or the higher performance object storage system is an immutable storage system with soft deletes to effect versioning to support snapshots. 
     5. Closing Comments 
       FIG. 5  shows a method described above. The method includes accepting  501  a filepath from a user that specifies a file. The method includes forming  502  a primary key for a representation of the file. The method includes applying  503  the primary key to a database cloud service to obtain a representation of the file, the representation of the file including an inode for the file&#39;s meta data. The method includes using  504  the inode for the file&#39;s meta data to obtain the file&#39;s meta data from a high performance object cloud storage service, the file&#39;s meta data pointing to information within the high performance object cloud storage service for accessing the file&#39;s stripes. The method includes accessing  505  the information within the high performance object cloud storage service to obtain an object ID for a stripe within the file. The method includes using  506  the object ID to access the stripe from a low performance object cloud storage service. 
       FIG. 6  provides an exemplary depiction of a computing system  600 . Any of the aforementioned cloud services can be constructed, e.g., from networked clusters of computers having at least some of the components described below and/or networked clusters of such components. 
     As observed in  FIG. 6 , the basic computing system  600  may include a central processing unit (CPU)  601  (which may include, e.g., a plurality of general purpose processing cores  615 _ 1  through  615 _X) and a main memory controller  617  disposed on a multi-core processor or applications processor, main memory  602  (also referred to as “system memory”), a display  603  (e.g., touchscreen, flat-panel), a local wired point-to-point link (e.g., universal serial bus (USB)) interface  604 , a peripheral control hub (PCH)  618 ; various network I/O functions  605  (such as an Ethernet interface and/or cellular modem subsystem), a wireless local area network (e.g., WiFi) interface  606 , a wireless point-to-point link (e.g., Bluetooth) interface  607  and a Global Positioning System interface  608 , various sensors  609 _ 1  through  609 _Y, one or more cameras  610 , a battery  611 , a power management control unit  612 , a speaker and microphone  613  and an audio coder/decoder  614 . 
     An applications processor or multi-core processor  650  may include one or more general purpose processing cores  615  within its CPU  601 , one or more graphical processing units  616 , a main memory controller  617  and a peripheral control hub (PCH)  618  (also referred to as I/O controller and the like). The general purpose processing cores  615  typically execute the operating system and application software of the computing system. The graphics processing unit  616  typically executes graphics intensive functions to, e.g., generate graphics information that is presented on the display  603 . The main memory controller  617  interfaces with the main memory  602  to write/read data to/from main memory  602 . The power management control unit  612  generally controls the power consumption of the system  600 . The peripheral control hub  618  manages communications between the computer&#39;s processors and memory and the I/O (peripheral) devices. 
     Each of the touchscreen display  603 , the communication interfaces  604 - 607 , the GPS interface  608 , the sensors  609 , the camera(s)  610 , and the speaker/microphone codec  613 ,  614  all can be viewed as various forms of I/O (input and/or output) relative to the overall computing system including, where appropriate, an integrated peripheral device as well (e.g., the one or more cameras  610 ). Depending on implementation, various ones of these I/O components may be integrated on the applications processor/multi-core processor  650  or may be located off the die or outside the package of the applications processor/multi-core processor  650 . The computing system also includes non-volatile mass storage  620  which may be the mass storage component of the system which may be composed of one or more non-volatile mass storage devices (e.g. hard disk drive, solid state drive, etc.). The non-volatile mass storage  620  may be implemented with any of solid state drives (SSDs), hard disk drive (HDDs), etc. 
     Embodiments of the invention may include various processes as set forth above. The processes may be embodied in program code (e.g., machine-executable instructions). The program code, when processed, causes a general-purpose or special-purpose processor to perform the program code&#39;s processes. Alternatively, these processes may be performed by specific/custom hardware components that contain hard interconnected logic circuitry (e.g., application specific integrated circuit (ASIC) logic circuitry) or programmable logic circuitry (e.g., field programmable gate array (FPGA) logic circuitry, programmable logic device (PLD) logic circuitry) for performing the processes, or by any combination of program code and logic circuitry. 
     Elements of the present invention may also be provided as a machine-readable storage medium for storing the program code. The machine-readable medium can include, but is not limited to, floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks, FLASH memory, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards or other type of media/machine-readable medium suitable for storing electronic instructions. The program code is to be executed by one or more computers. 
     In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.