D774.diff
No OneTemporary
Actions

Size

22 KB

Referenced Files

None

Subscribers

None

D774.diff
View Options

	Index: en_US.ISO8859-1/books/handbook/zfs/chapter.xml
	===================================================================
	--- en_US.ISO8859-1/books/handbook/zfs/chapter.xml
	+++ en_US.ISO8859-1/books/handbook/zfs/chapter.xml
	@@ -143,6 +143,13 @@
	<filename><replaceable>ada</replaceable></filename> device
	names.</para>

	+ <para>The first step in creating a new <acronym>ZFS</acronym> pool
	+ is deciding on the disk layout. There are a number of options
	+ and once the pool is created, the layout cannot be changed.
	+ For more information see <link
	+ linkend="zfs-advanced-layout">Advanced Topics - Pool
	+ Layout</link>.</para>
	+
	<sect2 xml:id="zfs-quickstart-single-disk-pool">
	<title>Single Disk Pool</title>

	@@ -460,11 +467,11 @@
	upon creation of file systems.</para>

	<warning>
	- <para>Checksums can be disabled, but it is
	- <emphasis>not</emphasis> recommended! Checksums take very
	- little storage space and provide data integrity. Many
	- <acronym>ZFS</acronym> features will not work properly with
	- checksums disabled. There is no noticeable performance gain
	+ <para>Checksums can be, but should never be disabled. The
	+ storage space for the checksum is a fixed part of the
	+ metadata, so no space is saved by disabling checksums.
	+ Many features will not work properly without checksums and
	+ there is also no noticeable performance gain
	from disabling these checksums.</para>
	</warning>

	@@ -715,13 +722,13 @@
	as for <acronym>RAID-Z</acronym>, an alternative method is to
	add another vdev to the pool. Additional vdevs provide higher
	performance, distributing writes across the vdevs. Each vdev
	- is responsible for providing its own redundancy. It is
	- possible, but discouraged, to mix vdev types, like
	+ is responsible for providing its own redundancy. Do not mix
	+ different vdev types, like
	<literal>mirror</literal> and <literal>RAID-Z</literal>.
	Adding a non-redundant vdev to a pool containing mirror or
	<acronym>RAID-Z</acronym> vdevs risks the data on the entire
	pool. Writes are distributed, so the failure of the
	- non-redundant disk will result in the loss of a fraction of
	+ non-redundant vdev will result in the loss of a fraction of
	every block that has been written to the pool.</para>

	<para>Data is striped across each of the vdevs. For example,
	@@ -730,8 +737,8 @@
	of mirrors. Space is allocated so that each vdev reaches 100%
	full at the same time. There is a performance penalty if the
	vdevs have different amounts of free space, as a
	- disproportionate amount of the data is written to the less
	- full vdev.</para>
	+ disproportionate amount of the data is written to the vdev
	+ that is less full.</para>

	<para>When attaching additional devices to a boot pool, remember
	to update the bootcode.</para>
	@@ -2171,7 +2178,7 @@
	<acronym>ZFS</acronym> will issue this warning:</para>

	<screen>&prompt.root; <userinput>zfs list -rt snapshot <replaceable>mypool/var/tmp</replaceable></userinput>
	-AME USED AVAIL REFER MOUNTPOINT
	+NAME USED AVAIL REFER MOUNTPOINT
	mypool/var/tmp@my_recursive_snapshot 88K - 152K -
	mypool/var/tmp@after_cp 53.5K - 118K -
	mypool/var/tmp@diff_snapshot 0 - 120K -
	@@ -2265,7 +2272,7 @@
	cp: /var/tmp/.zfs/snapshot/after_cp/rc.conf: Read-only file system</screen>

	<para>The error reminds the user that snapshots are read-only
	- and can not be changed after creation. No files can be
	+ and cannot be changed after creation. No files can be
	copied into or removed from snapshot directories because
	that would change the state of the dataset they
	represent.</para>
	@@ -2290,99 +2297,140 @@
	<sect2 xml:id="zfs-zfs-clones">
	<title>Managing Clones</title>

	- <para>A clone is a copy of a snapshot that is treated more like
	- a regular dataset. Unlike a snapshot, a clone is not read
	- only, is mounted, and can have its own properties. Once a
	- clone has been created using <command>zfs clone</command>, the
	- snapshot it was created from cannot be destroyed. The
	- child/parent relationship between the clone and the snapshot
	- can be reversed using <command>zfs promote</command>. After a
	- clone has been promoted, the snapshot becomes a child of the
	- clone, rather than of the original parent dataset. This will
	- change how the space is accounted, but not actually change the
	- amount of space consumed. The clone can be mounted at any
	- point within the <acronym>ZFS</acronym> file system hierarchy,
	- not just below the original location of the snapshot.</para>
	-
	- <para>To demonstrate the clone feature, this example dataset is
	- used:</para>
	-
	- <screen>&prompt.root; <userinput>zfs list -rt all <replaceable>camino/home/joe</replaceable></userinput>
	-NAME USED AVAIL REFER MOUNTPOINT
	-camino/home/joe 108K 1.3G 87K /usr/home/joe
	-camino/home/joe@plans 21K - 85.5K -
	-camino/home/joe@backup 0K - 87K -</screen>
	-
	- <para>A typical use for clones is to experiment with a specific
	- dataset while keeping the snapshot around to fall back to in
	- case something goes wrong. Since snapshots can not be
	- changed, a read/write clone of a snapshot is created. After
	- the desired result is achieved in the clone, the clone can be
	- promoted to a dataset and the old file system removed. This
	- is not strictly necessary, as the clone and dataset can
	- coexist without problems.</para>
	-
	- <screen>&prompt.root; <userinput>zfs clone <replaceable>camino/home/joe</replaceable>@<replaceable>backup</replaceable> <replaceable>camino/home/joenew</replaceable></userinput>
	-&prompt.root; <userinput>ls /usr/home/joe*</userinput>
	-/usr/home/joe:
	-backup.txz plans.txt
	-
	-/usr/home/joenew:
	-backup.txz plans.txt
	-&prompt.root; <userinput>df -h /usr/home</userinput>
	-Filesystem Size Used Avail Capacity Mounted on
	-usr/home/joe 1.3G 31k 1.3G 0% /usr/home/joe
	-usr/home/joenew 1.3G 31k 1.3G 0% /usr/home/joenew</screen>
	-
	- <para>After a clone is created it is an exact copy of the state
	- the dataset was in when the snapshot was taken. The clone can
	- now be changed independently from its originating dataset.
	- The only connection between the two is the snapshot.
	- <acronym>ZFS</acronym> records this connection in the property
	- <literal>origin</literal>. Once the dependency between the
	- snapshot and the clone has been removed by promoting the clone
	- using <command>zfs promote</command>, the
	- <literal>origin</literal> of the clone is removed as it is now
	- an independent dataset. This example demonstrates it:</para>
	-
	- <screen>&prompt.root; <userinput>zfs get origin <replaceable>camino/home/joenew</replaceable></userinput>
	-NAME PROPERTY VALUE SOURCE
	-camino/home/joenew origin camino/home/joe@backup -
	-&prompt.root; <userinput>zfs promote <replaceable>camino/home/joenew</replaceable></userinput>
	-&prompt.root; <userinput>zfs get origin <replaceable>camino/home/joenew</replaceable></userinput>
	-NAME PROPERTY VALUE SOURCE
	-camino/home/joenew origin - -</screen>
	-
	- <para>After making some changes like copying
	- <filename>loader.conf</filename> to the promoted clone, for
	- example, the old directory becomes obsolete in this case.
	- Instead, the promoted clone can replace it. This can be
	- achieved by two consecutive commands: <command>zfs
	- destroy</command> on the old dataset and <command>zfs
	- rename</command> on the clone to name it like the old
	- dataset (it could also get an entirely different name).</para>
	-
	- <screen>&prompt.root; <userinput>cp <replaceable>/boot/defaults/loader.conf</replaceable> <replaceable>/usr/home/joenew</replaceable></userinput>
	-&prompt.root; <userinput>zfs destroy -f <replaceable>camino/home/joe</replaceable></userinput>
	-&prompt.root; <userinput>zfs rename <replaceable>camino/home/joenew</replaceable> <replaceable>camino/home/joe</replaceable></userinput>
	-&prompt.root; <userinput>ls /usr/home/joe</userinput>
	-backup.txz loader.conf plans.txt
	-&prompt.root; <userinput>df -h <replaceable>/usr/home</replaceable></userinput>
	-Filesystem Size Used Avail Capacity Mounted on
	-usr/home/joe 1.3G 128k 1.3G 0% /usr/home/joe</screen>
	-
	- <para>The cloned snapshot is now handled like an ordinary
	- dataset. It contains all the data from the original snapshot
	- plus the files that were added to it like
	- <filename>loader.conf</filename>. Clones can be used in
	- different scenarios to provide useful features to ZFS users.
	- For example, jails could be provided as snapshots containing
	- different sets of installed applications. Users can clone
	- these snapshots and add their own applications as they see
	- fit. Once they are satisfied with the changes, the clones can
	- be promoted to full datasets and provided to end users to work
	- with like they would with a real dataset. This saves time and
	- administrative overhead when providing these jails.</para>
	+ <para>A clone is an exact copy of a snapshot that is treated
	+ like a regular dataset. Unlike a snapshot, the clone can
	+ be changed independently from its originating dataset. A
	+ clone can be written to, mounted, and have its own dataset
	+ properties. Similar to how snapshots works, a clone shares
	+ unmodified blocks with the <literal>origin</literal> snapshot
	+ it was created from. This converves space, as the clone only consumes additional space when it is
	+ modified. A clone can only be created from a snapshot.</para>
	+
	+ <para>Create a snapshot of a file system, then clone it:</para>
	+
	+ <screen>&prompt.root; <userinput>echo "first message" > <filename>/var/tmp/my_message</filename></userinput>
	+&prompt.root; <userinput>ls /var/tmp</userinput>
	+my_message vi.recover
	+&prompt.root; <userinput>zfs snapshot <replaceable>mypool/var/tmp@first_snapshot</replaceable></userinput>
	+&prompt.root; <userinput>zfs list -rt all <replaceable>mypool/var/tmp</replaceable></userinput>
	+NAME USED AVAIL REFER MOUNTPOINT
	+mypool/var/tmp 249K 30.5G 249K /var/tmp
	+mypool/var/tmp@first_snapshot 0 - 249K -
	+&prompt.root; <userinput>zfs clone <replaceable>mypool/var/tmp@first_snapshot</replaceable> <replaceable>mypool/var/clone</replaceable></userinput>
	+&prompt.root; <userinput>zfs list -rt all <replaceable>mypool/var/clone</replaceable> <replaceable>mypool/var/tmp</replaceable></userinput>
	+NAME USED AVAIL REFER MOUNTPOINT
	+mypool/var/clone 12.8K 30.5G 249K /var/clone
	+mypool/var/tmp 249K 30.5G 249K /var/tmp
	+mypool/var/tmp@first_snapshot 0 - 249K -
	+&prompt.root; <userinput>ls /var/clone</userinput>
	+my_message vi.recover</screen>
	+
	+ <para>A clone is essentially a fork of a file system, a common
	+ base set of blocks that are shared by two file systems. When
	+ a file is modified in a clone, additional space is consumed.
	+ The original blocks are kept intact because they are still
	+ being used by the first file system and any snapshots that belong to it.
	+ When a file is modified in the first file system, additional
	+ space is consumed again, this time allocated to the snapshot.
	+ The original blocks are still in use, now only by the
	+ snapshot. The system now contains all three versions of the
	+ file.</para>
	+
	+ <para>One common use case for clones is for experimenting with a
	+ dataset while preverving the original.
	+ Clones can also be useful for
	+ databases, jails, and virtual machines. Clones allow the
	+ administrator to create multiple nearly identical versions of
	+ the original without consuming additional space. Clones can be
	+ kept indefinitely. If the clone achieves the desired result,
	+ it can be promoted to be the parent dataset. The original
	+ file system can then be destroyed.</para>
	+
	+ <para>Make a change to the clone, and then the parent:</para>
	+
	+ <screen>&prompt.root; <userinput>echo "clone message" > <filename>/var/clone/my_message</filename></userinput>
	+&prompt.root; <userinput>zfs list -rt all <replaceable>mypool/var/clone</replaceable> <replaceable>mypool/var/tmp</replaceable></userinput>
	+NAME USED AVAIL REFER MOUNTPOINT
	+mypool/var/clone 134K 30.5G 249K /var/clone
	+mypool/var/tmp 249K 30.5G 249K /var/tmp
	+mypool/var/tmp@first_snapshot 0 - 249K -
	+&prompt.root; <userinput>echo "new message" > <filename>/var/tmp/my_message</filename></userinput>
	+&prompt.root; <userinput>zfs list -rt all <replaceable>mypool/var/clone</replaceable> <replaceable>mypool/var/tmp</replaceable></userinput>
	+NAME USED AVAIL REFER MOUNTPOINT
	+mypool/var/clone 134K 30.5G 249K /var/clone
	+mypool/var/tmp 383K 30.5G 249K /var/tmp
	+mypool/var/tmp@first_snapshot 134K - 249K -</screen>
	+
	+ <para>After a clone has been created, the snapshot it was
	+ created from cannot be destroyed because the clone only
	+ contains the blocks that have been modified. The child/parent
	+ relationship between the clone and the snapshot can be
	+ reversed using <command>zfs promote</command>. The snapshot
	+ then becomes a child of the clone, rather than of the original
	+ parent dataset. The original dataset can then be destroyed if
	+ desired. The way that space usage is recorded changes when a clone
	+ is promoted. The same amount of space is used, but which of
	+ the blocks are owned by the parent and the child
	+ changes.</para>
	+
	+ <para>The only connection between the clone and the original
	+ dataset is the snapshot. The
	+ connection is recorded in the <literal>origin</literal> property.
	+ The dependency between the clone and the original dataset is
	+ reversed by
	+ <command>zfs promote</command>. The original dataset becomes
	+ the clone. The <literal>origin</literal> property on the
	+ clone will then be blank. The <literal>origin</literal>
	+ property on the original dataset now point to the
	+ snapshot under the dataset that was formerly the clone.</para>
	+
	+ <para>Promote the clone:</para>
	+
	+ <screen>&prompt.root; <userinput>zfs list -rt all <replaceable>mypool/var/clone</replaceable> <replaceable>mypool/var/tmp</replaceable></userinput>
	+NAME USED AVAIL REFER MOUNTPOINT
	+mypool/var/clone 134K 30.5G 249K /var/clone
	+mypool/var/tmp 383K 30.5G 249K /var/tmp
	+mypool/var/tmp@first_snapshot 134K - 249K -
	+&prompt.root; <userinput>zfs get origin <replaceable>mypool/var/clone</replaceable></userinput>
	+NAME PROPERTY VALUE SOURCE
	+mypool/var/clone origin mypool/var/tmp@first_snapshot -
	+&prompt.root; <userinput>zfs promote <replaceable>mypool/var/clone</replaceable></userinput>
	+&prompt.root; <userinput>zfs list -rt all <replaceable>mypool/var/clone</replaceable> <replaceable>mypool/var/tmp</replaceable></userinput>
	+NAME USED AVAIL REFER MOUNTPOINT
	+mypool/var/clone 383K 30.5G 249K /var/clone
	+mypool/var/clone@first_snapshot 134K - 249K -
	+mypool/var/tmp 134K 30.5G 249K /var/tmp
	+&prompt.root; <userinput>zfs get origin <replaceable>mypool/var/clone</replaceable></userinput>
	+NAME PROPERTY VALUE SOURCE
	+mypool/var/clone origin - -
	+&prompt.root; <userinput>zfs get origin <replaceable>mypool/var/tmp</replaceable></userinput>
	+NAME PROPERTY VALUE SOURCE
	+mypool/var/tmp origin mypool/var/clone@first_snapshot -</screen>
	+
	+ <para>After making changes to the clone, it is now in
	+ the state wanted by the administrator. The old dataset has
	+ is obsolete and the administrator wants to replace it
	+ with the clone. After the clone is promoted, this can be
	+ achieved with two additional commands: <command>zfs
	+ destroy</command> the old dataset and <command>zfs
	+ rename</command> the clone to the name of the old dataset.
	+ The clone could also keep its original name, and only change
	+ its <literal>mountpoint</literal> property instead.</para>
	+
	+ <screen>&prompt.root; <userinput>zfs destroy -f <replaceable>mypool/var/tmp</replaceable></userinput>
	+&prompt.root; <userinput>zfs rename <replaceable>mypool/var/clone</replaceable> <replaceable>mypool/var/tmp</replaceable></userinput>
	+&prompt.root; <userinput>zfs list -rt all <replaceable>mypool/var/tmp</replaceable></userinput>
	+NAME USED AVAIL REFER MOUNTPOINT
	+mypool/var/tmp 383K 30.5G 249K /var/tmp
	+mypool/var/tmp@first_snapshot 134K - 249K -</screen>
	+
	+ <para>The original clone is now an ordinary dataset. It
	+ contains all the data from the original snapshot plus the
	+ files that were added or modified. Any changes made to the
	+ original dataset after the snapshot was created will be
	+ destroyed. Now that there are no other datasets
	+ depending on the snapshot, it can be destroyed as
	+ well.</para>
	</sect2>

	<sect2 xml:id="zfs-zfs-send">
	@@ -3041,6 +3089,55 @@
	<sect1 xml:id="zfs-advanced">
	<title>Advanced Topics</title>

	+ <sect2 xml:id="zfs-advanced-layout">
	+ <title>Pool Layout</title>
	+
	+ <para>Choosing the type of <link
	+ linkend="zfs-term-vdev">vdevs</link> for construct a
	+ pool requires deciding which factors are most important. The
	+ main considerations for a pool are: redundancy, capacity, and
	+ performance.</para>
	+
	+ <para><link linkend="zfs-term-vdev-mirror">Mirrors</link>
	+ provide the best performance in terms of operations per second
	+ (<acronym>IOPS</acronym>). With a mirror, every disk in a
	+ vdev can be used to service reads, because each disk in the vdev
	+ contains a complete copy of the data. Mirrors provide good
	+ redundancy. Each disk in a vdev contains a complete copy
	+ of the data and a mirror vdev can consist of many disks. The
	+ downside to mirrors is that they provide the worst space efficiency and total capacity.
	+ Each mirror vdev, no matter how many disks it contains,
	+ provides only the capacity of the smallest disk. Multiple
	+ mirror vdevs can be striped together (similar to RAID-10) to
	+ provide more capacity, but the usable capacity will usually be
	+ less than the same number of disks in RAID-Z.</para>
	+
	+ <para><link linkend="zfs-term-vdev-raidz">RAID-Z</link> comes in
	+ a number of levels of redundancy. RAID-Z1 provides enough
	+ redundancy to withstand the failure of a single disk in each
	+ vdev. RAID-Z2 can withstand two disks failing at the same time, and Z3
	+ can withstand three, without any data loss.
	+ Choosing between these levels allows the
	+ administrator to balance redundancy against
	+ usable capacity. Each RAID-Z vdev will provide
	+ storage capacity equal to the number of disks, less the level
	+ of redundancy, multiplied by the size of the smallest disk.
	+ Examples of the storage calculations are provided in the
	+ <link linkend="zfs-term-vdev-raidz">RAID-Z</link> definition
	+ in the terminology section. Multiple RAID-Z vdevs can be
	+ striped together to create an effective RAID-50 or RAID-60
	+ type array.</para>
	+
	+ <para>Using more vdevs will increase performance.
	+ Each vdev is operated as a unit. The effective speed of an
	+ individual vdev is determined by the speed of the slowest
	+ device. For the best performance, the recommended layout is
	+ many mirror vdevs, but this provides the worst effective
	+ capacity of the possible configurations. For increased
	+ redundancy, an administrator can choose between using RAID-Z2,
	+ Z3, or adding more member disks to each mirror vdev.</para>
	+ </sect2>
	+
	<sect2 xml:id="zfs-advanced-tuning">
	<title>Tuning</title>

	@@ -3173,16 +3270,6 @@

	<listitem>
	<para
	- xml:id="zfs-advanced-tuning-vdev-max_pending"><emphasis><varname>vfs.zfs.vdev.max_pending</varname></emphasis>
	- - Limit the number of pending I/O requests per device.
	- A higher value will keep the device command queue full
	- and may give higher throughput. A lower value will reduce
	- latency. This value can be adjusted at any time with
	- &man.sysctl.8;.</para>
	- </listitem>
	-
	- <listitem>
	- <para
	xml:id="zfs-advanced-tuning-top_maxinflight"><emphasis><varname>vfs.zfs.top_maxinflight</varname></emphasis>
	- Maxmimum number of outstanding I/Os per top-level
	<link linkend="zfs-term-vdev">vdev</link>. Limits the
	@@ -3299,7 +3386,7 @@
	<para
	xml:id="zfs-advanced-tuning-txg-timeout"><emphasis><varname>vfs.zfs.txg.timeout</varname></emphasis>
	- Maximum number of seconds between
	- <link linkend="zfs-term-txg">transaction group</link>s.
	+ <link linkend="zfs-term-txg">transaction groups</link>.
	The current transaction group will be written to the pool
	and a fresh transaction group started if this amount of
	time has elapsed since the previous transaction group. A
	@@ -3608,6 +3695,14 @@
	and an array of eight 1 TB disks in
	<acronym>RAID-Z3</acronym> will yield 5 TB of
	usable space.</para>
	+
	+ <para xml:id="zfs-term-vdev-raidz-optimal">For
	+ optimal performance, it is best to have a power of
	+ 2 (2, 4, 8) number of non-parity drives so that
	+ writes can be distributed evenly. The recommended
	+ configurations are: RAID-Z1: 3, 5, or 9 disks.
	+ RAID-Z2: 6 or 10 disks. RAID-Z3: 5, 7 or 11
	+ disks.</para>
	</listitem>

	<listitem>
	@@ -4065,10 +4160,13 @@
	this property on important datasets provides additional
	redundancy from which to recover a block that does not
	match its checksum. In pools without redundancy, the
	- copies feature is the only form of redundancy. The
	- copies feature can recover from a single bad sector or
	+ <literal>copies</literal> feature is the only form of redundancy. The
	+ <literal>copies</literal> feature can recover from a single bad sector or
	other forms of minor corruption, but it does not protect
	- the pool from the loss of an entire disk.</entry>
	+ the pool from the loss of an entire disk. Each
	+ copy of a block consumes that much additional space in
	+ the file system, but also in any snapshots where that
	+ block has been modified.</entry>
	</row>

	<row>

File Metadata

Mime Type: text/plain
Expires: Sun, Apr 19, 10:27 PM (21 h, 36 m)
Storage Engine: blob
Storage Format: Raw Data
Storage Handle: 31804556
Default Alt Text: D774.diff (22 KB)

D774.diffNo OneTemporaryActions

D774.diffView Options

File Metadata

Event Timeline

D774.diff
No OneTemporary
Actions

D774.diff
View Options