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 v2 pve-storage 1/2] lvmplugin: use blkdiscard when supported instead cstream to saferemove drive
Date: Wed, 22 Oct 2025 10:22:25 +0200	[thread overview]
Message-ID: <c1cf0323-231b-44f4-be1e-cb629c35aa4d@proxmox.com> (raw)
In-Reply-To: <mailman.160.1761055268.362.pve-devel@lists.proxmox.com>

It's v4 not v2.

Am 21.10.25 um 4:01 PM schrieb Alexandre Derumier via pve-devel:
> diff --git a/src/PVE/Storage/LVMPlugin.pm b/src/PVE/Storage/LVMPlugin.pm
> index 0416c9e..1c633a3 100644
> --- a/src/PVE/Storage/LVMPlugin.pm
> +++ b/src/PVE/Storage/LVMPlugin.pm
> @@ -3,10 +3,11 @@ package PVE::Storage::LVMPlugin;
>  use strict;
>  use warnings;
>  
> +use Cwd 'abs_path';
>  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);
>  
> @@ -284,23 +285,40 @@ my sub free_lvm_volumes {
>  
>      my $vg = $scfg->{vgname};
>  
> -    # 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};
> +    my $secure_delete_cmd = sub {
> +        my ($lvmpath) = @_;
> +
> +        my $stepsize = $scfg->{'saferemove-stepsize'} // 32;
> +        $stepsize = $stepsize * 1024 * 1024;
> +
> +        my $bdev = abs_path($lvmpath);
> +
> +        my $sysdir = undef;
> +        if ($bdev && $bdev =~ m|^/dev/(dm-\d+)|) {
> +            $sysdir = "/sys/block/$1";
> +        } else {
> +            warn "skip secure delete. lvm volume don't seem to be activated\n";
> +            return;
>          }
> -        for my $name (@$volnames) {
> -            print "zero-out data on image $name (/dev/$vg/del-$name)\n";
> +
> +        my $write_zeroes_max_bytes =
> +            file_read_firstline("$sysdir/queue/write_zeroes_max_bytes") // 0;
> +        ($write_zeroes_max_bytes) = $write_zeroes_max_bytes =~ m/^(\d+)$/; #untaint
> +
> +        if ($write_zeroes_max_bytes == 0) {

What if a storage supports discard, but this value is zero? Then we'd
fall back to the slow method even if we don't need to.

> +            # if storage don't support write zeroes, we fallback to cstream
> +            # 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};
> +            }
>  
>              my $cmd = [
>                  '/usr/bin/cstream',
>                  '-i',
>                  '/dev/zero',
>                  '-o',
> -                "/dev/$vg/del-$name",
> +                $lvmpath,
>                  '-T',
>                  '10',
>                  '-v',
> @@ -318,6 +336,47 @@ my sub free_lvm_volumes {
>              };
>              warn $@ if $@;
>  
> +        } else {
> +
> +            # 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";
> +
> +                $stepsize = $write_zeroes_max_bytes;

Similar here, we'd also reduce the step size even if later using discard.

> +            }
> +
> +            my $discard_enabled = undef;
> +
> +            if ($scfg->{'saferemove-discard'}) {
> +                my $discard_zeroes_data =
> +                    file_read_firstline("$sysdir/queue/discard_zeroes_data") // 0;

Are you sure this works? See:
https://www.kernel.org/doc/html/v6.17/admin-guide/abi-stable.html#abi-sys-block-disk-queue-discard-zeroes-data

"[RO] Will always return 0. Don’t rely on any specific behavior for
discards, and don’t read this file."

Isn't discard_max_hw_bytes the correct one, which also can be used to
determine the step size:
https://www.kernel.org/doc/html/v6.17/admin-guide/abi-stable.html#abi-sys-block-disk-queue-discard-max-hw-bytes

"[RO] Devices that support discard functionality may have internal
limits on the number of bytes that can be trimmed or unmapped in a
single operation. The discard_max_hw_bytes parameter is set by the
device driver to the maximum number of bytes that can be discarded in a
single operation. Discard requests issued to the device must not exceed
this limit. A discard_max_hw_bytes value of 0 means that the device does
not support discard functionality."

And I'm not sure a limit of 32 MiB makes sense then. If the hardware
supports much more, it should be fine to use that, or? Do we even want
to consider saferemove-stepsize if discard is supported? Of course
depending on what we decide on the description in the schema needs to be
adapted.

> +
> +                if ($discard_zeroes_data == 0) {
> +                    warn "Discard zeroes not supported. Fallback to zeroing.\n";
> +                } else {
> +                    $discard_enabled = 1;
> +                }
> +            }
> +
> +            my $cmd = ['/usr/sbin/blkdiscard', $lvmpath, '-v', '--step', "${stepsize}"];
> +            push @$cmd, '--zeroout' if !$discard_enabled;
> +
> +            eval { run_command($cmd); };
> +            warn $@ if $@;
> +        }
> +    };
> +
> +    # we need to zero out LVM data for security reasons
> +    # and to allow thin provisioning
> +    my $zero_out_worker = sub {
> +        for my $name (@$volnames) {
> +            my $lvmpath = "/dev/$vg/del-$name";
> +            print "zero-out data on image $name ($lvmpath)\n";
> +
> +            $secure_delete_cmd->($lvmpath);
> +
>              $class->cluster_lock_storage(
>                  $storeid,
>                  $scfg->{shared},
> @@ -376,6 +435,17 @@ sub properties {
>              description => "Zero-out data when removing LVs.",
>              type => 'boolean',
>          },
> +        'saferemove-discard' => {
> +            description => "Wipe with discard instead of zeroing.",
> +            type => 'boolean',
> +            default => 0,
> +        },
> +        'saferemove-stepsize' => {
> +            description => "Wipe step size (default 32MB)."

I'd put "Wipe step size in MiB." in the description and put a
"default => 32" via the dedicated key for defaults in the schema.

> +                . "It will be capped to the maximum storage support.",
> +            enum => [qw(1 2 4 8 16 32)],
> +            type => 'integer',
> +        },
>          saferemove_throughput => {
>              description => "Wipe throughput (cstream -t parameter value).",
>              type => 'string',
> @@ -394,6 +464,8 @@ sub options {
>          shared => { optional => 1 },
>          disable => { optional => 1 },
>          saferemove => { optional => 1 },
> +        'saferemove-discard' => { optional => 1 },
> +        'saferemove-stepsize' => { optional => 1 },
>          saferemove_throughput => { optional => 1 },
>          content => { optional => 1 },
>          base => { fixed => 1, optional => 1 },
> -- 
> 2.47.3
> 
> 



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

  reply	other threads:[~2025-10-22  8:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20251021140054.3916467-1-alexandre.derumier@groupe-cyllene.com>
2025-10-21 14:00 ` Alexandre Derumier via pve-devel
2025-10-22  8:22   ` Fiona Ebner [this message]
2025-10-22  9:35     ` DERUMIER, Alexandre via pve-devel
     [not found]     ` <414f3fba72876b4138458b625275892e059378af.camel@groupe-cyllene.com>
2025-10-22  9:43       ` Fiona Ebner
2025-10-21 14:00 ` [pve-devel] [PATCH v2 pve-storage 2/2] fix #6941 : lvmplugin : fix activation on secure delete Alexandre Derumier via pve-devel
2025-10-22  9:12   ` Fiona Ebner
2025-10-22  9:35     ` 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=c1cf0323-231b-44f4-be1e-cb629c35aa4d@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