summaryrefslogtreecommitdiff
path: root/lib/csu
diff options
context:
space:
mode:
authorStefan Sperling <stsp@cvs.openbsd.org>2021-02-08 11:21:54 +0000
committerStefan Sperling <stsp@cvs.openbsd.org>2021-02-08 11:21:54 +0000
commitf7d9b9b5db3018abfef29751f141651163e86de0 (patch)
treec37e76672a85c154fb395d431c55e9d6c997ed23 /lib/csu
parenta733f9a4a40d77e5a21edccaffc0228499806350 (diff)
Add a RAID1C (raid1 + crypto) softraid(8) discipline.
The RAID1C discipline encrypts data like the CRYPTO discipline, and accepts multiple chunks during creation and assembly like the RAID1 discipline. To deal with failing disks a RAID1C volume may be assembled with a smaller number of chunks than the volume was created with. The volume will then come up in degraded state. If the volume is now detached and assembled again with the correct number of chunks, any re-added chunks will require a rebuild. Consequently, assembling RAID1C volumes requires careful attention to the chunks passed via 'bioctl -l'. If a chunk is accidentally omitted from the command line during volume assembly, then this chunk will need to be rebuilt. At least one known-good chunk is required in order to assemble the volume. Like CRYPTO, RAID1C supports passphrase and key-disk authentication. Key-disk based volumes are assembled automatically if the key disk is present while the system is booting up. Unlike CRYPTO and RAID1, there is no boot support for RAID1C yet. RAID1C largely reuses existing code of RAID1 and CRYPTO disciplines. At present RAID1C's discipline-specific data structure is shared with that of the CRYPTO discipline to allow re-use of existing CRYPTO code. A custom RAID1C data structure would require CRYPTO code to access struct sr_crypto via a pointer instead of via a member field of struct sr_discipline. ok jsing@
Diffstat (limited to 'lib/csu')
0 files changed, 0 insertions, 0 deletions