Date: Wed, 14 Aug 2002 14:37:09 +0200 (CEST) From: Martin Heinen <vincent@Kain.sumuk.de> To: FreeBSD-gnats-submit@FreeBSD.org Subject: docs/41661: [PATCH] minor correction of vinum/chapter.sgml Message-ID: <200208141237.g7ECb9SJ021178@Kain.sumuk.de>
next in thread | raw e-mail | index | archive | help
>Number: 41661
>Category: docs
>Synopsis: [PATCH] minor correction of vinum/chapter.sgml
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-doc
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: doc-bug
>Submitter-Id: current-users
>Arrival-Date: Wed Aug 14 05:40:02 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: Martin Heinen
>Release: FreeBSD 4.6-STABLE i386
>Organization:
>Environment:
System: FreeBSD Kain.sumuk.de 4.6-STABLE FreeBSD 4.6-STABLE #0: Mon Aug 12 13:45:36 CEST 2002 toor@Kain.sumuk.de:/usr/obj/usr/src/sys/KAIN i386
>Description:
have solve -> have solved,
perpend -> prepend,
say what a kld is when it is first mentioned,
expanded contractions.
I don't know what was meant by \rg in
"VERITAS\(rg volume manager", but context suggests that
"VERITAS Volume Manager&trade" is appropriate here.
>How-To-Repeat:
Read the new Vinum chapter.
>Fix:
Index: chapter.sgml
===================================================================
RCS file: /u/cvs/doc/en_US.ISO8859-1/books/handbook/vinum/chapter.sgml,v
retrieving revision 1.2
diff -u -r1.2 chapter.sgml
--- chapter.sgml 14 Aug 2002 05:45:48 -0000 1.2
+++ chapter.sgml 14 Aug 2002 12:18:43 -0000
@@ -50,14 +50,14 @@
<para><emphasis>Vinum</emphasis> is a
so-called <emphasis>Volume Manager</emphasis>, a virtual disk driver that
- addresses these three problems. Let's look at them in more detail. Various
+ addresses these three problems. Let us look at them in more detail. Various
solutions to these problems have been proposed and implemented:</para>
<para>Disks are getting bigger, but so are data storage requirements.
- Often you'll find you want a file system that is bigger than the disks
+ Often you will find you want a file system that is bigger than the disks
you have available. Admittedly, this problem is not as acute as it was
- ten years ago, but it still exists. Some systems have solve this by
+ ten years ago, but it still exists. Some systems have solved this by
creating an abstract device which stores its data on a number of disks.</para>
</sect1>
@@ -72,7 +72,7 @@
<para>Current disk drives can transfer data sequentially at up to
30 MB/s, but this value is of little importance in an environment
where many independent processes access a drive, where they may
- achieve only a fraction of these values. In such cases it's more
+ achieve only a fraction of these values. In such cases it is more
interesting to view the problem from the viewpoint of the disk
subsystem: the important parameter is the load that a transfer places
on the subsystem, in other words the time for which a transfer occupies
@@ -80,7 +80,7 @@
<para>In any disk transfer, the drive must first position the heads, wait
for the first sector to pass under the read head, and then perform the
- transfer. These actions can be considered to be atomic: it doesn't make
+ transfer. These actions can be considered to be atomic: it does not make
any sense to interrupt them.</para>
<para><anchor id="vinum-latency">
@@ -112,7 +112,7 @@
<para>The evenness of the load on the disks is strongly dependent on
the way the data is shared across the drives. In the following
- discussion, it's convenient to think of the disk storage as a large
+ discussion, it is convenient to think of the disk storage as a large
number of data sectors which are addressable by number, rather like the
pages in a book. The most obvious method is to divide the virtual disk
into groups of consecutive sectors the size of the individual physical
@@ -654,7 +654,7 @@
<title>Object naming</title>
<para>As described above, Vinum assigns default names to plexes and
subdisks, although they may be overridden. Overriding the default names
- is not recommended: experience with the VERITAS\(rg volume manager, which
+ is not recommended: experience with the VERITAS Volume Manager™, which
allows arbitrary naming of objects, has shown that this flexibility does
not bring a significant advantage, and it can cause confusion.</para>
@@ -679,7 +679,7 @@
<para>Block and character device entries for each volume.
These are the main devices used by Vinum. The block device names are
the name of the volume, while the character device names follow the BSD
- tradition of perpending the letter <emphasis>r</emphasis> to the name.
+ tradition of prepending the letter <emphasis>r</emphasis> to the name.
Thus the configuration above would include the block devices
<devicename>/dev/vinum/myvol</devicename>,
<devicename>/dev/vinum/mirror</devicename>,
@@ -835,12 +835,12 @@
<sect1 id="vinum-config">
<title>Configuring Vinum</title>
- <para>The <filename>GENERIC</filename> kernel does not contain Vinum. It's
+ <para>The <filename>GENERIC</filename> kernel does not contain Vinum. It is
possible to build a special kernel which includes Vinum, but this is not
- recommended. The standard way to start Vinum is as a
- <acronym>kld</acronym>. You don't even need to use &man.kldload.8;
+ recommended. The standard way to start Vinum is as a kernel module
+ (<acronym>kld</acronym>). You do not even need to use &man.kldload.8;
for Vinum: when you start &man.vinum.8;, it checks whether the module
- has been loaded, and if it isn't, it loads it automatically.</para>
+ has been loaded, and if it is not, it loads it automatically.</para>
<sect2>
@@ -891,10 +891,10 @@
<programlisting>
start_vinum="YES" # set to YES to start vinum</programlisting>
- <para>If you don't have a file <filename>/etc/rc.conf</filename>, create
+ <para>If you do not have a file <filename>/etc/rc.conf</filename>, create
one with this content. This will cause the system to load the Vinum
<acronym>kld</acronym> at startup, and to start any objects mentioned in
- the configuration. This is done before mounting file systems, so it's
+ the configuration. This is done before mounting file systems, so it is
possible to automatically &man.fsck.8; and mount file systems on Vinum
volumes.</para>
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200208141237.g7ECb9SJ021178>