From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <f.ebner@proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 5F443A144E for <pve-devel@lists.proxmox.com>; Wed, 14 Jun 2023 14:13:38 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 3FEB21BF69 for <pve-devel@lists.proxmox.com>; Wed, 14 Jun 2023 14:13:08 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for <pve-devel@lists.proxmox.com>; Wed, 14 Jun 2023 14:13:06 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 7D77A45324 for <pve-devel@lists.proxmox.com>; Wed, 14 Jun 2023 14:13:06 +0200 (CEST) Message-ID: <ebd3a023-34d8-b3be-e8e8-dda120ec378c@proxmox.com> Date: Wed, 14 Jun 2023 14:13:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US To: Aaron Lauterer <a.lauterer@proxmox.com>, Thomas Lamprecht <t.lamprecht@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20230614112853.1560191-1-a.lauterer@proxmox.com> <6b906c73-1c4d-d29a-ff16-b7c0cf8a692d@proxmox.com> <49511c23-e5f8-4d09-d892-ff7ec4eeb44d@proxmox.com> From: Fiona Ebner <f.ebner@proxmox.com> In-Reply-To: <49511c23-e5f8-4d09-d892-ff7ec4eeb44d@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.002 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.098 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com] Subject: Re: [pve-devel] [PATCH storage] Revert "workaround zfs create -V error for unaligned sizes" X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Wed, 14 Jun 2023 12:13:38 -0000 Am 14.06.23 um 13:44 schrieb Aaron Lauterer: > On 6/14/23 13:38, Thomas Lamprecht wrote: >> Am 14/06/2023 um 13:28 schrieb Aaron Lauterer: >>> This reverts commit cdef3abb25984c369571626b38f97f92a0a2fd15. >>> >>> The bug should be fixed by now [0]. The reproducer doesn't cause any >>> issues in my tests. >>> >>> [0] https://github.com/openzfs/zfs/issues/8541 >> >> hmm, torn on this one; 1 MB aligned images sound not to bad for >> various things, >> and the extra size is rather negligible most of the time so we can >> mostly lose >> here, otoh. it should be callers decision if storage works fine now.. >> >>> >>> Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com> >>> --- >>> AFAICT this has an affect on EFI disks which after this revert will be >>> 528k and not 1M. Similar as if we would store it as a .raw file. >>> >> >> that sounds like it _could_ break stuff.. >> >> @fiona: what was the state with local storage migration and those disk >> size >> mismatches? Or anything else coming to your mind? > > I did a few tests in the meantime. An EFI disk on a directory based > storage will be 528 K and can be moved to a ZFS storage with this patch. > Without it, it will fail, similar to RBD which needs a 1M min size IIRC. Yes, drive mirror will fail if the source and target volume don't have the exact same size: https://bugzilla.proxmox.com/show_bug.cgi?id=3227 so this would be an improvement. Although the proper fix for that bug would need to be made in drive mirror (e.g. by adding an option to allow larger target image). Offline storage export/import for ZFS is currently limited to ZFS<->ZFS anyways. I'm not aware of any issues, but the alignment has been there for a while now ;) There's also similar padding in volume_resize(). Does ZFS also round up automatically there now or do we need to keep that?