You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 19, 2024. It is now read-only.
This will require some thought, but I want to get the conversation started early in my thinking. I would like StorScore to support multiple targets. This is important for evaluating hardware for the datacenter, where multiple users share the same drive. It's also timely with all the recent activity on streaming and open channel drives.
For example, I should be able to verify that a streaming drive with one sequentially-written file mapped to each stream will get a very low WAF. Whereas this same workload will appear essentially random to a standard block mode drive, yielding a higher WAF.
Here are a few areas that will need attention:
preconditioner -- the preconditioner should run for each target, and exit only when all targets have reached steady state. Preconditioner will need to take a "done" signal.
recipe -- it will need to allow a different IO pattern for each target, and a way to signal which tests are run sequentially and which are run simultaneously.
test setup -- We can start with having the test operator set up the targets manually, and pass the file names. Later improvements can automate this.
parsing -- the raw data could have another column to let us view the stream's performance individually. I will need to think about how/if the scoring will change.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This will require some thought, but I want to get the conversation started early in my thinking. I would like StorScore to support multiple targets. This is important for evaluating hardware for the datacenter, where multiple users share the same drive. It's also timely with all the recent activity on streaming and open channel drives.
For example, I should be able to verify that a streaming drive with one sequentially-written file mapped to each stream will get a very low WAF. Whereas this same workload will appear essentially random to a standard block mode drive, yielding a higher WAF.
Here are a few areas that will need attention:
The text was updated successfully, but these errors were encountered: