|
| 1 | +# Content Addressable Storage |
| 2 | + |
| 3 | +## Introduction to CAS |
| 4 | + |
| 5 | +Content Addressable Storage, or `CAS`, is a storage system where it assigns |
| 6 | +unique addresses to the data stored. It is very useful for data deduplicaton |
| 7 | +and creating unique identifiers. |
| 8 | + |
| 9 | +Unlikely other kind of storage system like file system, CAS is immutable. It |
| 10 | +is more reliable to model a computation when representing the inputs and outputs |
| 11 | +of the computation using objects stored in CAS. |
| 12 | + |
| 13 | +The basic unit of the CAS library is a CASObject, where it contains: |
| 14 | + |
| 15 | +* Data: arbitrary data |
| 16 | +* References: references to other CASObject |
| 17 | + |
| 18 | +It can be conceptually modeled as something like: |
| 19 | + |
| 20 | +``` |
| 21 | +struct CASObject { |
| 22 | + ArrayRef<char> Data; |
| 23 | + ArrayRef<CASObject*> Refs; |
| 24 | +} |
| 25 | +``` |
| 26 | + |
| 27 | +Such abstraction can allow simple composition of CASObjects into a DAG to |
| 28 | +represent complicated data structure while still allowing data deduplication. |
| 29 | +Note you can compare two DAGs by just comparing the CASObject hash of two |
| 30 | +root nodes. |
| 31 | + |
| 32 | + |
| 33 | + |
| 34 | +## LLVM CAS Library User Guide |
| 35 | + |
| 36 | +The CAS-like storage provided in LLVM is `llvm::cas::ObjectStore`. |
| 37 | +To reference a CASObject, there are few different abstractions provided |
| 38 | +with different trade-offs: |
| 39 | + |
| 40 | +### ObjectRef |
| 41 | + |
| 42 | +`ObjectRef` is a lightweight reference to a CASObject stored in the CAS. |
| 43 | +This is the most commonly used abstraction and it is cheap to copy/pass |
| 44 | +along. It has following properties: |
| 45 | + |
| 46 | +* `ObjectRef` is only meaningful within the `ObjectStore` that created the ref. |
| 47 | +`ObjectRef` created by different `ObjectStore` cannot be cross-referenced or |
| 48 | +compared. |
| 49 | +* `ObjectRef` doesn't guarantee the existence of the CASObject it points to. An |
| 50 | +explicitly load is required before accessing the data stored in CASObject. |
| 51 | +This load can also fail, for reasons like but not limited to: object does |
| 52 | +not exist, corrupted CAS storage, operation timeout, etc. |
| 53 | +* If two `ObjectRef` are equal, it is guarantee that the object they point to |
| 54 | +(if exists) are identical. If they are not equal, the underlying objects are |
| 55 | +guaranteed to be not the same. |
| 56 | + |
| 57 | +### ObjectProxy |
| 58 | + |
| 59 | +`ObjectProxy` represents a loaded CASObject. With an `ObjectProxy`, the |
| 60 | +underlying stored data and references can be accessed without the need |
| 61 | +of error handling. The class APIs also provide convenient methods to |
| 62 | +access underlying data. The lifetime of the underlying data is equal to |
| 63 | +the lifetime of the instance of `ObjectStore` unless explicitly copied. |
| 64 | + |
| 65 | +### CASID |
| 66 | + |
| 67 | +`CASID` is the hash identifier for CASObjects. It owns the underlying |
| 68 | +storage for hash value so it can be expensive to copy and compare depending |
| 69 | +on the hash algorithm. `CASID` is generally only useful in rare situations |
| 70 | +like printing raw hash value or exchanging hash values between different |
| 71 | +CAS instances with the same hashing schema. |
| 72 | + |
| 73 | +### ObjectStore |
| 74 | + |
| 75 | +`ObjectStore` is the CAS-like object storage. It provides API to save |
| 76 | +and load CASObjects, for example: |
| 77 | + |
| 78 | +``` |
| 79 | +ObjectRef A, B, C; |
| 80 | +Expected<ObjectRef> Stored = ObjectStore.store("data", {A, B}); |
| 81 | +Expected<ObjectProxy> Loaded = ObjectStore.getProxy(C); |
| 82 | +``` |
| 83 | + |
| 84 | +It also provides APIs to convert between `ObjectRef`, `ObjectProxy` and |
| 85 | +`CASID`. |
| 86 | + |
| 87 | + |
| 88 | + |
| 89 | +## CAS Library Implementation Guide |
| 90 | + |
| 91 | +The LLVM ObjectStore APIs are designed so that it is easy to add |
| 92 | +customized CAS implementation that are interchangeable with builtin |
| 93 | +CAS implementations. |
| 94 | + |
| 95 | +To add your own implementation, you just need to add a subclass to |
| 96 | +`llvm::cas::ObjectStore` and implement all its pure virtual methods. |
| 97 | +To be interchangeable with LLVM ObjectStore, the new CAS implementation |
| 98 | +needs to conform to following contracts: |
| 99 | + |
| 100 | +* Different CASObject stored in the ObjectStore needs to have a different hash |
| 101 | +and result in a different `ObjectRef`. Vice versa, same CASObject should have |
| 102 | +same hash and same `ObjectRef`. Note two different CASObjects with identical |
| 103 | +data but different references are considered different objects. |
| 104 | +* `ObjectRef`s are comparable within the same `ObjectStore` instance, and can |
| 105 | +be used to determine the equality of the underlying CASObjects. |
| 106 | +* The loaded objects from the ObjectStore need to have the lifetime to be at |
| 107 | +least as long as the ObjectStore itself. |
| 108 | + |
| 109 | +If not specified, the behavior can be implementation defined. For example, |
| 110 | +`ObjectRef` can be used to point to a loaded CASObject so |
| 111 | +`ObjectStore` never fails to load. It is also legal to use a stricter model |
| 112 | +than required. For example, an `ObjectRef` that can be used to compare |
| 113 | +objects between different `ObjectStore` instances is legal but user |
| 114 | +of the ObjectStore should not depend on this behavior. |
| 115 | + |
| 116 | +For CAS library implementer, there is also a `ObjectHandle` class that |
| 117 | +is an internal representation of a loaded CASObject reference. |
| 118 | +`ObjectProxy` is just a pair of `ObjectHandle` and `ObjectStore`, because |
| 119 | +just like `ObjectRef`, `ObjectHandle` is only useful when paired with |
| 120 | +the ObjectStore that knows about the loaded CASObject. |
0 commit comments