From: Fabio Fantoni via pve-devel <pve-devel@lists.proxmox.com>
To: Daniel Kral <d.kral@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Cc: Fabio Fantoni <fabio.fantoni@m2r.biz>
Subject: Re: [pve-devel] [RFC PATCH 2/2] common: btrfs: lower minimum amount of disks for raid10 to 2
Date: Wed, 15 Jan 2025 17:14:05 +0100 [thread overview]
Message-ID: <mailman.333.1736957650.441.pve-devel@lists.proxmox.com> (raw)
In-Reply-To: <0472416b-6e05-4793-876f-cc679fccf70f@proxmox.com>
[-- Attachment #1: Type: message/rfc822, Size: 9177 bytes --]
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
To: Daniel Kral <d.kral@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [RFC PATCH 2/2] common: btrfs: lower minimum amount of disks for raid10 to 2
Date: Wed, 15 Jan 2025 17:14:05 +0100
Message-ID: <65b62a24-fd78-4c4b-a7a9-5955237e872b@m2r.biz>
Il 15/01/2025 10:00, Daniel Kral ha scritto:
> On 1/13/25 13:24, Fabio Fantoni wrote:
>> btrfs profiles work differently but other hardware or software raids,
>> many users may not inform themselves well beforehand but even in the
>> case of informed users even if technically now btrfs allows lower
>> limits with the creation of raid 0 (and raid10) I think it would be
>> better to keep them at the base at the creation and then it must be
>> the user who consciously makes any subsequent conversions.
>
> Hm, I'm still unsure about this, because AFAIK we already allow
> creating ZFS RAID0 with a single disk, which technically also isn't a
> "real" RAID0 setup itself. But fair point for RAID10, it could be
> irritating for users to have a discrepancy between the minimum disk
> amount of ZFS and BTRFS RAID10 and it'd be a bit harder to communicate
> that in a understandable manner.
I'm not really sure if the difference with zfs (which they might not use
at all by btrfs users) is more impactful, or at least how proxmox
implements it, but I think it's more what you would expect in general
and even if it recently allows the use of the raid0 profile in
"fictitious" cases without requirements, or the possible removal of
disks without needing to convert the profile, it still seems strange to
me to have a "particular" situation by default, perhaps confusing even
more any less expert users.
I could be wrong, it would be useful to have more people's opinions.
>
>>
>> regarding btrfs profiles at creation, one thing that could be useful
>> is to always put duplicate metadata (dup with single disk or raid 1
>> in the case of raid0), if you don't want it by default maybe put it
>> as an additional option, and if you don't want that either at least
>> add it to the documentation (as a suggestion if you want greater
>> resilience of the filesystem without consuming excessive space)
>
> Currently, the installer creates the BTRFS filesystem with the data
> and metadata both using the same profile. I also think it could be
> valuable to have an "advanced" option, which allows to set a separate
> profile for the metadata.
>
> Feel free to send either a RFC for it (even if I can't tell you
> whether it will be accepted as it adds some complexity to the fs
> setup) or create a Bugzilla so also other users and developers can
> discuss it.
>
By default recently duplicate metadata is for all disk types, forcing
them to single is a proxmox specific thing. so it seemed good to me to
have at least the optional possibility to have them duplicated in the
installation. eventually could at least inform about this thing in the
documentation so that users are more aware and if they want they can
convert the metadata profile easily and quickly (dup for single disk and
raid1 in case of multiple disks in raid0).
regarding opening discussions I tried for some things even if there were
few or no answers.
bugzilla seems to me little used, the forum is very much used and there
is a minimum of participation but unfortunately given the enormous
quantity of topics that are continuously created the topics quickly
disappear from view.
I don't know what is best to do, eventually I will try to write again on
the forum.
--
Questa email è stata esaminata alla ricerca di virus dal software antivirus Avast.
www.avast.com
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
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-01-15 16:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-10 17:00 [pve-devel] [RFC PATCH 1/2] install: btrfs: fix raid level falling back to single mode Daniel Kral
2025-01-10 17:00 ` [pve-devel] [RFC PATCH 2/2] common: btrfs: lower minimum amount of disks for raid10 to 2 Daniel Kral
2025-01-13 12:24 ` Fabio Fantoni via pve-devel
[not found] ` <0999b2e1-8b8b-4baf-84d6-32251a675338@m2r.biz>
2025-01-15 9:00 ` Daniel Kral
2025-01-15 16:14 ` Fabio Fantoni via pve-devel [this message]
2025-01-13 12:15 ` [pve-devel] [RFC PATCH 1/2] install: btrfs: fix raid level falling back to single mode Fabio Fantoni via pve-devel
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=mailman.333.1736957650.441.pve-devel@lists.proxmox.com \
--to=pve-devel@lists.proxmox.com \
--cc=d.kral@proxmox.com \
--cc=fabio.fantoni@m2r.biz \
/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