From: Naohiro Aota <Naohiro.Aota@wdc.com>
To: David Sterba <dsterba@suse.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 3/3] btrfs: reformat comments in acls_after_inode_item()
Date: Thu, 24 Apr 2025 01:52:20 +0000 [thread overview]
Message-ID: <D9EHQPSBBS4G.2B8ALJ1KNJMET@wdc.com> (raw)
In-Reply-To: <8f6470c838cb98fd83136e3285af6afd8b8f293b.1745426584.git.dsterba@suse.com>
On Thu Apr 24, 2025 at 1:53 AM JST, David Sterba wrote:
> Signed-off-by: David Sterba <dsterba@suse.com>
> ---
> fs/btrfs/inode.c | 37 +++++++++++++++++++++++--------------
> 1 file changed, 23 insertions(+), 14 deletions(-)
>
> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> index e3bbe348ac91e2..e18967a14d6419 100644
> --- a/fs/btrfs/inode.c
> +++ b/fs/btrfs/inode.c
> @@ -3721,10 +3721,14 @@ int btrfs_orphan_cleanup(struct btrfs_root *root)
> }
>
> /*
> - * very simple check to peek ahead in the leaf looking for xattrs. If we
> - * don't find any xattrs, we know there can't be any acls.
> + * Look ahead in the leaf for xattrs. If we don't find any then we know there
> + * can be any ACLs.
can't be ?
> *
> - * slot is the slot the inode is in, objectid is the objectid of the inode
> + * @leaf: the eb leaf where to search
> + * @slot: the slot the inode is in
> + * @objectid: the objectid of the inode
> + *
> + * Retrun true if there is a xattr, false otherwise.
nit: typo: Return
Also, should it be "an xattr" ?
> */
> static noinline bool acls_after_inode_item(struct extent_buffer *leaf,
> int slot, u64 objectid,
> @@ -3748,11 +3752,11 @@ static noinline bool acls_after_inode_item(struct extent_buffer *leaf,
> while (slot < nritems) {
> btrfs_item_key_to_cpu(leaf, &found_key, slot);
>
> - /* we found a different objectid, there must not be acls */
> + /* We found a different objectid, there must be no ACLs. */
> if (found_key.objectid != objectid)
> return false;
>
> - /* we found an xattr, assume we've got an acl */
> + /* We found an xattr, assume we've got an ACL. */
> if (found_key.type == BTRFS_XATTR_ITEM_KEY) {
> if (*first_xattr_slot == -1)
> *first_xattr_slot = slot;
> @@ -3762,8 +3766,8 @@ static noinline bool acls_after_inode_item(struct extent_buffer *leaf,
> }
>
> /*
> - * we found a key greater than an xattr key, there can't
> - * be any acls later on
> + * We found a key greater than an xattr key, there can't be any
> + * ACLs later on.
> */
> if (found_key.type > BTRFS_XATTR_ITEM_KEY)
> return false;
> @@ -3772,17 +3776,22 @@ static noinline bool acls_after_inode_item(struct extent_buffer *leaf,
> scanned++;
>
> /*
> - * it goes inode, inode backrefs, xattrs, extents,
> - * so if there are a ton of hard links to an inode there can
> - * be a lot of backrefs. Don't waste time searching too hard,
> - * this is just an optimization
> + * The item order goes like:
> + * - inode
> + * - inode backrefs
> + * - xattrs
> + * - extents,
> + *
> + * so if there are lots of hard links to an inode there can be
> + * a lot of backrefs. Don't waste time searching too hard,
> + * this is just an optimization.
> */
> if (scanned >= 8)
> break;
> }
> - /* we hit the end of the leaf before we found an xattr or
> - * something larger than an xattr. We have to assume the inode
> - * has acls
> + /*
> + * We hit the end of the leaf before we found an xattr or something
> + * larger than an xattr. We have to assume the inode has ACLs.
> */
> if (*first_xattr_slot == -1)
> *first_xattr_slot = slot;
next prev parent reply other threads:[~2025-04-24 1:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-23 16:53 [PATCH 0/3] Bool return cleanups David Sterba
2025-04-23 16:53 ` [PATCH 1/3] btrfs: trivial conversion to return bool instead of int David Sterba
2025-04-23 16:53 ` [PATCH 2/3] btrfs: switch int dev_replace_is_ongoing variables/parameters to bool David Sterba
2025-04-23 16:53 ` [PATCH 3/3] btrfs: reformat comments in acls_after_inode_item() David Sterba
2025-04-24 1:52 ` Naohiro Aota [this message]
2025-04-25 11:31 ` David Sterba
2025-04-24 1:54 ` [PATCH 0/3] Bool return cleanups Naohiro Aota
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=D9EHQPSBBS4G.2B8ALJ1KNJMET@wdc.com \
--to=naohiro.aota@wdc.com \
--cc=dsterba@suse.com \
--cc=linux-btrfs@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox