Date: Sun, 24 Nov 2013 23:53:50 +0000 (UTC) From: Warren Block <wblock@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-projects@freebsd.org Subject: svn commit: r43238 - projects/zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs Message-ID: <201311242353.rAONrovn073313@svn.freebsd.org>
index | next in thread | raw e-mail
Author: wblock Date: Sun Nov 24 23:53:50 2013 New Revision: 43238 URL: http://svnweb.freebsd.org/changeset/doc/43238 Log: Edit for clarity, spelling, and redundancy. Modified: projects/zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs/chapter.xml Modified: projects/zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs/chapter.xml ============================================================================== --- projects/zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs/chapter.xml Sun Nov 24 23:25:14 2013 (r43237) +++ projects/zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs/chapter.xml Sun Nov 24 23:53:50 2013 (r43238) @@ -689,7 +689,7 @@ errors: No known data errors</screen> </sect2> <sect2 xml:id="zfs-zpool-history"> - <title>Displaying recorded Pool history</title> + <title>Displaying Recorded Pool History</title> <para>ZFS records all the commands that were issued to administer the pool. These include the creation of datasets, @@ -709,13 +709,13 @@ History for 'tank': 2013-02-27.18:51:09 zfs set checksum=fletcher4 tank 2013-02-27.18:51:18 zfs create tank/backup</screen> - <para>The command output shows in it's basic form a timestamp - followed by each <command>zpool</command> or - <command>zfs</command> command that was executed on the pool. + <para>The output shows + <command>zpool</command> and + <command>zfs</command> commands that were executed on the pool along with a timestamp. Note that only commands that altered the pool in some way are being recorded. Commands like <command>zfs list</command> are not part of the history. When there is no pool name provided - for <command>zpool history</command> then the history of all + for <command>zpool history</command>, then the history of all pools will be displayed.</para> <para>The <command>zpool history</command> can show even more @@ -758,12 +758,12 @@ History for 'tank': on the other system can clearly be distinguished by the hostname that is recorded for each command.</para> - <para>Both options to the <command>zpool history</command> - command can be combined together to give the most detailed + <para>Both options to <command>zpool history</command> + can be combined to give the most detailed information possible for any given pool. The pool history can - become a valuable information source when tracking down what - actions were performed or when it is needed to provide more - detailed output for debugging a ZFS pool.</para> + be a valuable information source when tracking down what + actions were performed or when more + detailed output is needed for debugging a ZFS pool.</para> </sect2> <sect2 xml:id="zfs-zpool-iostat"> @@ -974,9 +974,9 @@ Filesystem Size Used Avail Cap NAME PROPERTY VALUE SOURCE tank custom:costcenter 1234 local</screen> - <para>To remove such a custom property again, use the - <command>zfs inherit</command> command with the - <option>-r</option> option. If the custom property is not + <para>To remove such a custom property again, use + <command>zfs inherit</command> with + <option>-r</option>. If the custom property is not defined in any of the parent datasets, it will be removed completely (although the changes are still recorded in the pool's history).</para> @@ -1057,7 +1057,7 @@ tank custom:costcenter - that can be consumed by a particular dataset. <link linkend="zfs-term-refquota">Reference Quotas</link> work in very much the same way, except they only count the space used - by the dataset it self, excluding snapshots and child + by the dataset itself, excluding snapshots and child datasets. Similarly <link linkend="zfs-term-userquota">user</link> and <link linkend="zfs-term-groupquota">group</link> quotas can be used @@ -1258,7 +1258,7 @@ for> done</screen> NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT pool 2.84G 20.9M 2.82G 0% 3.00x ONLINE -</screen> - <para>The <literal>DEDUP</literal> column does now contain the + <para>The <literal>DEDUP</literal> column now contains the value <literal>3.00x</literal>. This indicates that ZFS detected the copies of the ports tree data and was able to deduplicate it at a ratio of 1/3. The space savings that this @@ -1269,8 +1269,7 @@ pool 2.84G 20.9M 2.82G 0% 3.00x ONLINE - there is not much redundant data on a ZFS pool. To see how much space could be saved by deduplication for a given set of data that is already stored in a pool, ZFS can simulate the - effects that deduplication would have. To do that, the - following command can be invoked on the pool.</para> + effects that deduplication would have:</para> <screen>&prompt.root; <userinput>zdb -S <replaceable>pool</replaceable></userinput> Simulated DDT histogram: @@ -1293,9 +1292,9 @@ refcnt blocks LSIZE PSIZE DSIZE dedup = 1.05, compress = 1.11, copies = 1.00, dedup * compress / copies = 1.16</screen> - <para>After <command>zdb -S</command> finished analyzing the - pool, it outputs a summary that shows the ratio that would - result in activating deduplication. In this case, + <para>After <command>zdb -S</command> finishes analyzing the + pool, it shows the space reduction ratio that would be achieved by + activating deduplication. In this case, <literal>1.16</literal> is a very poor rate that is mostly influenced by compression. Activating deduplication on this pool would not save any significant amount of space. Keeping @@ -1316,8 +1315,8 @@ dedup = 1.05, compress = 1.11, copies = <acronym>ZFS</acronym> dataset to a <link linkend="jails">Jail</link>. <command>zfs jail <replaceable>jailid</replaceable></command> attaches a dataset - to the specified jail, and the <command>zfs unjail</command> - detaches it. In order for the dataset to be administered from + to the specified jail, and <command>zfs unjail</command> + detaches it. For the dataset to be administered from within a jail, the <literal>jailed</literal> property must be set. Once a dataset is jailed it can no longer be mounted on the host, because the jail administrator may have set @@ -1328,46 +1327,45 @@ dedup = 1.05, compress = 1.11, copies = <sect1 xml:id="zfs-zfs-allow"> <title>Delegated Administration</title> - <para>ZFS features a comprehensive delegation system to assign - permissions to perform the various ZFS administration functions - to a regular (non-root) user. For example, if each users' home - directory is a dataset, then each user could be delegated + <para>A comprehensive permission delegation system allows unprivileged + users to perform ZFS administration functions. + For example, if each user's home + directory is a dataset, users can be given permission to create and destroy snapshots of their home - directory. A backup user could be assigned the permissions - required to make use of the ZFS replication features without - requiring root access, or isolate a usage collection script to - run as an unprivileged user with access to only the space - utilization data of all users. It is even possible to delegate - the ability to delegate permissions. ZFS allows to delegate - permissions over each subcommand and most ZFS properties.</para> + directories. A backup user can be given permission + to use ZFS replication features. + A usage statistics script can be allowed to + run with access only to the space + utilization data for all users. It is even possible to delegate + the ability to delegate permissions. Permission delegation is + possible for each subcommand and most ZFS properties.</para> <sect2 xml:id="zfs-zfs-allow-create"> <title>Delegating Dataset Creation</title> - <para>Using the <userinput>zfs allow + <para><userinput>zfs allow <replaceable>someuser</replaceable> create - <replaceable>mydataset</replaceable></userinput> command will - give the indicated user the required permissions to create + <replaceable>mydataset</replaceable></userinput> + gives the specified user permission to create child datasets under the selected parent dataset. There is a - caveat: creating a new dataset involves mounting it, which - requires the <literal>vfs.usermount</literal> sysctl to be - enabled in order to allow non-root users to mount a - filesystem. There is another restriction that non-root users - must own the directory they are mounting the filesystem to, in - order to prevent abuse.</para> + caveat: creating a new dataset involves mounting it. + That requires setting the <literal>vfs.usermount</literal> &man.sysctl.8; to <literal>1</literal> + to allow non-root users to mount a + filesystem. There is another restriction aimed at preventing abuse: non-root users + must own the mountpoint where the file system is being mounted.</para> </sect2> <sect2 xml:id="zfs-zfs-allow-allow"> <title>Delegating Permission Delegation</title> - <para>Using the <userinput>zfs allow + <para><userinput>zfs allow <replaceable>someuser</replaceable> allow - <replaceable>mydataset</replaceable></userinput> command will - give the indicated user the ability to assign any permission + <replaceable>mydataset</replaceable></userinput> + gives the specified user the ability to assign any permission they have on the target dataset (or its children) to other users. If a user has the <literal>snapshot</literal> - permission and the <literal>allow</literal> permission that - user can then grant the snapshot permission to some other + permission and the <literal>allow</literal> permission, that + user can then grant the <literal>snapshot</literal> permission to some other users.</para> </sect2> </sect1> @@ -1403,23 +1401,23 @@ dedup = 1.05, compress = 1.11, copies = <title>ZFS on i386</title> <para>Some of the features provided by <acronym>ZFS</acronym> - are RAM-intensive, so some tuning may be required to provide + are RAM-intensive, and may require tuning for maximum efficiency on systems with limited <acronym>RAM</acronym>.</para> <sect3> <title>Memory</title> - <para>At a bare minimum, the total system memory should be at + <para>As a bare minimum, the total system memory should be at least one gigabyte. The amount of recommended <acronym>RAM</acronym> depends upon the size of the pool and - the <acronym>ZFS</acronym> features which are used. A + which <acronym>ZFS</acronym> features are used. A general rule of thumb is 1 GB of RAM for every 1 TB of storage. If the deduplication feature is used, a general rule of thumb is 5 GB of RAM per TB of storage to be deduplicated. While some users successfully use <acronym>ZFS</acronym> with less <acronym>RAM</acronym>, - it is possible that when the system is under heavy load, it + systems under heavy load may panic due to memory exhaustion. Further tuning may be required for systems with less than the recommended RAM requirements.</para> @@ -1429,19 +1427,19 @@ dedup = 1.05, compress = 1.11, copies = <title>Kernel Configuration</title> <para>Due to the <acronym>RAM</acronym> limitations of the - &i386; platform, users using <acronym>ZFS</acronym> on the - &i386; architecture should add the following option to a + &i386; platform, <acronym>ZFS</acronym> users on the + &i386; architecture should add this option to a custom kernel configuration file, rebuild the kernel, and reboot:</para> <programlisting>options KVA_PAGES=512</programlisting> - <para>This option expands the kernel address space, allowing + <para>This expands the kernel address space, allowing the <varname>vm.kvm_size</varname> tunable to be pushed beyond the currently imposed limit of 1 GB, or the limit of 2 GB for <acronym>PAE</acronym>. To find the most suitable value for this option, divide the desired - address space in megabytes by four (4). In this example, it + address space in megabytes by four. In this example, it is <literal>512</literal> for 2 GB.</para> </sect3> @@ -1450,8 +1448,8 @@ dedup = 1.05, compress = 1.11, copies = <para>The <filename>kmem</filename> address space can be increased on all &os; architectures. On a test system with - one gigabyte of physical memory, success was achieved with - the following options added to + 1 GB of physical memory, success was achieved with + these options added to <filename>/boot/loader.conf</filename>, and the system restarted:</para> @@ -1638,12 +1636,12 @@ vfs.zfs.vdev.cache.size="5M"</programlis levels of usable storage. The types are named <acronym>RAID-Z1</acronym> through <acronym>RAID-Z3</acronym> based on the number of - parity devinces in the array and the number of - disks that the pool can operate without.</para> + parity devices in the array and the number of + disks which can fail while the pool remains operational.</para> <para>In a <acronym>RAID-Z1</acronym> configuration - with 4 disks, each 1 TB, usable storage will - be 3 TB and the pool will still be able to + with 4 disks, each 1 TB, usable storage is + 3 TB and the pool will still be able to operate in degraded mode with one faulted disk. If an additional disk goes offline before the faulted disk is replaced and resilvered, all data @@ -1663,7 +1661,7 @@ vfs.zfs.vdev.cache.size="5M"</programlis disks each would create something similar to a <acronym>RAID-60</acronym> array. A <acronym>RAID-Z</acronym> group's storage capacity - is approximately the size of the smallest disk, + is approximately the size of the smallest disk multiplied by the number of non-parity disks. Four 1 TB disks in <acronym>RAID-Z1</acronym> has an effective size of approximately 3 TB, @@ -1749,17 +1747,17 @@ vfs.zfs.vdev.cache.size="5M"</programlis <entry xml:id="zfs-term-l2arc"><acronym>L2ARC</acronym></entry> - <entry>The <acronym>L2ARC</acronym> is the second level + <entry><acronym>L2ARC</acronym> is the second level of the <acronym>ZFS</acronym> caching system. The primary <acronym>ARC</acronym> is stored in - <acronym>RAM</acronym>, however since the amount of + <acronym>RAM</acronym>. Since the amount of available <acronym>RAM</acronym> is often limited, - <acronym>ZFS</acronym> can also make use of + <acronym>ZFS</acronym> can also use <link linkend="zfs-term-vdev-cache">cache</link> vdevs. Solid State Disks (<acronym>SSD</acronym>s) are often used as these cache devices due to their higher speed and lower latency compared to traditional spinning - disks. An <acronym>L2ARC</acronym> is entirely + disks. <acronym>L2ARC</acronym> is entirely optional, but having one will significantly increase read speeds for files that are cached on the <acronym>SSD</acronym> instead of having to be read from @@ -1789,7 +1787,7 @@ vfs.zfs.vdev.cache.size="5M"</programlis <entry xml:id="zfs-term-zil"><acronym>ZIL</acronym></entry> - <entry>The <acronym>ZIL</acronym> accelerates synchronous + <entry><acronym>ZIL</acronym> accelerates synchronous transactions by using storage devices (such as <acronym>SSD</acronym>s) that are faster than those used for the main storage pool. When data is being written @@ -1809,11 +1807,11 @@ vfs.zfs.vdev.cache.size="5M"</programlis <entry xml:id="zfs-term-cow">Copy-On-Write</entry> <entry>Unlike a traditional file system, when data is - overwritten on <acronym>ZFS</acronym> the new data is + overwritten on <acronym>ZFS</acronym>, the new data is written to a different block rather than overwriting the - old data in place. Only once this write is complete is - the metadata then updated to point to the new location - of the data. This means that in the event of a shorn + old data in place. Only when this write is complete is + the metadata then updated to point to the new location. + In the event of a shorn write (a system crash or power loss in the middle of writing a file), the entire original contents of the file are still available and the incomplete write is @@ -1825,23 +1823,23 @@ vfs.zfs.vdev.cache.size="5M"</programlis <row> <entry xml:id="zfs-term-dataset">Dataset</entry> - <entry>Dataset is the generic term for a + <entry><emphasis>Dataset</emphasis> is the generic term for a <acronym>ZFS</acronym> file system, volume, snapshot or - clone. Each dataset will have a unique name in the + clone. Each dataset has a unique name in the format: <literal>poolname/path@snapshot</literal>. The root of the pool is technically a dataset as well. Child datasets are named hierarchically like - directories; for example, + directories. For example, <literal>mypool/home</literal>, the home dataset, is a child of <literal>mypool</literal> and inherits properties from it. This can be expanded further by creating <literal>mypool/home/user</literal>. This grandchild dataset will inherity properties from the - parent and grandparent. It is also possible to set - properties on a child to override the defaults inherited + parent and grandparent. + Properties on a child can be set to override the defaults inherited from the parents and grandparents. - <acronym>ZFS</acronym> also allows administration of - datasets and their children to be <link + Administration of + datasets and their children can be <link linkend="zfs-zfs-allow">delegated</link>.</entry> </row> @@ -1852,7 +1850,7 @@ vfs.zfs.vdev.cache.size="5M"</programlis as a file system. Like most other file systems, a <acronym>ZFS</acronym> file system is mounted somewhere in the systems directory heirarchy and contains files - and directories of its own with permissions, flags and + and directories of its own with permissions, flags, and other metadata.</entry> </row> @@ -1903,7 +1901,7 @@ vfs.zfs.vdev.cache.size="5M"</programlis space. Snapshots can also be marked with a <link linkend="zfs-zfs-snapshot">hold</link>, once a snapshot is held, any attempt to destroy it will return - an EBUY error. Each snapshot can have multiple holds, + an <literal>EBUSY</literal> error. Each snapshot can have multiple holds, each with a unique name. The <link linkend="zfs-zfs-snapshot">release</link> command removes the hold so the snapshot can then be deleted. @@ -1924,12 +1922,12 @@ vfs.zfs.vdev.cache.size="5M"</programlis overwritten in the cloned file system or volume, the reference count on the previous block is decremented. The snapshot upon which a clone is based cannot be - deleted because the clone is dependeant upon it (the + deleted because the clone depends on it (the snapshot is the parent, and the clone is the child). Clones can be <literal>promoted</literal>, reversing - this dependeancy, making the clone the parent and the + this dependency, making the clone the parent and the previous parent the child. This operation requires no - additional space, however it will change the way the + additional space, but it will change the way the used space is accounted.</entry> </row> @@ -1937,9 +1935,9 @@ vfs.zfs.vdev.cache.size="5M"</programlis <entry xml:id="zfs-term-checksum">Checksum</entry> <entry>Every block that is allocated is also checksummed - (the algorithm used is a per dataset property, see: - <command>zfs set</command>). <acronym>ZFS</acronym> - transparently validates the checksum of each block as it + (the algorithm used is a per dataset property, see + <command>zfs set</command>). The checksum of each block + is transparently validated as it is read, allowing <acronym>ZFS</acronym> to detect silent corruption. If the data that is read does not match the expected checksum, <acronym>ZFS</acronym> will @@ -1967,7 +1965,7 @@ vfs.zfs.vdev.cache.size="5M"</programlis The fletcher algorithms are faster, but sha256 is a strong cryptographic hash and has a much lower chance of collisions at the cost of some performance. Checksums - can be disabled but it is inadvisable.</entry> + can be disabled, but it is inadvisable.</entry> </row> <row> @@ -1977,8 +1975,8 @@ vfs.zfs.vdev.cache.size="5M"</programlis compression property, which defaults to off. This property can be set to one of a number of compression algorithms, which will cause all new data that is - written to this dataset to be compressed as it is - written. In addition to the reduction in disk usage, + written to the dataset to be compressed. + In addition to the reduction in disk usage, this can also increase read and write throughput, as only the smaller compressed version of the file needs to be read or written. @@ -1992,9 +1990,9 @@ vfs.zfs.vdev.cache.size="5M"</programlis <row> <entry xml:id="zfs-term-deduplication">Deduplication</entry> - <entry><acronym>ZFS</acronym> has the ability to detect - duplicate blocks of data as they are written (thanks to - the checksumming feature). If deduplication is enabled, + <entry>Checksums make it possible to detect + duplicate blocks of data as they are written. + If deduplication is enabled, instead of writing the block a second time, the reference count of the existing block will be increased, saving storage space. To do this, @@ -2011,23 +2009,23 @@ vfs.zfs.vdev.cache.size="5M"</programlis matching checksum is assumed to mean that the data is identical. If dedup is set to verify, then the data in the two blocks will be checked byte-for-byte to ensure - it is actually identical and if it is not, the hash - collision will be noted by <acronym>ZFS</acronym> and - the two blocks will be stored separately. Due to the - nature of the <acronym>DDT</acronym>, having to store + it is actually identical. If the data is not identical, the hash + collision will be noted and + the two blocks will be stored separately. Because + <acronym>DDT</acronym> must store the hash of each unique block, it consumes a very large amount of memory (a general rule of thumb is 5-6 GB of ram per 1 TB of deduplicated data). In situations where it is not practical to have enough <acronym>RAM</acronym> to keep the entire <acronym>DDT</acronym> in memory, performance will - suffer greatly as the <acronym>DDT</acronym> will need - to be read from disk before each new block is written. - Deduplication can make use of the + suffer greatly as the <acronym>DDT</acronym> must + be read from disk before each new block is written. + Deduplication can use <acronym>L2ARC</acronym> to store the <acronym>DDT</acronym>, providing a middle ground between fast system memory and slower disks. Consider - using <acronym>ZFS</acronym> compression instead, which + using compression instead, which often provides nearly as much space savings without the additional memory requirement.</entry> </row> @@ -2035,17 +2033,17 @@ vfs.zfs.vdev.cache.size="5M"</programlis <row> <entry xml:id="zfs-term-scrub">Scrub</entry> - <entry>In place of a consistency check like &man.fsck.8;, - <acronym>ZFS</acronym> has the <literal>scrub</literal> - command, which reads all data blocks stored on the pool - and verifies their checksums them against the known good + <entry>Instead of a consistency check like &man.fsck.8;, + <acronym>ZFS</acronym> has the <command>scrub</command>. + <command>scrub</command> reads all data blocks stored on the pool + and verifies their checksums against the known good checksums stored in the metadata. This periodic check of all the data stored on the pool ensures the recovery of any corrupted blocks before they are needed. A scrub is not required after an unclean shutdown, but it is recommended that you run a scrub at least once each - quarter. <acronym>ZFS</acronym> compares the checksum - for each block as it is read in the normal course of + quarter. Checksums + of each block are tested as they are read in normal use, but a scrub operation makes sure even infrequently used blocks are checked for silent corruption.</entry> </row> @@ -2054,7 +2052,7 @@ vfs.zfs.vdev.cache.size="5M"</programlis <entry xml:id="zfs-term-quota">Dataset Quota</entry> <entry><acronym>ZFS</acronym> provides very fast and - accurate dataset, user and group space accounting in + accurate dataset, user, and group space accounting in addition to quotas and space reservations. This gives the administrator fine grained control over how space is allocated and allows critical file systems to reserve @@ -2087,8 +2085,8 @@ vfs.zfs.vdev.cache.size="5M"</programlis Quota</entry> <entry>A reference quota limits the amount of space a - dataset can consume by enforcing a hard limit on the - space used. However, this hard limit includes only + dataset can consume by enforcing a hard limit. + However, this hard limit includes only space that the dataset references and does not include space used by descendants, such as file systems or snapshots.</entry> @@ -2115,10 +2113,10 @@ vfs.zfs.vdev.cache.size="5M"</programlis Reservation</entry> <entry>The <literal>reservation</literal> property makes - it possible to guaranteed a minimum amount of space for - the use of a specific dataset and its descendants. This + it possible to guarantee a minimum amount of space for + a specific dataset and its descendants. This means that if a 10 GB reservation is set on - <filename>storage/home/bob</filename>, if another + <filename>storage/home/bob</filename>, and another dataset tries to use all of the free space, at least 10 GB of space is reserved for this dataset. If a snapshot is taken of @@ -2127,7 +2125,7 @@ vfs.zfs.vdev.cache.size="5M"</programlis reservation. The <link linkend="zfs-term-refreservation">refreservation</link> property works in a similar way, except it - <emphasis>excludes</emphasis> descendants, such as + <emphasis>excludes</emphasis> descendants like snapshots. <para>Reservations of any sort are useful in many @@ -2143,11 +2141,11 @@ vfs.zfs.vdev.cache.size="5M"</programlis Reservation</entry> <entry>The <literal>refreservation</literal> property - makes it possible to guaranteed a minimum amount of + makes it possible to guarantee a minimum amount of space for the use of a specific dataset <emphasis>excluding</emphasis> its descendants. This means that if a 10 GB reservation is set on - <filename>storage/home/bob</filename>, if another + <filename>storage/home/bob</filename>, and another dataset tries to use all of the free space, at least 10 GB of space is reserved for this dataset. In contrast to a regular <link @@ -2168,10 +2166,10 @@ vfs.zfs.vdev.cache.size="5M"</programlis <entry xml:id="zfs-term-resilver">Resilver</entry> <entry>When a disk fails and must be replaced, the new - disk must be filled with the data that was lost. This - process of calculating and writing the missing data - (using the parity information distributed across the - remaining drives) to the new drive is called + disk must be filled with the data that was lost. The + process of using the parity information distributed across the remaining drives + to calculate and write the missing data to the new drive + is called <emphasis>resilvering</emphasis>.</entry> </row> @@ -2194,7 +2192,7 @@ vfs.zfs.vdev.cache.size="5M"</programlis or vdev into a <link linkend="zfs-term-faulted">Faulted</link> state. An administrator may choose to offline a disk in - preperation for replacing it, or to make it easier to + preparation for replacing it, or to make it easier to identify.</entry> </row> @@ -2204,10 +2202,10 @@ vfs.zfs.vdev.cache.size="5M"</programlis <entry>A ZFS pool or vdev that is in the <literal>Degraded</literal> state has one or more disks that have been disconnected or have failed. The pool is - still usable however if additional devices fail the pool + still usable, however if additional devices fail, the pool could become unrecoverable. Reconnecting the missing - device(s) or replacing the failed disks will return the - pool to a <link + devices or replacing the failed disks will return the + pool to an <link linkend="zfs-term-online">Online</link> state after the reconnected or new device has completed the <link linkend="zfs-term-resilver">Resilver</link> @@ -2228,7 +2226,7 @@ vfs.zfs.vdev.cache.size="5M"</programlis linkend="zfs-term-online">Online</link> state. If there is insufficient redundancy to compensate for the number of failed disks, then the contents of the pool - are lost and will need to be restored from + are lost and must be restored from backups.</entry> </row> </tbody>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201311242353.rAONrovn073313>