Skip to content

rfc11: support optional size key #449

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

rfc11: support optional size key #449

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 10 additions & 2 deletions spec_11.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -56,8 +56,8 @@ Implementation
In contrast to the original KVS prototype, in this specification, KVS
values are unstructured, opaque data.

All tree objects SHALL be represented as JSON objects containing three top
level names:
All tree objects SHALL be represented as JSON objects containing three
REQUIRED top level names:

- *ver*, an integer version number

Expand All @@ -82,6 +82,12 @@ There are six types:
- *symlink*, data is an object containing a target key and optionally
a namespace.

The following OPTIONAL names are supported:

- *size*, contains the size of the decoded data within a *val* object
or the total size of data stored in the blobrefs of a *valref* object.


Comment on lines +85 to +90
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like it could be neat.

A thought on adding size to dir and dirref: since every KVS metadata update involves updating all parent metadata back to the root, we could use that fact to keep a cumulative size in dir and dirref objects. That is, a directory would contain the sum of the sizes of files and directories it contains. The root would then contain the total size of the namespace. These sizes could be a little bit misleading due to the automatic de-duplication inherent in the content design, but it still might be useful and it would accurately reflect the size of the subtree if dumped with flux-dump(1).

Valref
======

Expand All @@ -93,6 +99,7 @@ not a *val* object).
{ "ver":1,
"type":"valref",
"data":["sha1-aaa...","sha1-bbb...",...],
"size":64,
}

Val
Expand All @@ -105,6 +112,7 @@ A *val* represents opaque data directly, base64-encoded.
{ "ver":1,
"type":"val",
"data":"NDIyCg==",
"size":3,
}

Short values that are not large enough to warrant a *valref* and independent
Expand Down