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)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 2D0A4997B for ; Fri, 18 Nov 2022 12:11:04 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id DD8DE376BA for ; Fri, 18 Nov 2022 12:10:33 +0100 (CET) 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 ; Fri, 18 Nov 2022 12:10:31 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 4CDBE44CF9 for ; Fri, 18 Nov 2022 12:10:30 +0100 (CET) From: Matthias Heiserer To: pve-devel@lists.proxmox.com Date: Fri, 18 Nov 2022 12:09:47 +0100 Message-Id: <20221118110949.59298-7-m.heiserer@proxmox.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20221118110949.59298-1-m.heiserer@proxmox.com> References: <20221118110949.59298-1-m.heiserer@proxmox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: =?UTF-8?Q?0=0A=09?=AWL -0.176 Adjusted score from AWL reputation of From: =?UTF-8?Q?address=0A=09?=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 =?UTF-8?Q?Alignment=0A=09?=SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF =?UTF-8?Q?Record=0A=09?=SPF_PASS -0.001 SPF: sender matches SPF record Subject: [pve-devel] [PATCH docs 7/9] local-zfs: rephrase ZFS RAID description 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, 18 Nov 2022 11:11:04 -0000 I tried to make the performance impact clearer, as what "behave like a number of disks" actually means wasn't quite clear to me. Use "in regard to" rather than "in regard of", as I couldn't find any source that this phrase is (commonly) used in modern english. Signed-off-by: Matthias Heiserer --- local-zfs.adoc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/local-zfs.adoc b/local-zfs.adoc index 6afc110..0fa06b0 100644 --- a/local-zfs.adoc +++ b/local-zfs.adoc @@ -167,17 +167,17 @@ Each `vdev` type has different performance behaviors. The two parameters of interest are the IOPS (Input/Output Operations per Second) and the bandwidth with which data can be written or read. -A 'mirror' vdev (RAID1) will approximately behave like a single disk in regards -to both parameters when writing data. When reading data if will behave like the -number of disks in the mirror. +A 'mirror' vdev (RAID1) will approximately behave like a single disk in regard +to both parameters when writing data. When reading data the performance will +scale linearly with the number of disks in the mirror. A common situation is to have 4 disks. When setting it up as 2 mirror vdevs (RAID10) the pool will have the write characteristics as two single disks in -regard of IOPS and bandwidth. For read operations it will resemble 4 single +regard to IOPS and bandwidth. For read operations it will resemble 4 single disks. A 'RAIDZ' of any redundancy level will approximately behave like a single disk -in regard of IOPS with a lot of bandwidth. How much bandwidth depends on the +in regard to IOPS with a lot of bandwidth. How much bandwidth depends on the size of the RAIDZ vdev and the redundancy level. For running VMs, IOPS is the more important metric in most situations. -- 2.30.2