btrfs-progs: do interactive fixing of some ambigous typos

Typos fixed manually using the following:

=== Do not change lines below ===
{
 "chain": [],
 "cmd": "codespell -w -i 3 -C 2",
 "exit": 0,
 "extra_inputs": [],
 "inputs": [],
 "outputs": [],
 "pwd": "."
}
^^^ Do not change lines above ^^^

Author: Yaroslav Halchenko <debian@onerussian.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This commit is contained in:
Yaroslav Halchenko 2024-07-10 11:37:26 -10:00 committed by David Sterba
parent 1c710603b3
commit 5b3bb3973a
5 changed files with 6 additions and 6 deletions

View File

@ -56,7 +56,7 @@ as a reply to the mailinglist after you've reviewed a patch. See below.
Reviewed-by: Reviewed-by:
^^^^^^^^^^^^ ^^^^^^^^^^^^
The patch has been reviewed and the singed person is putting his hand into The patch has been reviewed and the signed person is putting his hand into
fire. If there's a bug found in this patch, the person is usually a good fire. If there's a bug found in this patch, the person is usually a good
candidate for a CC: of the bugreport. candidate for a CC: of the bugreport.
@ -157,7 +157,7 @@ Controversial changes
This happens, not every patch gets merged. In the worst case there are not even This happens, not every patch gets merged. In the worst case there are not even
any comments under the patch and it's silently ignored. This depends on many any comments under the patch and it's silently ignored. This depends on many
factors, most notably \*cough*time*cough*. Examining potential drawbacks or factors, most notably \*cough*time*cough*. Examining potential drawbacks or
forseeing disasters is not an easy job. foreseeing disasters is not an easy job.
Let's be more positive, you manage to attract the attention of some developer Let's be more positive, you manage to attract the attention of some developer
and he says, he does not like the approach of the patch(es). Better than and he says, he does not like the approach of the patch(es). Better than

View File

@ -239,7 +239,7 @@ Patches
- additional information - additional information
- if there's a stack trace relevant for the patch, add it ther (lockdep, - if there's a stack trace relevant for the patch, add it there (lockdep,
crash, warning) crash, warning)
- steps to reproduce a bug (that will also get turned to a proper fstests - steps to reproduce a bug (that will also get turned to a proper fstests
case) case)

View File

@ -336,7 +336,7 @@ def print_block_groups(mountpoint):
p_left = args_buffer_size p_left = args_buffer_size
for _ in range(0, s.args.nr_items): for _ in range(0, s.args.nr_items):
# for each itme, copy the header from the buffer into # for each item, copy the header from the buffer into
# our header struct # our header struct
ctypes.memmove(h, p, header_size) ctypes.memmove(h, p, header_size)
p += header_size p += header_size

View File

@ -62,7 +62,7 @@ static int ext2_open_fs(struct btrfs_convert_context *cctx, const char *name)
/* /*
* We need to know exactly the used space, some RO compat flags like * We need to know exactly the used space, some RO compat flags like
* BIGALLOC will affect how used space is present. * BIGALLOC will affect how used space is present.
* So we need manuall check any unsupported RO compat flags * So we need manually check any unsupported RO compat flags
*/ */
ro_feature = ext2_fs->super->s_feature_ro_compat; ro_feature = ext2_fs->super->s_feature_ro_compat;
if (ro_feature & ~EXT2_LIB_FEATURE_RO_COMPAT_SUPP) { if (ro_feature & ~EXT2_LIB_FEATURE_RO_COMPAT_SUPP) {

View File

@ -194,7 +194,7 @@ static const uint32_t crc32c_table[256] = {
}; };
/* /*
* Fallback implementatin. Step through buffer one byte at at time, calculates * Fallback implementation. Step through buffer one byte at at time, calculates
* reflected crc using table, can accept an unaligned buffer. * reflected crc using table, can accept an unaligned buffer.
*/ */
static uint32_t crc32c_ref(uint32_t crc, unsigned char const *data, uint32_t length) static uint32_t crc32c_ref(uint32_t crc, unsigned char const *data, uint32_t length)