Lines Matching +full:storage +full:- +full:target
13 ## Target Audience {#blob_pg_audience}
23 Blobstore is a persistent, power-fail safe block allocator designed to be used as the local storage…
24 backing a higher level storage service, typically in lieu of a traditional filesystem. These higher…
26 distributed storage systems (ex. Ceph, Cassandra). It is not designed to be a general purpose files…
40 The Blobstore defines a hierarchy of storage abstractions as follows.
56 * **Blobstore**: An SSD which has been initialized by a Blobstore-based application is referred to …
61 +-----------------------------------------------------------------+
63 | +-----------------------------+ +-----------------------------+ |
65 | | +----+ +----+ +----+ +----+ | | +----+ +----+ +----+ +----+ | |
67 | | +----+ +----+ +----+ +----+ | | +----+ +----+ +----+ +----+ | |
68 | +-----------------------------+ +-----------------------------+ |
69 +-----------------------------------------------------------------+
82 …this metadata is kept in RAM and only synchronized with the on-disk version when the application m…
86 …RAM and on-disk. Unlike the per blob metadata, however, the Blobstore metadata region is not made …
103 Blobstore requires a backing storage device that can be integrated using the `bdev` layer, or by di…
111 Because Blobstore is designed to be lock-free, metadata operations need to be isolated to a single
128 Channels are an SPDK-wide abstraction and with Blobstore the best way to think about them is that t…
140 storage systems, instead it is returned a unique identifier by the Blobstore that it needs to use o…
158 * **Maximum Simultaneous Metadata Operations**: Determines how many internally pre-allocated memory…
160 * **Maximum Simultaneous Operations Per Channel**: Determines how many internally pre-allocated mem…
171 ### Sub-page Sized Operations
196 Asynchronous Blobstore callbacks all include an error number that should be checked; non-zero values
216 metadata will be inconsistent during run-time and only synchronized on proper shutdown. The implica…
240 …a RAM disk (malloc) back-end so that it can be executed easily in any development environment. The…
245 …and the `bdev` layer but offers multiple modes of operation to accomplish some real-world tasks. In
246 …command mode, it accepts single-shot commands which can be a little time consuming if there are ma…
264 The Blobstore owns the entire storage device. The device is divided into clusters starting from the…
269 +-----------+-----------+-----+-----------+
271 +-----------+-----------+-----+-----------+
277 +--------+-------------------+
279 +--------+-------------------+
282 +--------+-------------------+
289 Each blob is allocated a non-contiguous set of pages inside the metadata region for its metadata. T…
298 to the unallocated cluster - new extent is chosen. This information is stored in RAM and on-disk.
300 There are two extent representations on-disk, dependent on `use_extent_table` (default:true) opts u…
304 …that are not run-length encoded. Each extent page is referenced by EXTENT_TABLE descriptor, which …
305 …as part of linked list of pages. Extent table is run-length encoding all unallocated extent pages.
310 …Extents pointing to contiguous LBA are run-length encoded, including unallocated extents represent…
315 Each in-use cluster is allocated to blobstore metadata or to a particular blob. Once a cluster is
332 * **write to other blocks**: A copy-on-write operation is triggered. See @ref blob_pg_copy_on_write
354 A snapshot is a read-only blob that may have clones. A snapshot may itself be a clone of one other
358 When blob1 is snapshotted, a new read-only blob is created and blob1 becomes a clone of this new
362 | ---- | ------------------------------ | ------------------------------------------------- |
364 | 2 | Create snapshot blob2 of blob1 | `blob1 (rw) --> blob2 (ro)` |
365 | 2a | Write to blob1 | `blob1 (rw) --> blob2 (ro)` |
366 | 3 | Create snapshot blob3 of blob1 | `blob1 (rw) --> blob3 (ro) ---> blob2 (ro)` |
383 create golden golden --> golden-snap
384 snapshot golden as golden-snap ^ ^ ^
385 clone golden-snap as clone1 clone1 ---+ | |
386 clone golden-snap as clone2 clone2 -----+ |
387 clone golden-snap as clone3 clone3 -------+
397 snapshot golden as snap1 golden --> snap3 -----> snap2 ----> snap1
398 clone snap1 as clone1 clone3----/ clone2 --/ clone1 --/
409 Removal of the last clone leaves the snapshot in place. This snapshot continues to be read-only and
437 * **In memory**: The `spdk_blob` structure contains the metadata read from disk, `blob->parent_id`
438 is set to `SPDK_BLOBID_EXTERNAL_SNAPSHOT`, and `blob->back_bs_dev` references a blobstore device
460 #### Copy-on-write {#blob_pg_copy_on_write}
462 A copy-on-write operation is somewhat expensive, with the cost being proportional to the cluster
463 size. Typical copy-on-write involves the following steps:
466 2. Allocate a cluster-sized buffer into which data can be read.
467 3. Trigger a full-cluster read from the back device into the cluster-sized buffer.
468 4. Write from the cluster-sized buffer into the newly allocated cluster.
469 5. Update the blob's on-disk metadata to record ownership of the newly allocated cluster. This
470 involves at least one page-sized write.
488 of IO. They are an internal construct only and are pre-allocated on a per channel basis (channels w…
494 blob's back device, `blob->back_bs_dev`. For blobs that are not esnap clones, `channel` and
508 This is an in-memory data structure that contains key elements like the blob identifier, its curren…
521 This is the main in-memory structure for the entire Blobstore. It defines the global on disk metada…
522 information relevant to the entire system - initialization options such as cluster size, etc.
527 The super block is an on-disk structure that contains all of the relevant information that's in the…