all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Fiona Ebner <f.ebner@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH V3 pve-storage] lvm: use blkdiscard instead cstream to saferemove drive
Date: Mon, 22 Sep 2025 16:06:39 +0200	[thread overview]
Message-ID: <bd65c39a-6f21-484b-8998-8966dc2cd22a@proxmox.com> (raw)
In-Reply-To: <mailman.116.1755518974.385.pve-devel@lists.proxmox.com>

Am 18.08.25 um 2:09 PM schrieb Alexandre Derumier via pve-devel:
> Current cstream implementation is pretty slow as hell, even without throttling.

I'd use either "pretty slow" or "slow as hell"

> use blkdiscard --zeroout instead, which is lot of magnetude faster

should be: "a few magnitudes"

Seems like nice-to-have options given the improvement :)

Mostly nits, but also a question about REQ_OP_WRITE_ZEROES below:

> Signed-off-by: Alexandre Derumier <alexandre.derumier@groupe-cyllene.com>
> ---
>  src/PVE/Storage/LVMPlugin.pm | 74 +++++++++++++++++++++++-------------
>  1 file changed, 48 insertions(+), 26 deletions(-)
> 
> diff --git a/src/PVE/Storage/LVMPlugin.pm b/src/PVE/Storage/LVMPlugin.pm
> index 0416c9e..c3a864e 100644
> --- a/src/PVE/Storage/LVMPlugin.pm
> +++ b/src/PVE/Storage/LVMPlugin.pm
> @@ -6,7 +6,7 @@ use warnings;
>  use File::Basename;
>  use IO::File;
>  
> -use PVE::Tools qw(run_command trim);
> +use PVE::Tools qw(run_command file_read_firstline trim);
>  use PVE::Storage::Plugin;
>  use PVE::JSONSchema qw(get_standard_option);
>  
> @@ -287,35 +287,46 @@ my sub free_lvm_volumes {
>      # we need to zero out LVM data for security reasons
>      # and to allow thin provisioning
>      my $zero_out_worker = sub {
> -        # wipe throughput up to 10MB/s by default; may be overwritten with saferemove_throughput
> -        my $throughput = '-10485760';
> -        if ($scfg->{saferemove_throughput}) {
> -            $throughput = $scfg->{saferemove_throughput};
> -        }
>          for my $name (@$volnames) {
> -            print "zero-out data on image $name (/dev/$vg/del-$name)\n";
> +            my $lvmpath = "/dev/$vg/del-$name";
> +            print "zero-out data on image $name ($lvmpath)\n";
> +
> +            warn
> +                "The 'saferemove_throughput' option set for '${storeid}' is deprecated and will be removed."
> +                if $scfg->{saferemove_throughput};

Please split the string up (too long right now) and add a newline at the
end. It should be an if block rather than post if, since it's multiple
lines.

I'd also go for "and has no effect anymore." rather than "and will be
removed". Would be good to add a reminder comment in the code to remove
the option with PVE 10 (and then, for PVE 10, we can warn/error in the
pve9to10 script if the setting is still present).

> +
> +            my $stepsize = $scfg->{saferemove_stepsize} // 32;
> +            $stepsize = $stepsize * 1048576;

Minor nit, but "$stepsize * 1024 * 1024" would be more readable.

> +
> +            my $bdev = readlink($lvmpath);

I'd prefer abs_path() like we use in other places.

> +            if ($bdev && $bdev =~ m|^../(dm-(\d+))|) {

You don't need to group/capture the \d+

> +                my $sysdir = "/sys/block/$1";
> +
> +                my $write_zeroes_max_bytes =
> +                    file_read_firstline("$sysdir/queue/write_zeroes_max_bytes") // 0;

According to the docs: "The value 0 means that REQ_OP_WRITE_ZEROES
is not supported.", so it makes sense as a fallback too. But do we need
to handle that somehow below, i.e. can --zeroout still be used if the
reported value is 0? Or do we need to fall back to the old way of doing it?

> +                ($write_zeroes_max_bytes) = $write_zeroes_max_bytes =~ m/^(\d+)$/; #untaint
> +
> +                #if the storage support write_zeroes but stepsize is too big, reduce the stepsize to the max possible
> +                if ($write_zeroes_max_bytes > 0 && $stepsize > $write_zeroes_max_bytes) {
> +                    warn
> +                        "reduce stepsize to the maximum supported by the storage : $write_zeroes_max_bytes bytes\n";

Style nit: line too long

> +                    $stepsize = $write_zeroes_max_bytes;
> +                }
> +
> +                my $discard_zeroes_data =
> +                    file_read_firstline("$sysdir/queue/discard_zeroes_data") // 0;
> +                if ($scfg->{saferemove_discard} && $discard_zeroes_data == 0) {
> +                    warn "disabling saferemove_discard as the storage don't support it\n";
> +                    $scfg->{saferemove_discard} = undef;

This should be done with a local variable instead of changing the $scfg
hash.

> +                }
> +            }
>  
>              my $cmd = [
> -                '/usr/bin/cstream',
> -                '-i',
> -                '/dev/zero',
> -                '-o',
> -                "/dev/$vg/del-$name",
> -                '-T',
> -                '10',
> -                '-v',
> -                '1',
> -                '-b',
> -                '1048576',
> -                '-t',
> -                "$throughput",
> +                '/usr/sbin/blkdiscard', $lvmpath, '-v', '--step', "${stepsize}",
>              ];

Style nit: could now be one line

> -            eval {
> -                run_command(
> -                    $cmd,
> -                    errmsg => "zero out finished (note: 'No space left on device' is ok here)",
> -                );
> -            };
> +            push @$cmd, '--zeroout' if !$scfg->{saferemove_discard};
> +
> +            eval { run_command($cmd); };
>              warn $@ if $@;
>  
>              $class->cluster_lock_storage(
> @@ -376,6 +387,15 @@ sub properties {
>              description => "Zero-out data when removing LVs.",
>              type => 'boolean',
>          },
> +        saferemove_discard => {
> +            description => "Wipe with discard instead zeroing.",

Should be: "instead of zeroing"

> +            type => 'boolean',
> +            default => 0,
> +        },
> +        saferemove_stepsize => {
> +            description => "Wipe step size (default 32MB).",

Could mention that it will be capped to what the storage supports

> +            enum => [qw(1 2 4 8 16 32)],

Missing type

> +        },
>          saferemove_throughput => {
>              description => "Wipe throughput (cstream -t parameter value).",
>              type => 'string',

Please adapt the description to mention that it is deprecated and a
reminder comment in the code to remove it with PVE 10.

> @@ -394,6 +414,8 @@ sub options {
>          shared => { optional => 1 },
>          disable => { optional => 1 },
>          saferemove => { optional => 1 },
> +        saferemove_discard => { optional => 1 },
> +        saferemove_stepsize => { optional => 1 },

For new options, we try to use kebab-case rather than snake_case

>          saferemove_throughput => { optional => 1 },
>          content => { optional => 1 },
>          base => { fixed => 1, optional => 1 },

I wonder if we should turn saferemove into a property string with
enabled=BOOLEAN,mode=(zeroout|discard),stepsize=(1|2|4|8|16|32) and
enabled being the default key for backwards compat. But I'm also fine
with having the two properties.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


      reply	other threads:[~2025-09-22 14:06 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-18 12:08 Alexandre Derumier via pve-devel
2025-09-22 14:06 ` 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=bd65c39a-6f21-484b-8998-8966dc2cd22a@proxmox.com \
    --to=f.ebner@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