Hi,
I still have this last year patch pending
https://lists.proxmox.com/pipermail/pve-devel/2023-May/056815.html
to enabled conditionnaly tcmalloc in qemu
It's still required for performance with librbd with last qemu /lirbd
I get a 30-40% performance boost in iops and latency for small
>>
>>I managed to port it over, and in the second patch I squashed both
>>changes into one diff hunk, those two hunks touching the same file
>>confused me slightly initially ^^
oh, sorry, it was 2 patches from the initial github PR, and I have
merged them in the same patch manually, not cleanly
Am 09/01/2024 um 16:46 schrieb DERUMIER, Alexandre:
> oh, I have tested with 17.2.7-pve1
>
>
> I'll look for 18.2
I managed to port it over, and in the second patch I squashed both
changes into one diff hunk, those two hunks touching the same file
confused me slightly initially ^^
oh, I have tested with 17.2.7-pve1
I'll look for 18.2
Message initial
De: Thomas Lamprecht
À: Proxmox VE development discussion ,
Alexandre Derumier
Objet: Re: [pve-devel] [PATCH ceph 0/2] Build rocksdb in non-debug mode
Date: 09/01/2024 16:39:52
Am 09/01/2024 um 15:50
Am 09/01/2024 um 15:50 schrieb Alexandre Derumier:
> They are a bug in current debian packaging,
> where rocksdb is build in debug mode (not inheriting from cmake flags)
>
> patch 1 already exist in ubuntu
> patch 2 is a newer patch commited in ceph recently
>
> (patch 2 should be enough, but
source: https://github.com/ceph/ceph/pull/54891
build packages with 'RelWithDebInfo' to avoid to build rocksdb in debug
This is already the default in ubuntu packages
https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1894453
---
patches/0021-debian-rules-fix-buildtype.patch | 22
They are a bug in current debian packaging,
where rocksdb is build in debug mode (not inheriting from cmake flags)
patch 1 already exist in ubuntu
patch 2 is a newer patch commited in ceph recently
(patch 2 should be enough, but I'm keeping patch1 by security).
I have tested it, 4k randwrite
upstream patch: https://github.com/ceph/ceph/pull/54918
---
...ocksb-inherit-parent-cmake-cxx-flags.patch | 57 +++
patches/series| 3 +-
2 files changed, 59 insertions(+), 1 deletion(-)
create mode 100644
and point users to proxmox-offline-mirror-helper
Signed-off-by: Alexander Zeidler
---
PVE/CLI/pvesubscription.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/PVE/CLI/pvesubscription.pm b/PVE/CLI/pvesubscription.pm
index 2fd641d0..f1c11289 100755
---
Signed-off-by: Alexander Zeidler
---
PVE/Report.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/PVE/Report.pm b/PVE/Report.pm
index 10b28c79..9c46aa9b 100644
--- a/PVE/Report.pm
+++ b/PVE/Report.pm
@@ -85,7 +85,7 @@ my $init_report_cmds = sub {
cmds => [
Signed-off-by: Alexander Zeidler
---
PVE/CLI/pvesubscription.pm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/PVE/CLI/pvesubscription.pm b/PVE/CLI/pvesubscription.pm
index 2eb26cb4..2fd641d0 100755
--- a/PVE/CLI/pvesubscription.pm
+++ b/PVE/CLI/pvesubscription.pm
@@ -47,6 +47,8 @@
With pvebackup_propagate_error(), the first error wins. When one job
in the transaction fails, it is expected that later jobs get the
ECANCELED error. Those are not interesting and by skipping them a more
interesting error, which is likely the actual root cause, can win.
Signed-off-by: Fiona
Makes it simpler and shorter. Still results in the same code after
applying both patches in question.
Signed-off-by: Fiona Ebner
---
...-Backup-add-backup-dump-block-driver.patch | 22 ++---
...ckup-Proxmox-backup-patches-for-QEMU.patch | 81 ---
2 files changed, 28
Repeatedly creating users no longer re-encodes non-ASCII characters with
this patch applied.
Tested-by: Filip Schauer
On 09/01/2024 12:55, Fiona Ebner wrote:
by correclty passing the $force_utf8 flag to
PVE::Tools::file_set_contents(). The idea was that only callers that
are ready will opt-in
I just tried your patch, but it did not fix this specific issue.
On 09/01/2024 14:38, Fiona Ebner wrote:
Am 09.01.24 um 14:35 schrieb Filip Schauer:
UTF8 decode non-ASCII characters when syncing user attributes, since
those will be encoded later on. Without this fix the attributes were
encoded
Am 09.01.24 um 14:35 schrieb Filip Schauer:
> UTF8 decode non-ASCII characters when syncing user attributes, since
> those will be encoded later on. Without this fix the attributes were
> encoded twice, resulting in cases such as 'ü' turning into 'ü'.
>
> Signed-off-by: Filip Schauer
Is this
Patch v2 is available:
https://lists.proxmox.com/pipermail/pve-devel/2024-January/061273.html
On 08/01/2024 10:26, Wolfgang Bumiller wrote:
On Wed, Dec 20, 2023 at 03:37:03PM +0100, Filip Schauer wrote:
Decode non-ASCII character when syncing user attributes, since those
decode *how*?
will
UTF8 decode non-ASCII characters when syncing user attributes, since
those will be encoded later on. Without this fix the attributes were
encoded twice, resulting in cases such as 'ü' turning into 'ü'.
Signed-off-by: Filip Schauer
---
Changes since v1:
* Do not try to URI unescape the user
On Wed, Dec 13, 2023 at 05:42:00PM +0100, Lukas Wagner wrote:
> For mails forwarded by `proxmox-mail-forward` to an SMTP target, the
> original message was nested as a 'message/rfc822' message part.
> Originally this approach was chosen to avoid having to rewrite
> message headers.
> Good
On Thu, Dec 14, 2023 at 01:42:07PM +0100, Lukas Wagner wrote:
> by a matcher.
^ this line should be part of the subject
>
> In the 'delete'-handler targets, we check if a
> target is still referenced by a matcher - if it is, we return an
> error. For built-in targets, this is actually not
by correclty passing the $force_utf8 flag to
PVE::Tools::file_set_contents(). The idea was that only callers that
are ready will opt-in to the behavior.
When reading files with PVE::Tools::file_get_contents() or
ipcc_get_config(), the UTF-8 flag on the Perl string is not set, even
if the data is
On December 7, 2023 5:10 pm, Fiona Ebner wrote:
> It can be security-relevant in some environments. The LVM storage
> documentation can be reached via the "Help" button and contains a few
> more details.
>
> Signed-off-by: Fiona Ebner
> ---
> www/manager6/storage/LVMEdit.js | 10 ++
> 1
On December 7, 2023 5:10 pm, Fiona Ebner wrote:
> mentioning why zeroing-out might be necessary.
>
> Signed-off-by: Fiona Ebner
> ---
> pve-storage-lvm.adoc | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/pve-storage-lvm.adoc b/pve-storage-lvm.adoc
> index
thanks!
On October 10, 2023 3:24 pm, Aaron Lauterer wrote:
> Signed-off-by: Aaron Lauterer
> Reviewed-by: Fiona Ebner
> ---
> changes since v2: fixed missing trailing comma
>
> www/manager6/storage/DirEdit.js | 4
> www/manager6/storage/LVMEdit.js | 4
> 2 files changed, 8
thanks to both of you!
On December 22, 2023 10:58 am, Stefan Hanreich wrote:
> Since LVM 2.03.15 RBD devices are also scanned by default [1]. This
> can lead to guest volumes being recognized and displayed on the host
> when using KRBD for RBD-backed disks. In order to prevent this we add
> an
with a small cleanup as follow-up, as discussed off-list.
thanks!
On January 3, 2024 2:41 pm, Fiona Ebner wrote:
> The QMP command needs to be issued for the device where the disk is
> currently attached, not for the device where the disk was attached at
> the time the snapshot was taken.
>
>
On December 29, 2023 1:41 pm, Friedrich Weber wrote:
> I started testing this and will send a complete mail later, just wanted
> to mention one thing I've stumbled upon.
>
> Consider this pre-upgrade lvm.conf:
>
> devices {
> # added by pve-manager to avoid scanning ZFS zvols
>
> Esi Y via pve-devel hat am 09.01.2024 06:01 CET
> geschrieben:
> On Thu, Dec 21, 2023 at 10:53:11AM +0100, Fabian Grünbichler wrote:
> > RFC since this would be a bigger change in how we approach intra-cluster
> > SSH access.
> >
> > there are still a few parts that currently don't use
28 matches
Mail list logo
