Date: Thu, 15 Aug 2013 02:01:37 +0000 (UTC) From: Warren Block <wblock@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-projects@freebsd.org Subject: svn commit: r42547 - projects/zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs Message-ID: <201308150201.r7F21b11079224@svn.freebsd.org>
index | next in thread | raw e-mail
Author: wblock Date: Thu Aug 15 02:01:36 2013 New Revision: 42547 URL: http://svnweb.freebsd.org/changeset/doc/42547 Log: Fix numerous punctuation, spelling, and phrasing problems, stuff the chapter full of acronym tags. 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 Thu Aug 15 01:21:23 2013 (r42546) +++ projects/zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs/chapter.xml Thu Aug 15 02:01:36 2013 (r42547) @@ -15,7 +15,7 @@ </authorgroup> </chapterinfo> - <title>The Z File System (ZFS)</title> + <title>The Z File System (<acronym>ZFS</acronym>)</title> <para>The Z file system, originally developed by &sun;, is designed to future proof the file system by removing many of @@ -34,10 +34,10 @@ of the limitations of hardware <acronym>RAID</acronym>.</para> <sect1 id="zfs-differences"> - <title>What Makes ZFS Different</title> + <title>What Makes <acronym>ZFS</acronym> Different</title> - <para>ZFS is significantly different from any previous file system - owing to the fact that it is more than just a file system. ZFS + <para><acronym>ZFS</acronym> is significantly different from any previous file system + owing to the fact that it is more than just a file system. <acronym>ZFS</acronym> combines the traditionally separate roles of volume manager and file system, which provides unique advantages because the file system is now aware of the underlying structure of the disks. @@ -48,17 +48,17 @@ around by presenting the operating system with a single logical disk made up of the space provided by a number of disks, on top of which the operating system placed its file system. Even in - the case of software RAID solutions like - <acronym>GEOM</acronym>, the UFS file system living on top of + the case of software <acronym>RAID</acronym> solutions like + <acronym>GEOM</acronym>, the <acronym>UFS</acronym> file system living on top of the <acronym>RAID</acronym> transform believed that it was - dealing with a single device. ZFS's combination of the volume + dealing with a single device. <acronym>ZFS</acronym>'s combination of the volume manager and the file system solves this and allows the creation of many file systems all sharing a pool of available storage. - One of the biggest advantages to ZFS's awareness of the physical - layout of the disks is that ZFS can grow the existing file + One of the biggest advantages to <acronym>ZFS</acronym>'s awareness of the physical + layout of the disks is that <acronym>ZFS</acronym> can grow the existing file systems automatically when additional disks are added to the pool. This new space is then made available to all of the file - systems. ZFS also has a number of different properties that can + systems. <acronym>ZFS</acronym> also has a number of different properties that can be applied to each file system, creating many advantages to creating a number of different filesystems and datasets rather than a single monolithic filesystem.</para> @@ -69,10 +69,13 @@ <para>There is a start up mechanism that allows &os; to mount <acronym>ZFS</acronym> pools during system initialization. To - set it, issue the following commands:</para> + enable it, add this line to <filename>/etc/rc.conf</filename>:</para> - <screen>&prompt.root; <userinput>echo 'zfs_enable="YES"' >> /etc/rc.conf</userinput> -&prompt.root; <userinput>service zfs start</userinput></screen> + <programlisting>zfs_enable="YES"</programlisting> + + <para>Then start the service:</para> + + <screen>&prompt.root; <userinput>service zfs start</userinput></screen> <para>The examples in this section assume three <acronym>SCSI</acronym> disks with the device names @@ -132,7 +135,7 @@ drwxr-xr-x 21 root wheel 512 Aug 29 2 <screen>&prompt.root; <userinput>zfs set compression=off example/compressed</userinput></screen> - <para>To unmount a file system, issue the following command and + <para>To unmount a file system, use <command>zfs umount</command> and then verify by using <command>df</command>:</para> <screen>&prompt.root; <userinput>zfs umount example/compressed</userinput> @@ -143,7 +146,7 @@ devfs 1 1 0 /dev/ad0s1d 54098308 1032864 48737580 2% /usr example 17547008 0 17547008 0% /example</screen> - <para>To re-mount the file system to make it accessible again, + <para>To re-mount the file system to make it accessible again, use <command>zfs mount</command> and verify with <command>df</command>:</para> <screen>&prompt.root; <userinput>zfs mount example/compressed</userinput> @@ -211,11 +214,11 @@ example/data 17547008 0 175 <para>There is no way to prevent a disk from failing. One method of avoiding data loss due to a failed hard disk is to implement <acronym>RAID</acronym>. <acronym>ZFS</acronym> - supports this feature in its pool design. RAID-Z pools + supports this feature in its pool design. <acronym>RAID-Z</acronym> pools require 3 or more disks but yield more usable space than mirrored pools.</para> - <para>To create a <acronym>RAID</acronym>-Z pool, issue the + <para>To create a <acronym>RAID-Z</acronym> pool, issue the following command and specify the disks to add to the pool:</para> @@ -226,7 +229,7 @@ example/data 17547008 0 175 <acronym>RAID</acronym>-Z configuration is between three and nine. For environments requiring a single pool consisting of 10 disks or more, consider breaking it up into smaller - <acronym>RAID</acronym>-Z groups. If only two disks are + <acronym>RAID-Z</acronym> groups. If only two disks are available and redundancy is a requirement, consider using a <acronym>ZFS</acronym> mirror. Refer to &man.zpool.8; for more details.</para> @@ -312,7 +315,7 @@ devfs 1 1 0 storage 26320512 0 26320512 0% /storage storage/home 26320512 0 26320512 0% /home</screen> - <para>This completes the <acronym>RAID</acronym>-Z + <para>This completes the <acronym>RAID-Z</acronym> configuration. To get status updates about the file systems created during the nightly &man.periodic.8; runs, issue the following command:</para> @@ -325,8 +328,8 @@ storage/home 26320512 0 26320512 <para>Every software <acronym>RAID</acronym> has a method of monitoring its <literal>state</literal>. The status of - <acronym>RAID</acronym>-Z devices may be viewed with the - following command:</para> + <acronym>RAID-Z</acronym> devices may be viewed with this + command:</para> <screen>&prompt.root; <userinput>zpool status -x</userinput></screen> @@ -724,19 +727,19 @@ errors: No known data errors</screen> <para>Some of the features provided by <acronym>ZFS</acronym> are RAM-intensive, so some tuning may be required to provide - maximum efficiency on systems with limited RAM.</para> + 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 - least one gigabyte. The amount of recommended RAM depends - upon the size of the pool and the ZFS features which are - used. A general rule of thumb is 1GB of RAM for every 1TB + 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 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 5GB of RAM per TB of storage to be - deduplicated. While some users successfully use ZFS with - less RAM, it is possible that when the system is under heavy + 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 may panic due to memory exhaustion. Further tuning may be required for systems with less than the recommended RAM requirements.</para> @@ -745,8 +748,8 @@ errors: No known data errors</screen> <sect3> <title>Kernel Configuration</title> - <para>Due to the RAM limitations of the &i386; platform, users - using ZFS on the &i386; architecture should add the + <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 custom kernel configuration file, rebuild the kernel, and reboot:</para> @@ -777,7 +780,7 @@ vfs.zfs.arc_max="40M" vfs.zfs.vdev.cache.size="5M"</programlisting> <para>For a more detailed list of recommendations for - ZFS-related tuning, see <ulink + <acronym>ZFS</acronym>-related tuning, see <ulink url="http://wiki.freebsd.org/ZFSTuningGuide"></ulink>.</para>; </sect3> </sect2> @@ -826,22 +829,22 @@ vfs.zfs.vdev.cache.size="5M"</programlis </sect1> <sect1 id="zfs-term"> - <title>ZFS Features and Terminology</title> + <title><acronym>ZFS</acronym> Features and Terminology</title> - <para>ZFS is a fundamentally different file system because it - is more than just a file system. ZFS combines the roles of + <para><acronym>ZFS</acronym> is a fundamentally different file system because it + is more than just a file system. <acronym>ZFS</acronym> combines the roles of file system and volume manager, enabling additional storage devices to be added to a live system and having the new space available on all of the existing file systems in that pool immediately. By combining the traditionally separate roles, - ZFS is able to overcome previous limitations that prevented - RAID groups being able to grow. Each top level device in a - zpool is called a vdev, which can be a simple disk or a RAID - transformation such as a mirror or RAID-Z array. ZFS file + <acronym>ZFS</acronym> is able to overcome previous limitations that prevented + <acronym>RAID</acronym> groups being able to grow. Each top level device in a + zpool is called a vdev, which can be a simple disk or a <acronym>RAID</acronym> + transformation such as a mirror or <acronym>RAID-Z</acronym> array. <acronym>ZFS</acronym> file systems (called datasets), each have access to the combined - free space of the entire pool. As blocks are allocated the - free space in the pool available to of each file system is - decreased. This approach avoids the common pitfall with + free space of the entire pool. As blocks are allocated from + the pool, the space available to each file system + decreases. This approach avoids the common pitfall with extensive partitioning where free space becomes fragmentated across the partitions.</para> @@ -852,7 +855,7 @@ vfs.zfs.vdev.cache.size="5M"</programlis <entry id="zfs-term-zpool">zpool</entry> <entry>A storage pool is the most basic building block of - ZFS. A pool is made up of one or more vdevs, the + <acronym>ZFS</acronym>. A pool is made up of one or more vdevs, the underlying devices that store the data. A pool is then used to create one or more file systems (datasets) or block devices (volumes). These datasets and volumes @@ -860,14 +863,14 @@ vfs.zfs.vdev.cache.size="5M"</programlis uniquely identified by a name and a <acronym>GUID</acronym>. The zpool also controls the version number and therefore the features available for - use with ZFS. + use with <acronym>ZFS</acronym>. <note> - <para>&os; 9.0 and 9.1 include support for ZFS version - 28. Future versions use ZFS version 5000 with + <para>&os; 9.0 and 9.1 include support for <acronym>ZFS</acronym> version + 28. Future versions use <acronym>ZFS</acronym> version 5000 with feature flags. This allows greater cross-compatibility with other implementations of - ZFS.</para> + <acronym>ZFS</acronym>.</para> </note></entry> </row> @@ -876,8 +879,8 @@ vfs.zfs.vdev.cache.size="5M"</programlis <entry>A zpool is made up of one or more vdevs, which themselves can be a single disk or a group of disks, in - the case of a RAID transform. When multiple vdevs are - used, ZFS spreads data across the vdevs to increase + the case of a <acronym>RAID</acronym> transform. When multiple vdevs are + used, <acronym>ZFS</acronym> spreads data across the vdevs to increase performance and maximize usable space. <itemizedlist> @@ -899,7 +902,7 @@ vfs.zfs.vdev.cache.size="5M"</programlis <listitem> <para id="zfs-term-vdev-file"> <emphasis>File</emphasis> - In addition to - disks, ZFS pools can be backed by regular files, + disks, <acronym>ZFS</acronym> pools can be backed by regular files, this is especially useful for testing and experimentation. Use the full path to the file as the device path in the zpool create command. @@ -930,21 +933,21 @@ vfs.zfs.vdev.cache.size="5M"</programlis <listitem> <para id="zfs-term-vdev-raidz"> - <emphasis><acronym>RAID</acronym>-Z</emphasis> - - ZFS implements RAID-Z, a variation on standard - RAID-5 that offers better distribution of parity - and eliminates the "RAID-5 write hole" in which + <emphasis><acronym>RAID-Z</acronym></emphasis> - + <acronym>ZFS</acronym> implements <acronym>RAID-Z</acronym>, a variation on standard + <acronym>RAID-5</acronym> that offers better distribution of parity + and eliminates the "<acronym>RAID-5</acronym> write hole" in which the data and parity information become - inconsistent after an unexpected restart. ZFS - supports 3 levels of RAID-Z which provide + inconsistent after an unexpected restart. <acronym>ZFS</acronym> + supports 3 levels of <acronym>RAID-Z</acronym> which provide varying levels of redundancy in exchange for decreasing levels of usable storage. The types - are named RAID-Z1 through Z3 based on the number + 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> - <para>In a RAID-Z1 configuration with 4 disks, + <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 operate in degraded mode with one faulted disk. If an @@ -952,8 +955,8 @@ vfs.zfs.vdev.cache.size="5M"</programlis disk is replaced and resilvered, all data in the pool can be lost.</para> - <para>In a RAID-Z3 configuration with 8 disks of - 1 TB, the volume would provide 5TB of + <para>In a <acronym>RAID-Z3</acronym> configuration with 8 disks of + 1 TB, the volume would provide 5 TB of usable space and still be able to operate with three faulted disks. Sun recommends no more than 9 disks in a single vdev. If the @@ -961,53 +964,53 @@ vfs.zfs.vdev.cache.size="5M"</programlis to divide them into separate vdevs and the pool data will be striped across them.</para> - <para>A configuration of 2 RAID-Z2 vdevs + <para>A configuration of 2 <acronym>RAID-Z2</acronym> vdevs consisting of 8 disks each would create - something similar to a RAID 60 array. A RAID-Z + 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, multiplied by the - number of non-parity disks. 4x 1 TB disks - in Z1 has an effective size of approximately - 3 TB, and a 8x 1 TB array in Z3 will - yeild 5 TB of usable space.</para> + number of non-parity disks. Four 1 TB disks + in <acronym>RAID-Z1</acronym> has an effective size of approximately + 3 TB, and an array of eight 1 TB disks in <acronym>RAID-Z3</acronym> will + yield 5 TB of usable space.</para> </listitem> <listitem> <para id="zfs-term-vdev-spare"> - <emphasis>Spare</emphasis> - ZFS has a special + <emphasis>Spare</emphasis> - <acronym>ZFS</acronym> has a special pseudo-vdev type for keeping track of available hot spares. Note that installed hot spares are not deployed automatically; they must manually be configured to replace the failed device using - the zfs replace command.</para> + <command>zfs replace</command>.</para> </listitem> <listitem> <para id="zfs-term-vdev-log"> - <emphasis>Log</emphasis> - ZFS Log Devices, also + <emphasis>Log</emphasis> - <acronym>ZFS</acronym> Log Devices, also known as ZFS Intent Log (<acronym>ZIL</acronym>) move the intent log from the regular pool - devices to a dedicated device. The ZIL + devices to a dedicated device. The <acronym>ZIL</acronym> accelerates synchronous transactions by using storage devices (such as <acronym>SSD</acronym>s) that are faster - compared to those used for the main pool. When + than those used for the main pool. When data is being written and the application requests a guarantee that the data has been safely stored, the data is written to the faster - ZIL storage, then later flushed out to the + <acronym>ZIL</acronym> storage, then later flushed out to the regular disks, greatly reducing the latency of synchronous writes. Log devices can be - mirrored, but RAID-Z is not supported. When - specifying multiple log devices writes will be - load balanced across all devices.</para> + mirrored, but <acronym>RAID-Z</acronym> is not supported. If + multiple log devices are used, writes will be + load balanced across them.</para> </listitem> <listitem> <para id="zfs-term-vdev-cache"> <emphasis>Cache</emphasis> - Adding a cache vdev to a zpool will add the storage of the cache to - the L2ARC. Cache devices cannot be mirrored. + the <acronym>L2ARC</acronym>. Cache devices cannot be mirrored. Since a cache device only stores additional copies of existing data, there is no risk of data loss.</para> @@ -1019,7 +1022,7 @@ vfs.zfs.vdev.cache.size="5M"</programlis <entry id="zfs-term-arc">Adaptive Replacement Cache (<acronym>ARC</acronym>)</entry> - <entry>ZFS uses an Adaptive Replacement Cache + <entry><acronym>ZFS</acronym> uses an Adaptive Replacement Cache (<acronym>ARC</acronym>), rather than a more traditional Least Recently Used (<acronym>LRU</acronym>) cache. An @@ -1032,8 +1035,8 @@ vfs.zfs.vdev.cache.size="5M"</programlis lists; the Most Recently Used (<acronym>MRU</acronym>) and Most Frequently Used (<acronym>MFU</acronym>) objects, plus a ghost list for each. These ghost - lists tracks recently evicted objects to provent them - being added back to the cache. This increases the + lists track recently evicted objects to prevent them + from being added back to the cache. This increases the cache hit ratio by avoiding objects that have a history of only being used occasionally. Another advantage of using both an <acronym>MRU</acronym> and @@ -1041,14 +1044,14 @@ vfs.zfs.vdev.cache.size="5M"</programlis filesystem would normally evict all data from an <acronym>MRU</acronym> or <acronym>LRU</acronym> cache in favor of this freshly accessed content. In the - case of <acronym>ZFS</acronym> since there is also an + case of <acronym>ZFS</acronym>, since there is also an <acronym>MFU</acronym> that only tracks the most frequently used objects, the cache of the most commonly accessed blocks remains.</entry> </row> <row> - <entry id="zfs-term-l2arc">L2ARC</entry> + <entry id="zfs-term-l2arc"><acronym>L2ARC</acronym></entry> <entry>The <acronym>L2ARC</acronym> is the second level of the <acronym>ZFS</acronym> caching system. The @@ -1060,11 +1063,11 @@ vfs.zfs.vdev.cache.size="5M"</programlis 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 L2ARC is entirely optional, but having one + disks. An <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 the regular spinning disks. The - L2ARC can also speed up <link + <acronym>L2ARC</acronym> can also speed up <link linkend="zfs-term-deduplication">deduplication</link> since a <acronym>DDT</acronym> that does not fit in <acronym>RAM</acronym> but does fit in the @@ -1089,35 +1092,35 @@ vfs.zfs.vdev.cache.size="5M"</programlis <entry id="zfs-term-cow">Copy-On-Write</entry> <entry>Unlike a traditional file system, when data is - overwritten on ZFS the new data is written to a + 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 write (a system - crash or power loss in the middle of writing a file) the + 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 discarded. This also means - that ZFS does not require a fsck after an unexpected + that <acronym>ZFS</acronym> does not require a &man.fsck.8; after an unexpected shutdown.</entry> </row> <row> <entry id="zfs-term-dataset">Dataset</entry> - <entry>Dataset is the generic term for a ZFS file system, + <entry>Dataset is the generic term for a <acronym>ZFS</acronym> file system, volume, snapshot or clone. Each dataset will have 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 <literal>mypool/home</literal>, the home dataset - is a child of mypool and inherits properties from it. - This can be expended further by creating + 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 from the - parents and grandparents. ZFS also allows + parents and grandparents. <acronym>ZFS</acronym> also allows administration of datasets and their children to be delegated.</entry> </row> @@ -1125,12 +1128,12 @@ vfs.zfs.vdev.cache.size="5M"</programlis <row> <entry id="zfs-term-volum">Volume</entry> - <entry>In additional to regular file system datasets, ZFS + <entry>In additional to regular file system datasets, <acronym>ZFS</acronym> can also create volumes, which are block devices. Volumes have many of the same features, including copy-on-write, snapshots, clones and checksumming. Volumes can be useful for running other file system - formats on top of ZFS, such as UFS or in the case of + formats on top of <acronym>ZFS</acronym>, such as <acronym>UFS</acronym> or in the case of Virtualization or exporting <acronym>iSCSI</acronym> extents.</entry> </row> @@ -1141,7 +1144,7 @@ vfs.zfs.vdev.cache.size="5M"</programlis <entry>The <link linkend="zfs-term-cow">copy-on-write</link> - design of ZFS allows for nearly instantaneous consistent + design of <acronym>ZFS</acronym> allows for nearly instantaneous consistent snapshots with arbitrary names. After taking a snapshot of a dataset (or a recursive snapshot of a parent dataset that will include all child datasets), new data @@ -1202,15 +1205,15 @@ vfs.zfs.vdev.cache.size="5M"</programlis <entry id="zfs-term-checksum">Checksum</entry> <entry>Every block that is allocated is also checksummed - (which algorithm is used is a per dataset property, see: - zfs set). ZFS transparently validates the checksum of - each block as it is read, allowing ZFS to detect silent + (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 is read, allowing <acronym>ZFS</acronym> to detect silent corruption. If the data that is read does not match the - expected checksum, ZFS will attempt to recover the data - from any available redundancy (mirrors, RAID-Z). You - can trigger the validation of all checksums using the - <link linkend="zfs-term-scrub">scrub</link> - command. The available checksum algorithms include: + expected checksum, <acronym>ZFS</acronym> will attempt to recover the data + from any available redundancy, like mirrors or <acronym>RAID-Z</acronym>). Validation of all checksums can be triggered with + the + <link linkend="zfs-term-scrub"><command>scrub</command></link> + command. Available checksum algorithms include: <itemizedlist> <listitem> @@ -1235,7 +1238,7 @@ vfs.zfs.vdev.cache.size="5M"</programlis <row> <entry id="zfs-term-compression">Compression</entry> - <entry>Each dataset in ZFS has a compression property, + <entry>Each dataset in <acronym>ZFS</acronym> has a 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 @@ -1245,7 +1248,7 @@ vfs.zfs.vdev.cache.size="5M"</programlis of the file needs to be read or written. <note> - <para>LZ4 compression is only available after &os; + <para><acronym>LZ4</acronym> compression is only available after &os; 9.2</para> </note></entry> </row> @@ -1253,12 +1256,12 @@ vfs.zfs.vdev.cache.size="5M"</programlis <row> <entry id="zfs-term-deduplication">Deduplication</entry> - <entry>ZFS has the ability to detect duplicate blocks of + <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, instead of writing the block a second time, the reference count of the existing block will be increased, saving storage - space. In order to do this, ZFS keeps a deduplication + space. To do this, <acronym>ZFS</acronym> keeps a deduplication table (<acronym>DDT</acronym>) in memory, containing the list of unique checksums, the location of that block and a reference count. When new data is written, the @@ -1266,25 +1269,25 @@ vfs.zfs.vdev.cache.size="5M"</programlis match is found, the data is considered to be a duplicate. When deduplication is enabled, the checksum algorithm is changed to <acronym>SHA256</acronym> to - provide a secure cryptographic hash. ZFS deduplication + provide a secure cryptographic hash. <acronym>ZFS</acronym> deduplication is tunable; if dedup is on, then a 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 - ZFS and the two blocks will be stored separately. Due + <acronym>ZFS</acronym> and the two blocks will be stored separately. Due to the nature of the <acronym>DDT</acronym>, having to 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 DDT in memory, - performance will suffer greatly as the DDT will need to + <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 L2ARC to store the - DDT, providing a middle ground between fast system - memory and slower disks. It is advisable to consider - using ZFS compression instead, which often provides + Deduplication can make use of the <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 often provides nearly as much space savings without the additional memory requirement.</entry> </row> @@ -1292,7 +1295,7 @@ vfs.zfs.vdev.cache.size="5M"</programlis <row> <entry id="zfs-term-scrub">Scrub</entry> - <entry>In place of a consistency check like fsck, ZFS has + <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 checksums stored @@ -1300,7 +1303,7 @@ vfs.zfs.vdev.cache.size="5M"</programlis 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. ZFS + 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 use, but a scrub operation makes sure even infrequently used blocks are checked for @@ -1310,14 +1313,14 @@ vfs.zfs.vdev.cache.size="5M"</programlis <row> <entry id="zfs-term-quota">Dataset Quota</entry> - <entry>ZFS provides very fast and accurate dataset, user - and group space accounting in addition to quotes and + <entry><acronym>ZFS</acronym> provides very fast and 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 space to ensure other file systems do not take all of the free space. - <para>ZFS supports different types of quotas: the + <para><acronym>ZFS</acronym> supports different types of quotas: the dataset quota, the <link linkend="zfs-term-refquota">reference quota (<acronym>refquota</acronym>)</link>, the @@ -1378,7 +1381,7 @@ vfs.zfs.vdev.cache.size="5M"</programlis 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 - <filename>storage/home/bob</filename>, the space used by + <filename class="directory">storage/home/bob</filename>, the space used by that snapshot is counted against the reservation. The <link linkend="zfs-term-refreservation">refreservation</link> @@ -1428,7 +1431,7 @@ vfs.zfs.vdev.cache.size="5M"</programlis process of calculating and writing the missing data (using the parity information distributed across the remaining drives) to the new drive is called - Resilvering.</entry> + <emphasis>resilvering</emphasis>.</entry> </row> </tbody> </tgroup>help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201308150201.r7F21b11079224>