X-Git-Url: https://git.arvados.org/arvados.git/blobdiff_plain/e7a865275a832420b9d63c0ab3ebf87eaca57d26..1267366d66cadcc09972721bf7381f96f8fe73d6:/doc/api/storage.html.textile.liquid diff --git a/doc/api/storage.html.textile.liquid b/doc/api/storage.html.textile.liquid index 868e5cc170..aa0ed21b9f 100644 --- a/doc/api/storage.html.textile.liquid +++ b/doc/api/storage.html.textile.liquid @@ -1,12 +1,17 @@ --- layout: default -navsection: api +navsection: architecture title: Storage in Keep ... +{% comment %} +Copyright (C) The Arvados Authors. All rights reserved. + +SPDX-License-Identifier: CC-BY-SA-3.0 +{% endcomment %} Keep clients are applications such as @arv-get@, @arv-put@ and @arv-mount@ which store and retrieve data from Keep. In doing so, these programs interact with both the API server (which stores file metadata in form of Collection objects) and individual Keep servers (which store the actual data blocks). -!{{site.baseurl}}/images/Keep_reading_writing_block.svg! +!(full-width){{site.baseurl}}/images/Keep_reading_writing_block.svg! h2. Storing a file @@ -18,7 +23,7 @@ h2. Storing a file # The client creates a "collection":{{site.baseurl}}/api/methods/collections.html and provides the @manifest_text@ # The API server accepts the collection after validating the signed tokens (proof of knowledge) for each block. -!{{site.baseurl}}/images/Keep_manifests.svg! +!(full-width){{site.baseurl}}/images/Keep_manifests.svg! h2. Fetching a file @@ -29,7 +34,7 @@ h2. Fetching a file # The client sends the data block request to the keep server, along with the token signature from the API which proves to Keep servers that the client is permitted to read a given block. # The server provides the block data after validating the token signature for the block (if the server does not have the block, it returns a 404 and the client tries the next highest priority server) -!{{site.baseurl}}/images/Keep_rendezvous_hashing.svg! +!(full-width){{site.baseurl}}/images/Keep_rendezvous_hashing.svg! Each @keep_service@ resource has an assigned uuid. To determine priority assignments of blocks to servers, for each keep service compute the MD5 sum of the string concatenation of the block locator (hex-coded hash part only) and service uuid, then sort this list in descending order. Blocks are preferentially placed on servers with the highest weight.