From d58846cb1cd0eb0b1a68e89425a6b2e3ea6e6f1e Mon Sep 17 00:00:00 2001 From: Deepak Cherian Date: Thu, 20 Feb 2025 10:29:34 -0700 Subject: [PATCH] fixes --- docs/docs/concepts/concurrency.md | 5 ++--- docs/docs/concepts/data-model.md | 7 +++---- docs/docs/concepts/version-control-system.md | 11 +++++------ 3 files changed, 10 insertions(+), 13 deletions(-) diff --git a/docs/docs/concepts/concurrency.md b/docs/docs/concepts/concurrency.md index 2d678cf9..3e2ee7cf 100644 --- a/docs/docs/concepts/concurrency.md +++ b/docs/docs/concepts/concurrency.md @@ -102,9 +102,8 @@ They overlap writes on the chunk spanning the range `10:20`. In this case, only one commit will succeed, and the other will raise an error. _This is good!_ It means Icechunk helped us avoid a potentially inconsistent update to the array that would have produced an incorrect end state. -:::tip -This sort of consistency problem is not possible to detect when using Zarr directly on object storage. -::: +!!! tip + This sort of consistency problem is not possible to detect when using Zarr directly on object storage. It is now up to the user to decide what to do next. In the example below, the user's code implements a manual retry by checking out the repo in its diff --git a/docs/docs/concepts/data-model.md b/docs/docs/concepts/data-model.md index 23ef35ec..62cc183d 100644 --- a/docs/docs/concepts/data-model.md +++ b/docs/docs/concepts/data-model.md @@ -47,9 +47,8 @@ In standard Zarr usage, these keys are filenames in a filesystem or object keys When writing data, a Zarr implementation will create these keys and populate them with data. -:::tip -An important point is that **the state of a Zarr dataset is spread over many different keys**, both metadata and chunks. -::: +!!! tip + An important point is that **the state of a Zarr dataset is spread over many different keys**, both metadata and chunks. ## Icechunk Data Model @@ -80,7 +79,7 @@ Tags are appropriate for publishing specific releases of a repository or for any Chunk references are "pointers" to chunks that exist in other files--HDF5, NetCDF, GRIB, etc. Icechunk can store these references alongside native Zarr chunks as "virtual datasets". -You can then can update these virtual datasets incrementally (overwrite chunks, change metadata, etc.) without touching the underlying files. +You can then can update these virtual datasets incrementally (overwrite chunks, change metadata, etc.) without touching the underlying files. Chunk references are stored in "chunk manifest" files. ### How Does It Work? diff --git a/docs/docs/concepts/version-control-system.md b/docs/docs/concepts/version-control-system.md index 1b7869bf..b708b2b5 100644 --- a/docs/docs/concepts/version-control-system.md +++ b/docs/docs/concepts/version-control-system.md @@ -192,9 +192,8 @@ graph TD; I-->|retry| D ``` -:::caution -The "optimistic concurrency" approach is relatively expensive and assumes that conflicts -are unlikely. It makes the assumption that users will design their workloads to avoid -deliberately creating many simultaneous commits at the same time. -This is elaborated further in [Best Practices](best-practices). -::: +!!! caution + The "optimistic concurrency" approach is relatively expensive and assumes that conflicts + are unlikely. It makes the assumption that users will design their workloads to avoid + deliberately creating many simultaneous commits at the same time. + This is elaborated further in [Best Practices](best-practices).