Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Stakeholders

Identify developer(s), component validation engineer(s) & reviewer(s).

Introduction

WORM stands for Write Once Read Many. WORM is a per-container feature that aims at increasing performance for containers that are accessed in read-only mode after initial data ingest.
The typical use case is AI training dataset. There are several places in DAOS that can be accelerated if we know that the data is immutable:

  • Aggressive caching can be done in the client side;

  • File size can be safely stored in the inode (dkey) and trusted;

  • VOS layout for the object can be optimized by simplifying all the versioning and concurrency control mechanism.

Requirements & Use Cases

Describe the key functionality, use cases and assumptions. This should include what is in-scope and out-of-scope.

Design Overview

Describe the key architecture decisions, benefits & drawbacks.
Describe what software component(s) be modified and how. Diagrams are welcomed.

User Interface

How is the user/admin expected to interact with the new feature? Describe the API/tool.
What are all the tunables provided to the user/admin?
Any extra statistics that should reported to the user/admin?
Explain how errors will be handled.

Impacts

Any performance impact?
Any API changes? If so, internal or external API? Any changes required to middleware? Any interop requirements?Any VOS/config layout changes? How will migration will be supported?Any extra parameters required in the config file?Any wire protocol change? How will interop be supported?Any impact on the rebuild protocol?Any impact on aggregation?Any impact on security?

Quality

How the feature will be tested? Unit tests, functional tests and system tests need to be covered.
Describe the extra soak/performance tests that should be added.

Project Milestones

Description of the different milestones delivering incremental functionality.
Describe what will work/not work and what will be validated.
Targeted date for each milestone.

References (optional)

External papers, web page (if any)

Future Work (optional)

Known issues and future works that was considered out-of-scope.

  • No labels