diff options
Diffstat (limited to 'Documentation/filesystems')
| -rw-r--r-- | Documentation/filesystems/caching/backend-api.txt | 2 | ||||
| -rw-r--r-- | Documentation/filesystems/caching/cachefiles.txt | 4 | ||||
| -rw-r--r-- | Documentation/filesystems/caching/netfs-api.txt | 2 | ||||
| -rw-r--r-- | Documentation/filesystems/caching/operations.txt | 2 | ||||
| -rw-r--r-- | Documentation/filesystems/qnx6.txt | 4 | ||||
| -rw-r--r-- | Documentation/filesystems/vfs.txt | 2 | ||||
| -rw-r--r-- | Documentation/filesystems/xfs-self-describing-metadata.txt | 2 | ||||
| -rw-r--r-- | Documentation/filesystems/xfs.txt | 2 |
8 files changed, 10 insertions, 10 deletions
diff --git a/Documentation/filesystems/caching/backend-api.txt b/Documentation/filesystems/caching/backend-api.txt index c0bd5677271b..c418280c915f 100644 --- a/Documentation/filesystems/caching/backend-api.txt +++ b/Documentation/filesystems/caching/backend-api.txt @@ -704,7 +704,7 @@ FS-Cache provides some utilities that a cache backend may make use of: void fscache_get_retrieval(struct fscache_retrieval *op); void fscache_put_retrieval(struct fscache_retrieval *op); - These two functions are used to retain a retrieval record whilst doing + These two functions are used to retain a retrieval record while doing asynchronous data retrieval and block allocation. diff --git a/Documentation/filesystems/caching/cachefiles.txt b/Documentation/filesystems/caching/cachefiles.txt index 748a1ae49e12..28aefcbb1442 100644 --- a/Documentation/filesystems/caching/cachefiles.txt +++ b/Documentation/filesystems/caching/cachefiles.txt @@ -45,7 +45,7 @@ filesystems are very specific in nature. CacheFiles creates a misc character device - "/dev/cachefiles" - that is used to communication with the daemon. Only one thing may have this open at once, -and whilst it is open, a cache is at least partially in existence. The daemon +and while it is open, a cache is at least partially in existence. The daemon opens this and sends commands down it to control the cache. CacheFiles is currently limited to a single cache. @@ -163,7 +163,7 @@ Do not mount other things within the cache as this will cause problems. The kernel module contains its own very cut-down path walking facility that ignores mountpoints, but the daemon can't avoid them. -Do not create, rename or unlink files and directories in the cache whilst the +Do not create, rename or unlink files and directories in the cache while the cache is active, as this may cause the state to become uncertain. Renaming files in the cache might make objects appear to be other objects (the diff --git a/Documentation/filesystems/caching/netfs-api.txt b/Documentation/filesystems/caching/netfs-api.txt index 2a6f7399c1f3..ba968e8f5704 100644 --- a/Documentation/filesystems/caching/netfs-api.txt +++ b/Documentation/filesystems/caching/netfs-api.txt @@ -382,7 +382,7 @@ MISCELLANEOUS OBJECT REGISTRATION An optional step is to request an object of miscellaneous type be created in the cache. This is almost identical to index cookie acquisition. The only difference is that the type in the object definition should be something other -than index type. Whilst the parent object could be an index, it's more likely +than index type. While the parent object could be an index, it's more likely it would be some other type of object such as a data file. xattr->cache = diff --git a/Documentation/filesystems/caching/operations.txt b/Documentation/filesystems/caching/operations.txt index a1c052cbba35..d8976c434718 100644 --- a/Documentation/filesystems/caching/operations.txt +++ b/Documentation/filesystems/caching/operations.txt @@ -171,7 +171,7 @@ Operations are used through the following procedure: (3) If the submitting thread wants to do the work itself, and has marked the operation with FSCACHE_OP_MYTHREAD, then it should monitor FSCACHE_OP_WAITING as described above and check the state of the object if - necessary (the object might have died whilst the thread was waiting). + necessary (the object might have died while the thread was waiting). When it has finished doing its processing, it should call fscache_op_complete() and fscache_put_operation() on it. diff --git a/Documentation/filesystems/qnx6.txt b/Documentation/filesystems/qnx6.txt index 4f3d6a882bdc..48ea68f15845 100644 --- a/Documentation/filesystems/qnx6.txt +++ b/Documentation/filesystems/qnx6.txt @@ -87,7 +87,7 @@ addressed with 16 direct blocks. For more than 16 blocks an indirect addressing in form of another tree is used. (scheme is the same as the one used for the superblock root nodes) -The filesize is stored 64bit. Inode counting starts with 1. (whilst long +The filesize is stored 64bit. Inode counting starts with 1. (while long filename inodes start with 0) Directories @@ -155,7 +155,7 @@ Then userspace. The requirement for a static, fixed preallocated system area comes from how qnx6fs deals with writes. Each superblock got it's own half of the system area. So superblock #1 -always uses blocks from the lower half whilst superblock #2 just writes to +always uses blocks from the lower half while superblock #2 just writes to blocks represented by the upper half bitmap system area bits. Bitmap blocks, Inode blocks and indirect addressing blocks for those two diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 5f71a252e2e0..8dc8e9c2913f 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -1131,7 +1131,7 @@ struct dentry_operations { d_manage: called to allow the filesystem to manage the transition from a dentry (optional). This allows autofs, for example, to hold up clients - waiting to explore behind a 'mountpoint' whilst letting the daemon go + waiting to explore behind a 'mountpoint' while letting the daemon go past and construct the subtree there. 0 should be returned to let the calling process continue. -EISDIR can be returned to tell pathwalk to use this directory as an ordinary directory and to ignore anything diff --git a/Documentation/filesystems/xfs-self-describing-metadata.txt b/Documentation/filesystems/xfs-self-describing-metadata.txt index 05aa455163e3..68604e67a495 100644 --- a/Documentation/filesystems/xfs-self-describing-metadata.txt +++ b/Documentation/filesystems/xfs-self-describing-metadata.txt @@ -110,7 +110,7 @@ owner field in the metadata object, we can immediately do top down validation to determine the scope of the problem. Different types of metadata have different owner identifiers. For example, -directory, attribute and extent tree blocks are all owned by an inode, whilst +directory, attribute and extent tree blocks are all owned by an inode, while freespace btree blocks are owned by an allocation group. Hence the size and contents of the owner field are determined by the type of metadata object we are looking at. The owner information can also identify misplaced writes (e.g. diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt index a9ae82fb9d13..9ccfd1bc6201 100644 --- a/Documentation/filesystems/xfs.txt +++ b/Documentation/filesystems/xfs.txt @@ -417,7 +417,7 @@ level directory: filesystem from ever unmounting fully in the case of "retry forever" handler configurations. - Note: there is no guarantee that fail_at_unmount can be set whilst an + Note: there is no guarantee that fail_at_unmount can be set while an unmount is in progress. It is possible that the sysfs entries are removed by the unmounting filesystem before a "retry forever" error handler configuration causes unmount to hang, and hence the filesystem |