From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Filipe Manana <fdmanana@kernel.org>, Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org, David Sterba <dsterba@suse.com>
Subject: Re: [PATCH v3 07/11] btrfs: remove extent_map::block_start member
Date: Fri, 24 May 2024 08:53:07 +0930 [thread overview]
Message-ID: <5cb1affd-8f9b-4879-8815-56d716733910@gmx.com> (raw)
In-Reply-To: <CAL3q7H6C23anvfyxCumZ8TveM+xgPnMZFWrDUo_Gop=kc1C9-g@mail.gmail.com>
在 2024/5/24 03:26, Filipe Manana 写道:
>> @@ -2703,7 +2700,7 @@ static int btrfs_find_new_delalloc_bytes(struct btrfs_inode *inode,
>> if (IS_ERR(em))
>> return PTR_ERR(em);
>>
>> - if (em->block_start != EXTENT_MAP_HOLE)
>> + if (extent_map_block_start(em) != EXTENT_MAP_HOLE)
> This should be: if (em->disk_bytenr != EXTENT_MAP_HOLE)
That's fine, the extent_map_block_start() would handle it correctly, as
for any disk_bytenr >= EXTENT_MAP_LAST_BYTE, it would return the
disk_bytenr directly.
But yes, we can save one if() check and would update it.
Thanks,
Qu
>
> Everything else looks fine. Thanks.
next prev parent reply other threads:[~2024-05-23 23:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-23 5:03 [PATCH v3 00/11] btrfs: extent-map: unify the members with btrfs_ordered_extent Qu Wenruo
2024-05-23 5:03 ` [PATCH v3 01/11] btrfs: rename extent_map::orig_block_len to disk_num_bytes Qu Wenruo
2024-05-23 5:03 ` [PATCH v3 02/11] btrfs: export the expected file extent through can_nocow_extent() Qu Wenruo
2024-05-23 5:03 ` [PATCH v3 03/11] btrfs: introduce new members for extent_map Qu Wenruo
2024-05-23 16:53 ` Filipe Manana
2024-05-23 23:19 ` Qu Wenruo
2024-05-24 10:59 ` David Sterba
2024-05-23 18:21 ` Filipe Manana
2024-05-23 5:03 ` [PATCH v3 04/11] btrfs: introduce extra sanity checks for extent maps Qu Wenruo
2024-05-23 16:57 ` Filipe Manana
2024-05-23 5:03 ` [PATCH v3 05/11] btrfs: remove extent_map::orig_start member Qu Wenruo
2024-05-23 5:03 ` [PATCH v3 06/11] btrfs: remove extent_map::block_len member Qu Wenruo
2024-05-23 5:03 ` [PATCH v3 07/11] btrfs: remove extent_map::block_start member Qu Wenruo
2024-05-23 17:56 ` Filipe Manana
2024-05-23 23:23 ` Qu Wenruo [this message]
2024-05-23 5:03 ` [PATCH v3 08/11] btrfs: cleanup duplicated parameters related to can_nocow_file_extent_args Qu Wenruo
2024-05-23 5:03 ` [PATCH v3 09/11] btrfs: cleanup duplicated parameters related to btrfs_alloc_ordered_extent Qu Wenruo
2024-05-23 18:17 ` Filipe Manana
2024-05-23 5:03 ` [PATCH v3 10/11] btrfs: cleanup duplicated parameters related to create_io_em() Qu Wenruo
2024-05-23 5:03 ` [PATCH v3 11/11] btrfs: cleanup duplicated parameters related to btrfs_create_dio_extent() Qu Wenruo
2024-05-23 10:23 ` [PATCH v3 00/11] btrfs: extent-map: unify the members with btrfs_ordered_extent Johannes Thumshirn
2024-05-23 18:26 ` Filipe Manana
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=5cb1affd-8f9b-4879-8815-56d716733910@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=dsterba@suse.com \
--cc=fdmanana@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=wqu@suse.com \
/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