From: Fiona Ebner <f.ebner@proxmox.com>
To: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>,
"pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [RFC qemu 1/1] block/rbd: add @keyring-file option to BlockdevOptionsRbd
Date: Mon, 12 May 2025 16:36:18 +0200 [thread overview]
Message-ID: <73e9ad92-622a-4f16-ad6d-b28acc992ac9@proxmox.com> (raw)
In-Reply-To: <330ddb6da2469b425acda6ceb9cdaf5a510a854f.camel@groupe-cyllene.com>
Am 12.05.25 um 15:39 schrieb DERUMIER, Alexandre:
> Am 12.05.25 um 12:57 schrieb DERUMIER, Alexandre:
>> for blockdev, do we still use a ceph config file in /var/run for
>> potential others rbd client options ?
>
>>> Not currently, but we can add that later if we consider it worth it.
>>> We
>>> would need to merge with the storage's already existing ceph.conf and
>>> not only write the new options. For now, users can adapt their
>>> storage's
>>> ceph.conf as desired.
>
> they still are this rbd_cache_policy for efidisk to fix
> https://bugzilla.proxmox.com/show_bug.cgi?id=3329
>
>
> # SPI flash does lots of read-modify-write OPs, without writeback this
> gets really slow #3329
> if ($path =~ m/^rbd:/) {
> $var_drive_str .= ',cache=writeback';
> $path .= ':rbd_cache_policy=writeback'; # avoid write-around,
> we *need* to cache writes too
> }
>
>
>
> I'm not sure, but maybe it's fixed in qemu , the biggest problem was
> that every single byte write was push to the storage without any buffer
> (so it was pretty slow with rbd crush).
> but maybe it ok now with:
> https://github.com/qemu/qemu/commit/284a7ee2e290e0c9b8cd3ea6164d92386933054f
>
> (I don't have tested it)
Good point!
Unfortunately, it's still very slow without the additional options in
current QEMU 9.2 (i.e. even after that commit).
I suppose this does require us to have a per-drive configuration already.
It's not ideal that qemu-server knows about storage-internal details
though and would need to re-write the Ceph config, I might abstract that
away by passing an additional $hints parameter or something (e.g.
'writeback-cache' => 1, for EFI disk).
We do have a similar situation (but with KRBD):
https://lore.proxmox.com/pve-devel/20241025111304.99680-1-f.weber@proxmox.com/
Replying to stuff from your other mail here too:
> They are interesting rbd client option that we could add later
> https://bugzilla.proxmox.com/show_bug.cgi?id=6290
> crush_location=host:myhost|datacenter:mydc
> read_from_replica=localize
Those can/should simply be set in the storage's ceph.conf, or do they
need to be different per-volume or per-VM?
_______________________________________________
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-05-12 14:36 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-09 14:15 [pve-devel] [RFC qemu/pve-storage] storage plugin method to get qemu blockdevice options for volume Fiona Ebner
2025-05-09 14:15 ` [pve-devel] [RFC qemu 1/1] block/rbd: add @keyring-file option to BlockdevOptionsRbd Fiona Ebner
2025-05-12 10:57 ` DERUMIER, Alexandre via pve-devel
[not found] ` <dfc78aa17b9c1c8496fa74cb6e6d2517337b65c0.camel@groupe-cyllene.com>
2025-05-12 11:25 ` Fiona Ebner
2025-05-12 13:39 ` DERUMIER, Alexandre via pve-devel
[not found] ` <330ddb6da2469b425acda6ceb9cdaf5a510a854f.camel@groupe-cyllene.com>
2025-05-12 14:36 ` Fiona Ebner [this message]
2025-05-12 14:53 ` DERUMIER, Alexandre via pve-devel
2025-05-09 14:15 ` [pve-devel] [RFC storage 1/3] plugin: add method to get qemu blockdevice options for volume Fiona Ebner
2025-05-23 8:19 ` DERUMIER, Alexandre via pve-devel
2025-05-23 8:30 ` DERUMIER, Alexandre via pve-devel
[not found] ` <eeb11ec08d36c3a6f5290134158e91ad7be8b432.camel@groupe-cyllene.com>
2025-05-23 8:32 ` Fiona Ebner
2025-05-23 8:42 ` DERUMIER, Alexandre via pve-devel
[not found] ` <2efc51be0c973a3055e8214beef06ea9a1c6583b.camel@groupe-cyllene.com>
2025-05-23 8:46 ` Fiona Ebner
[not found] ` <175dd76aa95365010c8448bdd15eddf30aa39641.camel@groupe-cyllene.com>
2025-05-23 8:38 ` Fiona Ebner
2025-05-23 8:50 ` DERUMIER, Alexandre via pve-devel
[not found] ` <67db7959a03a391df39e9b5af24edc2bed48a21d.camel@groupe-cyllene.com>
2025-05-23 8:54 ` Fiona Ebner
2025-05-23 9:15 ` DERUMIER, Alexandre via pve-devel
[not found] ` <abbb8159177112d0f1f44d1dccc8fc3907bccb73.camel@groupe-cyllene.com>
2025-05-23 9:18 ` Fiona Ebner
2025-05-23 9:23 ` DERUMIER, Alexandre via pve-devel
2025-05-23 9:34 ` DERUMIER, Alexandre via pve-devel
[not found] ` <abebd4ee7f1197d9e549203355c9482bd7b1004a.camel@groupe-cyllene.com>
2025-05-23 9:53 ` Fiona Ebner
2025-05-23 10:30 ` DERUMIER, Alexandre via pve-devel
2025-05-09 14:15 ` [pve-devel] [RFC storage 2/3] iscsi direct plugin: implement method to get qemu blockdevice options Fiona Ebner
2025-05-12 13:14 ` Fiona Ebner
2025-05-09 14:15 ` [pve-devel] [RFC storage 3/3] rbd plugin: implement new " Fiona Ebner
2025-05-09 14:21 ` [pve-devel] [RFC qemu/pve-storage] storage plugin method to get qemu blockdevice options for volume Fiona Ebner
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=73e9ad92-622a-4f16-ad6d-b28acc992ac9@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=alexandre.derumier@groupe-cyllene.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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal