Archive-Team
/
zfs
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 103 Wiki Activity

build: resolve orthographic and other grammatical errors 

Signed-off-by: Jan Engelhardt <jengelh@inai.de>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
This commit is contained in:
Jan Engelhardt 2013-03-30 03:27:50 +01:00 committed by Brian Behlendorf
parent 4a5b121808
commit 4e95cc99b0
5 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
config/kernel.m4
View File

@ -109,7 +109,7 @@ AC_DEFUN([ZFS_AC_MODULE_SYMVERS], [
AS_IF([test ! -f "$LINUX_OBJ/$LINUX_SYMBOLS"], [
AC_MSG_ERROR([
*** Please make sure the kernel devel package for your distribution
*** is installed. If your building with a custom kernel make sure the
*** is installed. If you are building with a custom kernel, make sure the
*** kernel is configured, built, and the '--with-linux=PATH' configure
*** option refers to the location of the kernel source.])
])
@ -163,7 +163,7 @@ AC_DEFUN([ZFS_AC_KERNEL], [
AS_IF([test ! -d "$kernelsrc"], [
AC_MSG_ERROR([
*** Please make sure the kernel devel package for your distribution
*** is installed then try again. If that fails you can specify the
*** is installed and then try again. If that fails, you can specify the
*** location of the kernel source with the '--with-linux=PATH' option.])
])

6
include/sys/dmu.h
View File

@ -410,7 +410,7 @@ void dmu_write_policy(objset_t *os, struct dnode *dn, int level, int wp,
* read db_data, dmu_buf_will_dirty() before modifying it, and the
* object must be held in an assigned transaction before calling
* dmu_buf_will_dirty. You may use dmu_buf_set_user() on the bonus
* buffer as well. You must release your hold with dmu_buf_rele().
* buffer as well. You must release what you hold with dmu_buf_rele().
*/
int dmu_bonus_hold(objset_t *os, uint64_t object, void *tag, dmu_buf_t **);
int dmu_bonus_max(void);
@ -432,8 +432,8 @@ int dmu_spill_hold_existing(dmu_buf_t *bonus, void *tag, dmu_buf_t **dbp);
* Obtain the DMU buffer from the specified object which contains the
* specified offset. dmu_buf_hold() puts a "hold" on the buffer, so
* that it will remain in memory. You must release the hold with
* dmu_buf_rele(). You musn't access the dmu_buf_t after releasing your
* hold. You must have a hold on any dmu_buf_t* you pass to the DMU.
* dmu_buf_rele(). You must not access the dmu_buf_t after releasing
* what you hold. You must have a hold on any dmu_buf_t* you pass to the DMU.
*
* You must call dmu_buf_read, dmu_buf_will_dirty, or dmu_buf_will_fill
* on the returned buffer before reading or writing the buffer's

6
lib/libspl/include/umem.h
View File

@ -28,10 +28,10 @@
#define _LIBSPL_UMEM_H
/* XXX: We should use the real portable umem library if it is detected
* at configure time. However, if the library is not available we can
* at configure time. However, if the library is not available, we can
* use a trivial malloc based implementation. This obviously impacts
* performance but unless you using a full userspace build of zpool for
* something other than ztest your likely not going to notice or care.
* performance, but unless you are using a full userspace build of zpool for
* something other than ztest, you are likely not going to notice or care.
*
* https://labs.omniti.com/trac/portableumem
*/

6
module/zfs/vdev_disk.c
View File

@ -268,13 +268,13 @@ vdev_disk_open(vdev_t *v, uint64_t *psize, uint64_t *max_psize,
* Devices are always opened by the path provided at configuration
* time. This means that if the provided path is a udev by-id path
* then drives may be recabled without an issue. If the provided
* path is a udev by-path path then the physical location information
* path is a udev by-path path, then the physical location information
* will be preserved. This can be critical for more complicated
* configurations where drives are located in specific physical
* locations to maximize the systems tolerence to component failure.
* Alternately you can provide your own udev rule to flexibly map
* Alternatively, you can provide your own udev rule to flexibly map
* the drives as you see fit. It is not advised that you use the
* /dev/[hd]d devices which may be reorder due to probing order.
* /dev/[hd]d devices which may be reordered due to probing order.
* Devices in the wrong locations will be detected by the higher
* level vdev validation.
*/

2
scripts/zpios.sh
View File

@ -229,7 +229,7 @@ fi
check_test || die "${ERROR}"
. ${ZPIOS_TEST}
# Pull in the zpios test module is not loaded. If this fails it is
# Pull in the zpios test module if not loaded. If this fails, it is
# likely because the full module stack was not yet loaded with zfs.sh
if check_modules; then
if ! load_modules; then