D774.id1607.diff
No OneTemporary
Actions

Size

22 KB

Referenced Files

None

Subscribers

None

D774.id1607.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 can not be changed.
	+ For more information see <link
	+ linkend="zfs-advanced-layout">Advanced Topics - Pool
	+ Layout</link>.</para>
	+
	<sect2>
	<title>Single Disk Pool</title>

	@@ -163,8 +170,8 @@

	<para>This output shows that the <literal>example</literal> pool
	has been created and mounted. It is now accessible as a file
	- system. Files can be created on it and users can browse
	- it:</para>
	+ system. Files can be created on it and users can browse it,
	+ like in this example:</para>

	<screen>&prompt.root; <userinput>cd /example</userinput>
	&prompt.root; <userinput>ls</userinput>
	@@ -465,8 +472,8 @@
	<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
	- from disabling these checksums.</para>
	+ checksums disabled. There is also no noticeable performance
	+ gain from disabling these checksums.</para>
	</warning>

	<para>Checksum verification is known as
	@@ -716,13 +723,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 reponsible for providing its own redundancy. It is
	- possible, but discouraged, to mix vdev types, like
	+ is reponsible 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,
	@@ -731,8 +738,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>
	@@ -1933,7 +1940,7 @@
	<sect3 xml:id="zfs-zfs-snapshot-creation">
	<title>Creating Snapshots</title>

	- <para>Snapshots are created with <command>zfs snapshot
	+ <para>Snapshots are created with <command>zfs snapshot
	<replaceable>dataset</replaceable>@<replaceable>snapshotname</replaceable></command>.
	Adding <option>-r</option> creates a snapshot recursively,
	with the same name on all child datasets.</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 -
	@@ -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 clone is an exact copy of a snapshot that is treated
	+ more 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 can have its own
	+ properties. Similar to how snapshots works, a clone shares
	+ unmodified blocks with the <literal>origin</literal> snapshot
	+ it was created from, saving space, and only growing as 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 its snapshot(s).
	+ 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>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>
	+ dataset while keeping the original around to fall back to in
	+ case something goes wrong. Clones can also be powerful in the
	+ case of databases, jails, and virtual machines, allowing the
	+ administrator to create multiple nearly identical versions of
	+ the original without consuming additional space. Clone can be
	+ kept indefinately, or after the desired result is achieved in
	+ the clone, it can be promoted to be the parent dataset and the
	+ old 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 is counted 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
	+ change.</para>
	+
	+ <para>The only connection between the clone and the original
	+ dataset is the snapshot. <acronym>ZFS</acronym> records this
	+ connection in the <literal>origin</literal> property. Once
	+ the dependency between the clone and the original dataset has
	+ been reversed by promoting the clone using
	+ <command>zfs promote</command>, the original dataset becomes
	+ the clone. The <literal>origin</literal> property on the
	+ clone will then be blank, and the <literal>origin</literal>
	+ property on the original dataset will 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 some changes to the clone, it is now in
	+ the state that the administrator wants. The old dataset has
	+ become obsolete and the administrator wants to replace it
	+ with the clone. After the clone is promoted, this can be
	+ achieved by 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 the
	+ original dataset after the snapshot the clone was based off of
	+ have been destroyed. Now that there is no other dataset
	+ depending on the snapshot, it can now 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 which type of <link
	+ linkend="zfs-term-vdev">vdevs</link> to use to 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, since each disk in the vdev
	+ contains a complete copy of the data. Mirrors provide good
	+ redundancy since 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 capacity,
	+ since 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 concurrent failures, and Z3
	+ can withstand three concurrent failures without any data loss.
	+ Choosing between these levels of redundancy allows the
	+ administrator to balance the level of redundancy against the
	+ amount of 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 separate 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>

	@@ -3182,9 +3279,16 @@
	vdevs to prevent the amount of free space across the vdevs
	from becoming unbalanced, which will reduce read and write
	performance. This value can be adjusted at any time with
	- &man.sysctl.8;.</para>
	+ &man.sysctl.8;.
	+ <note>
	+ <para>In &os; releases after August 10, 2014 this
	+ sysctl is deprecated. ZFS will always write to a
	+ degraded vdev unless it is a non-redundant
	+ vdev.</para></note>
	+ </para>
	</listitem>

	+<!-- In 9.3 this sysctl is replaced by an entire slew of new ones that I do not yet fully understand
	<listitem>
	<para
	xml:id="zfs-advanced-tuning-vdev-max_pending"><emphasis><varname>vfs.zfs.vdev.max_pending</varname></emphasis>
	@@ -3194,6 +3298,7 @@
	latency. This value can be adjusted at any time with
	&man.sysctl.8;.</para>
	</listitem>
	+-->

	<listitem>
	<para
	@@ -3313,7 +3418,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
	@@ -3622,6 +3727,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>
	@@ -4082,7 +4195,10 @@
	copies feature is the only form of redundancy. The
	copies 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, Mar 22, 1:01 AM (12 h, 32 m)
Storage Engine: blob
Storage Format: Raw Data
Storage Handle: 30099858
Default Alt Text: D774.id1607.diff (22 KB)

D774.id1607.diffNo OneTemporaryActions

D774.id1607.diffView Options

File Metadata

Event Timeline

D774.id1607.diff
No OneTemporary
Actions

D774.id1607.diff
View Options