public inbox for pve-devel@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 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