From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 BE65D7361E for ; Fri, 27 May 2022 13:53:05 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B33D3DAF7 for ; Fri, 27 May 2022 13:53:05 +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 id 22A94DAEE for ; Fri, 27 May 2022 13:53:05 +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 E84F4438B2 for ; Fri, 27 May 2022 13:53:04 +0200 (CEST) Message-ID: <1da1ddc6-bc41-80ad-8120-21984d512a70@proxmox.com> Date: Fri, 27 May 2022 13:53:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-US To: Fabian Ebner , pve-devel@lists.proxmox.com References: <20220512092416.137095-1-m.heiserer@proxmox.com> <5e8f2678-4567-45be-76d3-f6d9f33f1fff@proxmox.com> From: Matthias Heiserer In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.872 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -1.995 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 - Subject: Re: [pve-devel] [PATCH v3 manager 1/2] HDEdit: check iothread by default and move it from advanced section X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2022 11:53:05 -0000 On 20.05.2022 08:52, Fabian Ebner wrote: > Am 19.05.22 um 15:35 schrieb Matthias Heiserer: >> On 18.05.2022 11:40, Fabian Ebner wrote: >>> Am 12.05.22 um 11:24 schrieb Matthias Heiserer: >>>> Existing disks are not changed by this. >>>> Especially in benchmarks, iothreads significantly improve IO >>>> performance. >>>> >>>> >>>> Signed-off-by: Matthias Heiserer >>>> --- >>>> >>>> Changes from v2: >>>> * also check iothread when adding a disk to an existing VM and >>>>   scsi single >>>> * use bind instead of hardcoded true >>> >>> This feels like to much automagic to me, because changes to the checkbox >>> (even if checkbox is for a virtio disk) will change the controller type >>> and vice versa. This also makes it impossible to only set iothread on >>> certain disks or use the "Virtio SCSI single" controller type without >>> setting iothread. >>> >>> Is it possible to instead have the checkbox be invalid with an >>> appropriate error for the user when it's a bad configuration? >> >> Changes to the checkbox already change the Controller to Virtio SCSI >> (single), regardless of what was selected before. Anyways, the automatic >> change only happens in the wizard. >> > > You're right, and I'd argue that the current behavior isn't ideal either > ;). I guess with only a single scsi disk it makes sense to automatically > switch, because the iothread setting would be invalid otherwise. It also > happens for a virtio disk though, where the scsi controller type isn't > even visible in the disk edit tab. One can still argue that it's just > not relevant there. But we switched to using a multi-disk panel some > time ago, and in that context it's just confusing, because changes to > each iothread checkbox will affect the scsi controller type. > I send in a v4, please take a look. There is still no warning for bad configurations, rather, I removed the bin. Now, you can configure all disks individually, with SCSI single and iothread enabled still being the default. The iothread are still binded to the scsi controller, so if someone were to change some iothread settings, go back to the controller, set it to something other than SCSI single, then change it back to scsi single, the iothread configuration would be lost/all enabled. Please let me know what you think about it, if it's closer to what you have in mind.