From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id EB9761FF141 for ; Tue, 30 Jun 2026 14:51:09 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id A122B21472; Tue, 30 Jun 2026 14:51:02 +0200 (CEST) Message-ID: <8f78d025-6cd5-44f1-934e-b21b740cdd5b@proxmox.com> Date: Tue, 30 Jun 2026 14:50:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH docs v7 4/4] fix #7339: lvm: document discard option To: Lukas Sichert , pve-devel@lists.proxmox.com References: <20260616101323.24981-1-l.sichert@proxmox.com> <20260616101323.24981-5-l.sichert@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <20260616101323.24981-5-l.sichert@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1782823816347 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.000 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: G5QBWOOFCVM2HAAO42SOUCVWYZAEQALH X-Message-ID-Hash: G5QBWOOFCVM2HAAO42SOUCVWYZAEQALH X-MailFrom: f.ebner@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Am 16.06.26 um 12:13 PM schrieb Lukas Sichert: > `saferemove_throughput`:: > > -Wipe throughput (`cstream -t` parameter value), up to 10 MiB/s by default. > +Wipe throughput, unlimited by default. As mentioned in patch 1, we should keep the default for the syswrite case. We can mention that if the more efficient zeroing operation is supported, then the default throughput is unlimited. And as discussed off-list: currently we do not look at the throughput at all when BLKZEROOUT is supported. People might be surprised if they have a (left-over) throughput limit configured which suddenly gets applied after we roll out this series. But it can also be considered a bug that it wasn't applied. What we should do is adding a log message that the limit gets applied so that people notice. And adding a recommendation to the docs that if BLKZEROOUT is supported, then removing the limit is recommended (and how to check for support). > > `snapshot-as-volume-chain`:: >