attrs: update cephdocs template to quincy

[pve-docs.git] / local-zfs.adoc

diff --git a/local-zfs.adoc b/local-zfs.adoc
index 6afc11011b34168bb6885aede028c0b701b5b561..014f5874b015a259b997d9be78898424e3819c77 100644 (file)
--- 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.
@@ -235,7 +235,7 @@ There are a few options to counter the increased use of space:
 The `volblocksize` property can only be set when creating a ZVOL. The default
 value can be changed in the storage configuration. When doing this, the guest
 needs to be tuned accordingly and depending on the use case, the problem of
-write amplification if just moved from the ZFS layer up to the guest.
+write amplification is just moved from the ZFS layer up to the guest.
 
 Using `ashift=9` when creating the pool can lead to bad
 performance, depending on the disks underneath, and cannot be changed later on.
@@ -311,14 +311,23 @@ manual pages, which can be read with:
 Create a new zpool
 ^^^^^^^^^^^^^^^^^^
 
-To create a new pool, at least one disk is needed. The `ashift` should
-have the same sector-size (2 power of `ashift`) or larger as the
-underlying disk.
+To create a new pool, at least one disk is needed. The `ashift` should have the
+same sector-size (2 power of `ashift`) or larger as the underlying disk.
 
 ----
 # zpool create -f -o ashift=12 <pool> <device>
 ----
 
+[TIP]
+====
+Pool names must adhere to the following rules:
+
+* begin with a letter (a-z or A-Z)
+* contain only alphanumeric, `-`, `_`, `.`, `:` or ` ` (space) characters
+* must *not begin* with one of `mirror`, `raidz`, `draid` or `spare`
+* must not be `log`
+====
+
 To activate compression (see section <<zfs_compression,Compression in ZFS>>):
 
 ----
@@ -406,8 +415,8 @@ As `<device>` it is possible to use more devices, like it's shown in
 Add cache and log to an existing pool
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-If you have a pool without cache and log. First partition the SSD in
-2 partition with `parted` or `gdisk`
+If you have a pool without cache and log, first create 2 partitions on the SSD
+with `parted` or `gdisk`.
 
 IMPORTANT: Always use GPT partition tables.