all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Fiona Ebner <f.ebner@proxmox.com>
To: Aaron Lauterer <a.lauterer@proxmox.com>,
	Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH manager] fix #4631: ceph: osd: create: add osds-per-device
Date: Mon, 21 Aug 2023 13:27:36 +0200	[thread overview]
Message-ID: <5e91a159-d79a-840f-ddae-3314e1088610@proxmox.com> (raw)
In-Reply-To: <cad5f917-49df-4855-bc55-420f694f9186@proxmox.com>

Am 21.08.23 um 12:51 schrieb Aaron Lauterer:
> responses inline
> 

Feel free to cut away irrelevant bits when responding (could've cut away
the commit message myself last time already) ;)

> On 8/21/23 10:20, Fiona Ebner wrote:
>> I noticed a warning while testing
>>
>> --> DEPRECATION NOTICE
>> --> You are using the legacy automatic disk sorting behavior
>> --> The Pacific release will change the default to --no-auto
>> --> passed data devices: 1 physical, 0 LVM
>> --> relative data size: 0.3333333333333333
>>
>> Note that I'm on Quincy, so maybe they didn't still didn't change it :P
> 
> Also shows up when using `ceph-volume lvm batch …` directly. So I guess
> not much we can do about it after consulting the man page.

We could explicitly pass --no-auto I guess [0]? While it doesn't make a
difference, since we only pass one disk to 'batch', it would at least
avoid the warning.

[0]: https://docs.ceph.com/en/reef/ceph-volume/lvm/batch/

>>
>>> +        minimum => '1',
>>> +        description => 'OSD services per physical device. Can
>>> improve fast NVME utilization.',
>>
>> Can we add an explicit recommendation against doing it for other disk
>> types? I imagine it's not beneficial for those, or?
> 
> What about something like:
> "Only useful for fast NVME devices to utilize their performance better."?
> 

Sounds good to me.

>>
>>> +        },
>>>       },
>>>       },
>>>       returns => { type => 'string' },
>>> @@ -294,6 +300,15 @@ __PACKAGE__->register_method ({
>>>       # extract parameter info and fail if a device is set more than
>>> once
>>>       my $devs = {};
>>>   +    # allow 'osds-per-device' only without dedicated db and/or wal
>>> devs. We cannot specify them with
>>> +    # 'ceph-volume lvm batch' and they don't make a lot of sense on
>>> fast NVMEs anyway.
>>> +    if ($param->{'osds-per-device'}) {
>>> +        for my $type ( qw(db_dev wal_dev) ) {
>>> +        die "Cannot use 'osds-per-device' parameter with '${type}'"
>>
>> Missing newline after error message.
>> Could also use raise_param_exc().
> 
> Ah thanks. Will switch it to an `raise_param_exc()` where we don't need
> the newline AFAICT?

Yes, the function will add a newline.




      reply	other threads:[~2023-08-21 11:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-18 12:26 Aaron Lauterer
2023-08-21  8:20 ` Fiona Ebner
2023-08-21 10:51   ` Aaron Lauterer
2023-08-21 11:27     ` Fiona Ebner [this message]

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=5e91a159-d79a-840f-ddae-3314e1088610@proxmox.com \
    --to=f.ebner@proxmox.com \
    --cc=a.lauterer@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal