From: "Michael Köppl" <m.koeppl@proxmox.com>
To: Christoph Heiss <c.heiss@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH pve-installer v3 2/7] move RAID setup checks to RAID level enum implementations
Date: Tue, 8 Jul 2025 14:01:09 +0200 [thread overview]
Message-ID: <3d66a3fa-e7ce-49e7-805d-5f4bccc553f6@proxmox.com> (raw)
In-Reply-To: <DB5SRLYPL32U.2CDWB2K7UMD7K@proxmox.com>
On 7/7/25 13:47, Christoph Heiss wrote:
>> +
>> + for v in zfs_raid_variants {
>> + assert!(v.check_disks(&[]).is_err());
>> + assert!(v.check_disks(&disks[..v.get_min_disks() - 1]).is_err());
>> + assert!(v.check_disks(&disks[..v.get_min_disks()]).is_ok());
>> + assert!(v.check_disks(&disks).is_ok());
>> + }
>> }
>
> These unit tests should be moved to `proxmox_installer_common::options`,
> if the implementation of these methods also resides there.
First of all, thanks for having a look at this! True, I forgot to move
the tests as well. Will move them for v4. Right now, both sets of unit
tests (for proxmox_installer_common::options and
proxmox_installer_common::disk_checks) use the dummy_disks and
dummy_disk helpers. I think simply copying the implementation of these
over to the options.rs tests is fine since the implementation is not
exactly complicated and it seems a bit overkill to introduce some sort
of test utils for this. What do you think?
>
>> }
>> diff --git a/proxmox-installer-common/src/options.rs b/proxmox-installer-common/src/options.rs
>> index 9271b8b..0552954 100644
>> --- a/proxmox-installer-common/src/options.rs
>> +++ b/proxmox-installer-common/src/options.rs
>> @@ -6,6 +6,7 @@ use std::str::FromStr;
>> use std::sync::OnceLock;
>> use std::{cmp, fmt};
>>
>> +use crate::disk_checks::check_raid_min_disks;
>> use crate::setup::{LocaleInfo, NetworkInfo, RuntimeInfo, SetupInfo};
>> use crate::utils::{CidrAddress, Fqdn};
>>
>> @@ -28,6 +29,17 @@ impl BtrfsRaidLevel {
>> BtrfsRaidLevel::Raid10 => 4,
>> }
>> }
>> +
>> + /// Checks whether a user-supplied Btrfs RAID setup is valid or not, such as minimum
>> + /// number of disks.
>> + ///
>> + /// # Arguments
>> + ///
>> + /// * `disks` - List of disks designated as RAID targets.
>> + pub fn check_disks(&self, disks: &[Disk]) -> Result<(), String> {
>
> Maybe rename this to something more expressive, e.g.
> check_raid_disks_setup()?
>
> check_disks() by itself is a rather "opaque" method name and would (at
> least to me, if I didn't know the implementation) suggests that the
> actual disks are checked, not just the RAID configuration and sizes.
I agree that check_disks() suggests that the function does
more/something different than it actually does. Thanks for your
suggestion, I'll adapt it to check_raid_disks_setup() in v4.
>
>> + check_raid_min_disks(disks, self.get_min_disks())?;
>> + Ok(())
>> + }
>> }
>>
>> serde_plain::derive_display_from_serialize!(BtrfsRaidLevel);
>> @@ -69,6 +81,53 @@ impl ZfsRaidLevel {
>> ZfsRaidLevel::RaidZ3 => 5,
>> }
>> }
>> +
>> + fn check_mirror_size(&self, disk1: &Disk, disk2: &Disk) -> Result<(), String> {
>> + if (disk1.size - disk2.size).abs() > disk1.size / 10. {
>> + Err(format!(
>> + "Mirrored disks must have same size:\n\n * {disk1}\n * {disk2}"
>> + ))
>> + } else {
>> + Ok(())
>> + }
>> + }
>> +
>> + /// Checks whether a user-supplied ZFS RAID setup is valid or not, such as disk sizes andminimum
>> + /// number of disks.
>> + ///
>> + /// # Arguments
>> + ///
>> + /// * `disks` - List of disks designated as RAID targets.
>> + pub fn check_disks(&self, disks: &[Disk]) -> Result<(), String> {
>
> ^ Same here as above.
>
>> + check_raid_min_disks(disks, self.get_min_disks())?;
>> +
>> + match self {
>> + ZfsRaidLevel::Raid0 => {}
>> + ZfsRaidLevel::Raid10 => {
>> + if disks.len() % 2 != 0 {
>> + return Err(format!(
>> + "Needs an even number of disks, currently selected: {}",
>> + disks.len(),
>> + ));
>> + }
>> +
>> + // Pairs need to have the same size
>> + for i in (0..disks.len()).step_by(2) {
>> + self.check_mirror_size(&disks[i], &disks[i + 1])?;
>> + }
>> + }
>> + ZfsRaidLevel::Raid1
>> + | ZfsRaidLevel::RaidZ
>> + | ZfsRaidLevel::RaidZ2
>> + | ZfsRaidLevel::RaidZ3 => {
>> + for disk in disks {
>> + self.check_mirror_size(&disks[0], disk)?;
>> + }
>> + }
>> + }
>> +
>> + Ok(())
>> + }
>> }
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2025-07-08 12:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-26 15:11 [pve-devel] [PATCH docs/installer v3 0/8] add early disk and network sanity checks Michael Köppl
2025-06-26 15:11 ` [pve-devel] [PATCH pve-installer v3 1/7] auto: add early answer file sanity check for RAID configurations Michael Köppl
2025-06-26 15:11 ` [pve-devel] [PATCH pve-installer v3 2/7] move RAID setup checks to RAID level enum implementations Michael Köppl
2025-07-07 11:47 ` Christoph Heiss
2025-07-08 12:01 ` Michael Köppl [this message]
2025-07-08 13:46 ` Christoph Heiss
2025-07-08 14:36 ` Michael Köppl
2025-06-26 15:11 ` [pve-devel] [PATCH pve-installer v3 3/7] close #5887: add sanity check for LVM swapsize Michael Köppl
2025-07-07 12:07 ` Christoph Heiss
2025-07-08 17:45 ` Michael Köppl
2025-06-26 15:11 ` [pve-devel] [PATCH pve-installer v3 4/7] auto: add check for duplicate disks in answer file Michael Köppl
2025-06-26 15:11 ` [pve-devel] [PATCH pve-installer v3 5/7] common: add more descriptive errors for invalid network configs Michael Köppl
2025-07-07 12:37 ` Christoph Heiss
2025-07-08 17:34 ` Michael Köppl
2025-06-26 15:11 ` [pve-devel] [PATCH pve-installer v3 6/7] tui: change get_value return type for easier error handling Michael Köppl
2025-07-07 12:56 ` Christoph Heiss
2025-06-26 15:11 ` [pve-devel] [PATCH pve-installer v3 7/7] common: add checks for valid subnet mask and IPv4 address within subnet Michael Köppl
2025-06-26 15:11 ` [pve-devel] [PATCH pve-docs v3 1/1] installation: remove maxroot size requirement and mention default instead Michael Köppl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3d66a3fa-e7ce-49e7-805d-5f4bccc553f6@proxmox.com \
--to=m.koeppl@proxmox.com \
--cc=c.heiss@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox