From nobody Thu Apr 25 23:04:30 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1552722525756703.4972031072645; Sat, 16 Mar 2019 00:48:45 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CB3D63084215; Sat, 16 Mar 2019 07:48:43 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7896E60C18; Sat, 16 Mar 2019 07:48:43 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 0DB1B181A137; Sat, 16 Mar 2019 07:48:43 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x2G7mCfT011641 for ; Sat, 16 Mar 2019 03:48:12 -0400 Received: by smtp.corp.redhat.com (Postfix) id 9148526564; Sat, 16 Mar 2019 07:48:12 +0000 (UTC) Received: from localhost.localdomain (unknown [10.35.206.20]) by smtp.corp.redhat.com (Postfix) with ESMTP id A162326565 for ; Sat, 16 Mar 2019 07:48:09 +0000 (UTC) From: Michal Privoznik To: libvir-list@redhat.com Date: Sat, 16 Mar 2019 08:47:58 +0100 Message-Id: <6dc3012059a74f9824bf0f42122924555eae8624.1552722341.git.mprivozn@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH v3 1/2] storage_backend_iscsi_direct: Simplify vol zeroing X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Sat, 16 Mar 2019 07:48:44 +0000 (UTC) Content-Type: text/plain; charset="utf-8" So far we have two branches: either we zero BLOCK_PER_PACKET (currently 128) block at once, or if we're close to the last block then we zero out one block at the time. This is very suboptimal. We know how many block are there left. Might as well just write them all at once. Signed-off-by: Michal Privoznik Reviewed-by: Pavel Hrdina --- src/storage/storage_backend_iscsi_direct.c | 26 ++++++++++++---------- 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/src/storage/storage_backend_iscsi_direct.c b/src/storage/stora= ge_backend_iscsi_direct.c index 6283a2836b..5f2dfc0405 100644 --- a/src/storage/storage_backend_iscsi_direct.c +++ b/src/storage/storage_backend_iscsi_direct.c @@ -638,21 +638,23 @@ virStorageBackendISCSIDirectVolWipeZero(virStorageVol= DefPtr vol, return ret; =20 while (lba < nb_block) { - if (nb_block - lba > block_size * BLOCK_PER_PACKET) { + const uint64_t to_write =3D MIN(nb_block - lba + 1, BLOCK_PER_PACK= ET); =20 - if (!(task =3D iscsi_write16_sync(iscsi, lun, lba, data, - block_size * BLOCK_PER_PACKET, - block_size, 0, 0, 0, 0, 0))) - return -1; - scsi_free_scsi_task(task); - lba +=3D BLOCK_PER_PACKET; - } else { - if (!(task =3D iscsi_write16_sync(iscsi, lun, lba, data, block= _size, - block_size, 0, 0, 0, 0, 0))) - return -1; + task =3D iscsi_write16_sync(iscsi, lun, lba, data, + to_write * block_size, + block_size, 0, 0, 0, 0, 0); + + if (!task || + task->status !=3D SCSI_STATUS_GOOD) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("failed to write to LUN %d: %s"), + lun, iscsi_get_error(iscsi)); scsi_free_scsi_task(task); - lba++; + return -1; } + + scsi_free_scsi_task(task); + lba +=3D to_write; } =20 return 0; --=20 2.19.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list From nobody Thu Apr 25 23:04:30 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1552722529833577.5572183631224; Sat, 16 Mar 2019 00:48:49 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 162A0308624A; Sat, 16 Mar 2019 07:48:48 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E5D2D226EE; Sat, 16 Mar 2019 07:48:47 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id A5070181A13C; Sat, 16 Mar 2019 07:48:47 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x2G7mFE8011651 for ; Sat, 16 Mar 2019 03:48:15 -0400 Received: by smtp.corp.redhat.com (Postfix) id 3E91526565; Sat, 16 Mar 2019 07:48:15 +0000 (UTC) Received: from localhost.localdomain (unknown [10.35.206.20]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3E77326564 for ; Sat, 16 Mar 2019 07:48:12 +0000 (UTC) From: Michal Privoznik To: libvir-list@redhat.com Date: Sat, 16 Mar 2019 08:47:59 +0100 Message-Id: <70647a21aafd4d7624850f01771711a42d8083c5.1552722341.git.mprivozn@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH v3 2/2] storageVolWipePattern: Don't take shortcut to refreshPool() X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.49]); Sat, 16 Mar 2019 07:48:48 +0000 (UTC) Content-Type: text/plain; charset="utf-8" In d16f803d780 we've tried to solve an issue that after wiping an image its format might have changed (e.g. from qcow2 to raw) but libvirt wasn't probing the image format. We fixed this by calling virStorageBackendRefreshVolTargetUpdate() which is what refreshPool() would end up calling. But this shortcut is not good enough because the function is called only for local types of volumes (like dir, fs, netfs). But now that more backends support volume wiping we have to call the function with more caution. Signed-off-by: Michal Privoznik Reviewed-by: Pavel Hrdina --- src/storage/storage_driver.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index 95561a0578..496d51b1e0 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -2572,11 +2572,16 @@ storageVolWipePattern(virStorageVolPtr vol, if (rc < 0) goto cleanup; =20 - /* Instead of using the refreshVol, since much changes on the target - * volume, let's update using the same function as refreshPool would - * use when it discovers a volume. The only failure to capture is -1, - * we can ignore -2. */ - if (virStorageBackendRefreshVolTargetUpdate(voldef) =3D=3D -1) + /* For local volumes, Instead of using the refreshVol, since + * much changes on the target volume, let's update using the + * same function as refreshPool would use when it discovers a + * volume. The only failure to capture is -1, we can ignore + * -2. */ + if ((backend->type =3D=3D VIR_STORAGE_POOL_DIR || + backend->type =3D=3D VIR_STORAGE_POOL_FS || + backend->type =3D=3D VIR_STORAGE_POOL_NETFS || + backend->type =3D=3D VIR_STORAGE_POOL_VSTORAGE) && + virStorageBackendRefreshVolTargetUpdate(voldef) =3D=3D -1) goto cleanup; =20 ret =3D 0; --=20 2.19.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list