All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <rdunlap@infradead.org>
To: linux-fsdevel@vger.kernel.org
Cc: Randy Dunlap <rdunlap@infradead.org>, Chris Mason <clm@fb.com>,
	Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>,
	linux-btrfs@vger.kernel.org
Subject: [PATCH] btrfs: delete duplicated words + other fixes
Date: Tue,  4 Aug 2020 19:48:34 -0700	[thread overview]
Message-ID: <20200805024834.12078-1-rdunlap@infradead.org> (raw)

Delete repeated words in fs/btrfs/.
{to, the, a, and old}
and change "into 2 part" to "into 2 parts".

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
To: linux-fsdevel@vger.kernel.org
Cc: Chris Mason <clm@fb.com>
Cc: Josef Bacik <josef@toxicpanda.com>
Cc: David Sterba <dsterba@suse.com>
Cc: linux-btrfs@vger.kernel.org
---
 fs/btrfs/block-group.c      |    2 +-
 fs/btrfs/ctree.c            |    2 +-
 fs/btrfs/disk-io.c          |    2 +-
 fs/btrfs/extent_io.c        |    2 +-
 fs/btrfs/free-space-cache.c |    2 +-
 fs/btrfs/qgroup.c           |    2 +-
 fs/btrfs/tree-log.c         |    4 ++--
 7 files changed, 8 insertions(+), 8 deletions(-)

--- linux-next-20200804.orig/fs/btrfs/block-group.c
+++ linux-next-20200804/fs/btrfs/block-group.c
@@ -2783,7 +2783,7 @@ int btrfs_write_dirty_block_groups(struc
 			 * finished yet (no block group item in the extent tree
 			 * yet, etc). If this is the case, wait for all free
 			 * space endio workers to finish and retry. This is a
-			 * a very rare case so no need for a more efficient and
+			 * very rare case so no need for a more efficient and
 			 * complex approach.
 			 */
 			if (ret == -ENOENT) {
--- linux-next-20200804.orig/fs/btrfs/ctree.c
+++ linux-next-20200804/fs/btrfs/ctree.c
@@ -5111,7 +5111,7 @@ again:
 			slot--;
 		/*
 		 * check this node pointer against the min_trans parameters.
-		 * If it is too old, old, skip to the next one.
+		 * If it is too old, skip to the next one.
 		 */
 		while (slot < nritems) {
 			u64 gen;
--- linux-next-20200804.orig/fs/btrfs/disk-io.c
+++ linux-next-20200804/fs/btrfs/disk-io.c
@@ -2929,7 +2929,7 @@ int __cold open_ctree(struct super_block
 	}
 
 	/*
-	 * Verify the type first, if that or the the checksum value are
+	 * Verify the type first, if that or the checksum value are
 	 * corrupted, we'll find out
 	 */
 	csum_type = btrfs_super_csum_type(disk_super);
--- linux-next-20200804.orig/fs/btrfs/extent_io.c
+++ linux-next-20200804/fs/btrfs/extent_io.c
@@ -3241,7 +3241,7 @@ static int __do_readpage(struct page *pa
 
 		/*
 		 * If we have a file range that points to a compressed extent
-		 * and it's followed by a consecutive file range that points to
+		 * and it's followed by a consecutive file range that points
 		 * to the same compressed extent (possibly with a different
 		 * offset and/or length, so it either points to the whole extent
 		 * or only part of it), we must make sure we do not submit a
--- linux-next-20200804.orig/fs/btrfs/free-space-cache.c
+++ linux-next-20200804/fs/btrfs/free-space-cache.c
@@ -1353,7 +1353,7 @@ static int __btrfs_write_out_cache(struc
 
 	/*
 	 * at this point the pages are under IO and we're happy,
-	 * The caller is responsible for waiting on them and updating the
+	 * The caller is responsible for waiting on them and updating
 	 * the cache and the inode
 	 */
 	io_ctl->entries = entries;
--- linux-next-20200804.orig/fs/btrfs/qgroup.c
+++ linux-next-20200804/fs/btrfs/qgroup.c
@@ -2315,7 +2315,7 @@ static int qgroup_update_refcnt(struct b
  * Update qgroup rfer/excl counters.
  * Rfer update is easy, codes can explain themselves.
  *
- * Excl update is tricky, the update is split into 2 part.
+ * Excl update is tricky, the update is split into 2 parts.
  * Part 1: Possible exclusive <-> sharing detect:
  *	|	A	|	!A	|
  *  -------------------------------------
--- linux-next-20200804.orig/fs/btrfs/tree-log.c
+++ linux-next-20200804/fs/btrfs/tree-log.c
@@ -4881,7 +4881,7 @@ static int log_conflicting_inodes(struct
 		 * Check the inode's logged_trans only instead of
 		 * btrfs_inode_in_log(). This is because the last_log_commit of
 		 * the inode is not updated when we only log that it exists and
-		 * and it has the full sync bit set (see btrfs_log_inode()).
+		 * it has the full sync bit set (see btrfs_log_inode()).
 		 */
 		if (BTRFS_I(inode)->logged_trans == trans->transid) {
 			spin_unlock(&BTRFS_I(inode)->lock);
@@ -6378,7 +6378,7 @@ void btrfs_record_snapshot_destroy(struc
  *            committed by the caller, and BTRFS_DONT_NEED_TRANS_COMMIT
  *            otherwise.
  * When false: returns BTRFS_DONT_NEED_LOG_SYNC if the caller does not need to
- *             to sync the log, BTRFS_NEED_LOG_SYNC if it needs to sync the log,
+ *             sync the log, BTRFS_NEED_LOG_SYNC if it needs to sync the log,
  *             or BTRFS_NEED_TRANS_COMMIT if the transaction needs to be
  *             committed (without attempting to sync the log).
  */

             reply	other threads:[~2020-08-05  2:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-05  2:48 Randy Dunlap [this message]
2020-08-05  7:09 ` [PATCH] btrfs: delete duplicated words + other fixes Nikolay Borisov
2020-08-10 15:09 ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200805024834.12078-1-rdunlap@infradead.org \
    --to=rdunlap@infradead.org \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.