On Thu, Feb 20, 2025 at 08:11:46AM +0100, Christophe JAILLET wrote:
> Le 20/02/2025 à 06:55, Naohiro Aota a écrit :
> > On Wed Feb 19, 2025 at 11:10 PM JST, Christophe JAILLET wrote:
> >> This code snippet is written twice in row, so remove one of them.
> >>
> >> This was apparently added by accident in commit efe28fcf2e47 ("btrfs:
> >> handle unexpected parent block offset in btrfs_alloc_tree_block()")
> >>
> >> Signed-off-by: Christophe JAILLET <christophe.jaillet@xxxxxxxxxx>
> >> ---
> >> fs/btrfs/zoned.c | 9 ---------
> >> 1 file changed, 9 deletions(-)
> >>
> >> diff --git a/fs/btrfs/zoned.c b/fs/btrfs/zoned.c
> >> index b5b9d16664a8..6c4534316aad 100644
> >> --- a/fs/btrfs/zoned.c
> >> +++ b/fs/btrfs/zoned.c
> >> @@ -1663,15 +1663,6 @@ int btrfs_load_block_group_zone_info(struct btrfs_block_group *cache, bool new)
> >> }
> >>
> >> out:
> >> - /* Reject non SINGLE data profiles without RST */
> >> - if ((map->type & BTRFS_BLOCK_GROUP_DATA) &&
> >> - (map->type & BTRFS_BLOCK_GROUP_PROFILE_MASK) &&
> >> - !fs_info->stripe_root) {
> >> - btrfs_err(fs_info, "zoned: data %s needs raid-stripe-tree",
> >> - btrfs_bg_type_to_raid_name(map->type));
> >> - return -EINVAL;
> >> - }
> >> -
> >> /* Reject non SINGLE data profiles without RST. */
> >> if ((map->type & BTRFS_BLOCK_GROUP_DATA) &&
> >> (map->type & BTRFS_BLOCK_GROUP_PROFILE_MASK) &&
> >
> > Thanks, but which repository/branch are you working with? I cannot
> > find the duplicated lines in btrfs/for-next, linus/master, nor
> > linux-stable. Also, the pointed commit seems wrong too.
>
> Sorry for the lack of context.
>
> This is based on linux-next. In my case -next-20250219
>
> This can be seen at :
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/fs/btrfs/zoned.c?id=efe28fcf2e47aa5142bff2c284ea7337b40901e8#n1666
>
> The commit Id is the one given at :
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/fs/btrfs/zoned.c?id=efe28fcf2e47aa5142bff2c284ea7337b40901e8
For the record, the patch has been removed from for-next, and it was
actually wrong, probably a result of some rebase conflict.
