Storage Landscape Whitepaper V3 - #2255
Conversation
40cb39f to
e7ad2f5
Compare
|
/assign @chira001 |
|
@xing-yang please give a markdown version of version 3 to review. Just looking at the first paragraphs of the PDF - it looks like it's based on version 1 outdated material and needs an overhaul. This isn't reviewable until we have the markdown version here please :) |
|
Thanks @angellk for reviewing this! I'll take a look and convert this into a markdown version. |
cfccf53 to
4a2a08c
Compare
Signed-off-by: xing-yang <xingyang105@gmail.com>
4a2a08c to
cddf522
Compare
|
@angellk I have converted the doc into a markdown and updated the outdated sections. Please take a look. Thanks! |
Thank you so much @xing-yang ! Makes it easier to review |
brandtkeller
left a comment
brandtkeller
left a comment
There was a problem hiding this comment.
Initial comments as I am reading through the first few sections. Don't consider them blockers.
|
|
||
| ## 3.1 Availability | ||
|
|
||
| Availability of a storage system defines the ability to access the data during failure conditions. The failures may be due to failures in the storage media, transport, controller or any other component in the system. |
There was a problem hiding this comment.
I've always thought of Availability as an observed service outcome (perhaps SLO) and Recovery Time Objective as a recovery target after an incident. Should these be separated given how availability is referenced throughout the paper?
| - Average and worst-case latency to perform storage operations to files, disk blocks or objects. | ||
| - the number of storage operations that are possible per second | ||
| - the throughput of data that can be stored or retrieved per second | ||
| - The steady state and burst performance of the metrics above and other storage metrics. |
There was a problem hiding this comment.
nit: consider omitting "and other storage metrics" unless they are listed.
|
|
||
| Storage performance varies greatly from the combination of workloads, storage software layers, topology, and storage systems. Benchmarks and datasheets offer some guidance but experiments with real datasets and data processing unique to a workload produces a better prediction of deployed performance. | ||
|
|
||
| For an in depth description of storage performance, see the [Performance and Benchmarking](https://docs.google.com/document/d/1r9gPg9wLwm2GAmEoSn_HOqMwWZjwCuT6TysclvPWVQU/edit?usp=sharing) paper created by CNCF TAG Storage (before the TAG reboot). |
There was a problem hiding this comment.
Was this paper officially published? I appreciate attribution but wonder if the note of before the tag reboot adds any necessary context.
| @@ -0,0 +1,83 @@ | |||
| # 3 Attributes of a storage interface or system | |||
There was a problem hiding this comment.
Was Security evaluated as an attribute? More curious than anything else as I think the implications are broader than simply encryption.
| - the endurance characteristics of the storage media that is holding the data (e.g. SSD vs spinning disks vs tape) | ||
| - the ability to detect corruption of data (e.g. due to component failure or wear/usage) and the ability to use data protection functions to rebuild or recover the corrupted data (sometimes referred to as "bit-rot") | ||
|
|
||
| ## 3.6 Observability |
There was a problem hiding this comment.
The next two sections (as mentioned as new additions) change to more general prose instead of measurable attributes. Was this intentional?
4 participants
This PR adds the Storage Landscape Whitepaper V3 for this initiative: #1830
What changed for V3: