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.
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
Add mixed raid levels #2520
Milestone
Comments
phillxnet
added a commit
to phillxnet/rockstor-core
that referenced
this issue
Mar 24, 2023
Extend our existing raid levels to include: raid1c3 and raid1c4. Additionally add mixed raid capability. We artificially reduce mixed raid profile options to assist with usability.
phillxnet
added a commit
to phillxnet/rockstor-core
that referenced
this issue
Mar 24, 2023
Adds abstraction, with tests, to centralise profile from pool raid levels mechanism. Minor rename-refactor from prior TODO. Enable distinguishing between single & single-dup. Add "unknown" profile as fail-through catch-all. Enable easy Web-UI access to data/metadata via additional Pool object properties as thin PROFILE look-ups. Surface data-metadata in pool details.
phillxnet
changed the title
Surface metadata raid level within Web-UI
Add mixed raid levels
Mar 25, 2023
phillxnet
added a commit
to phillxnet/rockstor-core
that referenced
this issue
Mar 25, 2023
Extend our existing raid levels to include: raid1c3 and raid1c4, introduced in kernel 5.5. Additionally add mixed raid capability. We artificially reduce mixed raid profile options to assist with usability. Adds abstraction, with tests, to generate a profile from our existing pool raid levels mechanism. Includes: - Minor rename-refactor from prior TODO. - Enable distinguishing between single & single-dup. - Add an "unknown" profile as fail-through catch-all. - Enable easy Web-UI access to data/metadata via additional Pool object properties as thin PROFILE look-ups. - Surface data-metadata in pool details Web-UI page. - Remove now redundant single raid designator for data, if metadata = single. As we now have data-metadata surfaced we no longer need this.
phillxnet
added a commit
to phillxnet/rockstor-core
that referenced
this issue
Mar 25, 2023
phillxnet
added a commit
to phillxnet/rockstor-core
that referenced
this issue
Mar 25, 2023
phillxnet
added a commit
to phillxnet/rockstor-core
that referenced
this issue
Mar 25, 2023
SUPPORTED_PROFILES was a class variable without requirement to be this way. Move to module and use in test_pool.py unsupported profile test case.
phillxnet
added a commit
to phillxnet/rockstor-core
that referenced
this issue
Mar 25, 2023
Extend our existing raid levels to include: raid1c3 and raid1c4, introduced in kernel 5.5. Additionally add mixed raid capability. We artificially reduce mixed raid profile options to assist with usability. Adds abstraction, with tests, to generate a profile from our existing pool raid levels mechanism. Includes: - Minor rename-refactor from prior TODO. - Enable distinguishing between single & single-dup. - Add an "unknown" profile as fail-through catch-all. - Enable easy Web-UI access to data/metadata via additional Pool object properties as thin PROFILE look-ups. - Surface data-metadata in pool details Web-UI page. - Remove now redundant single raid designator for data, if metadata = single. As we now have data-metadata surfaced we no longer need this. - Refactor supported profiles var for test use. SUPPORTED_PROFILES was a class variable without requirement to be this way. Move to module level and use in test_pool.py unsupported profile test case.
This was referenced Mar 25, 2023
Closing as: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As part of an ongoing effort to improve our support for such things as mixed data/metadata raid levels, it would be good to have our data and meta-data raid levels surfaced within the Web-UI.
It is proposed that we adopt more fully our existing 10 digit btrfs raid level representation introduced in:
#2500 and enhanced in #2503 that should enable the use of our existing db Pool raid field to represent both data and metadata raid levels via a relatively simple parsing mechanism.
This avoids adding excessive complexity and paves the way for extending our capabilities re underlying btrfs support.
The text was updated successfully, but these errors were encountered: