pf.conf.5/swapcache.8: Fix some typos (verses -> versus).

diff --git a/share/man/man8/swapcache.8 b/share/man/man8/swapcache.8
index f688d67..a5ff6cc 100644 (file)
--- a/share/man/man8/swapcache.8
+++ b/share/man/man8/swapcache.8
@@ -276,7 +276,7 @@ Configuring two SSDs for your swap will
 improve aggregate swapcache read performance by 1.5x to 1.8x.
 In tests with two Intel 40GB SSDs 300MB/sec was easily achieved.
 With two SATA-III SSDs it is possible to achieve 600MB/sec or better
-and well over 400MB/sec random-read performance (verses the ~3MB/sec
+and well over 400MB/sec random-read performance (versus the ~3MB/sec
 random read performance a hard drive gives you).
 .Pp
 At this point you will be configuring more swap space than a 32 bit
@@ -405,7 +405,7 @@ Although
 is designed to work with SSD-based storage it can also be used with
 HD-based storage as an aid for offloading the primary storage system.
 Here we need to make a distinction between using RAID for fanning out
-storage verses using RAID for redundancy.  There are numerous situations
+storage versus using RAID for redundancy.  There are numerous situations
 where RAID-based redundancy does not make sense.
 .Pp
 A good example would be in an environment where the servers themselves
@@ -488,7 +488,7 @@ Write-combining results in a net-reduction
 of write-amplification effects but due to having to de-combine later and
 other fragmentary effects it isn't 100%.
 From testing with Intel devices write-amplification can be well controlled
-in the 2x-4x range with the OS doing 16K writes, verses a worst-case
+in the 2x-4x range with the OS doing 16K writes, versus a worst-case
 8x write-amplification with 16K blocks, 32x with 4K blocks, and a truly
 horrid worst-case with 512 byte blocks.
 .Pp
@@ -503,7 +503,7 @@ In terms of placing an actual filesystem on the SSD, the
 filesystem utilizes 16K blocks and is well behaved as long as you limit
 reblocking operations.
 For UFS you should create the filesystem with at least a 4K fragment
-size, verses the default 2K.
+size, versus the default 2K.
 Modern Windows filesystems use 4K clusters but it is unclear how SSD-friendly
 NTFS is.
 .Sh EXPLANATION OF FLASH CHIP FEATURE SIZE VS ERASE/REWRITE CYCLE DURABILITY
@@ -515,7 +515,7 @@ The older 34nm flash typically had a 10,000 cell durability while the newer
 25nm flash is closer to 1000.  The newer flash uses larger ECCs and more
 sensitive voltage comparators on-chip to increase the durability closer to
 3000 cycles.  Generally speaking you should assume a durability of around
-1/3 for the same storage capacity using the new chips verses the older
+1/3 for the same storage capacity using the new chips versus the older
 chips.  If you can squeeze out a 400TB durability from an older 40GB X25-V
 using 34nm technology then you should assume around a 400TB durability from
 a newer 120GB 310 series SSD using 25nm technology.

diff --git a/usr.sbin/pfctl/pf.conf.5 b/usr.sbin/pfctl/pf.conf.5
index 0fdac9c..17a361e 100644 (file)
--- a/usr.sbin/pfctl/pf.conf.5
+++ b/usr.sbin/pfctl/pf.conf.5
@@ -901,7 +901,7 @@ The queues are scanned from highest priority to lowest priority.
 If a queue has pending packets and is under its bandwidth minimum the
 scan stops and a packet is selected from that queue.
 If all queues have reached their bandwidth minimum a scale factor based
-on each queue's bandwidth minimum verses that queue's current bandwidth
+on each queue's bandwidth minimum versus that queue's current bandwidth
 usage is calculated and the queue with the lowest scale factor is selected.
 This effectively uses the minimum bandwidth specification as a relative
 weighting for apportioning any remaining bandwidth on the link.