Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2] btrfs-progs: convert-ext2: insert a dummy inode item before inode ref
Date: Tue, 16 Jan 2024 19:47:38 +0100	[thread overview]
Message-ID: <20240116184738.GE31555@twin.jikos.cz> (raw)
In-Reply-To: <6e1e07ad53a9e716be28e4d505042a50c1676254.1705134953.git.wqu@suse.com>

On Sat, Jan 13, 2024 at 07:07:06PM +1030, Qu Wenruo wrote:
> [BUG]
> There is a report about failed btrfs-convert, which shows the following
> error:
> 
>   Create btrfs metadata
>   corrupt leaf: root=5 block=5001931145216 slot=1 ino=89911763, invalid previous key objectid, have 89911762 expect 89911763
>   leaf 5001931145216 items 336 free space 7 generation 90 owner FS_TREE
>   leaf 5001931145216 flags 0x1(WRITTEN) backref revision 1
>   fs uuid 8b69f018-37c3-4b30-b859-42ccfcbe2449
>   chunk uuid 448ce78c-ea41-49f6-99dc-46ad80b93da9
>           item 0 key (89911762 INODE_REF 3858733) itemoff 16222 itemsize 61
>                   index 171 namelen 51 name: [FILENAME1]
>           item 1 key (89911763 INODE_REF 3858733) itemoff 16161 itemsize 61
>                   index 103 namelen 51 name: [FILENAME2]
> 
> [CAUSE]
> When iterating a directory, btrfs-convert would insert the DIR_ITEMs,
> along with the INODE_REF of that inode.
> 
> This leads to above stray INODE_REFs, and trigger the tree-checker.
> 
> This can only happen for large fs, as for most cases we have all these
> modified tree blocks cached, thus tree-checker won't be triggered.
> But when the tree block cache is not hit, and we have to read from disk,
> then such behavior can lead to above tree-checker error.
> 
> [FIX]
> Insert a dummy INODE_ITEM for the INODE_REF first, the inode items would
> be updated when iterating the child inode of the directory.
> 
> Issue: #731
> Signed-off-by: Qu Wenruo <wqu@suse.com>

Thanks, the cached data are uncovering some bugs, I wonder if
https://github.com/kdave/btrfs-progs/issues/349 could be also caused by
that.

> ---
>  check/mode-common.h   | 15 ---------------
>  common/utils.h        | 16 ++++++++++++++++
>  convert/source-ext2.c | 30 ++++++++++++++++++++----------
>  convert/source-fs.c   | 20 ++++++++++++++++++++
>  4 files changed, 56 insertions(+), 25 deletions(-)
> 
> ---
> Changelog:
> v2:
> - Initialized dummy inodes' mode/generation/transid
>   As the mode can still trigger tree-checker warnings.
> 
> diff --git a/check/mode-common.h b/check/mode-common.h
> index 894bbbb8141b..80672e51e870 100644
> --- a/check/mode-common.h
> +++ b/check/mode-common.h
> @@ -167,21 +167,6 @@ static inline bool is_valid_imode(u32 imode)
> 
>  int recow_extent_buffer(struct btrfs_root *root, struct extent_buffer *eb);
> 
> -static inline u32 btrfs_type_to_imode(u8 type)
> -{
> -	static u32 imode_by_btrfs_type[] = {
> -		[BTRFS_FT_REG_FILE]	= S_IFREG,
> -		[BTRFS_FT_DIR]		= S_IFDIR,
> -		[BTRFS_FT_CHRDEV]	= S_IFCHR,
> -		[BTRFS_FT_BLKDEV]	= S_IFBLK,
> -		[BTRFS_FT_FIFO]		= S_IFIFO,
> -		[BTRFS_FT_SOCK]		= S_IFSOCK,
> -		[BTRFS_FT_SYMLINK]	= S_IFLNK,
> -	};
> -
> -	return imode_by_btrfs_type[(type)];
> -}

Why did you move this helper to utils.h? Here it's available for
anything that needs it. Mkfs and convert share some code, no style
problem to cross include from each other. Also moving it to utils.h is
going the opposite way, it's a header that's a default if there's no
better place. Lot of code has been factored out of it.

  reply	other threads:[~2024-01-16 18:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-13  8:37 [PATCH v2] btrfs-progs: convert-ext2: insert a dummy inode item before inode ref Qu Wenruo
2024-01-16 18:47 ` David Sterba [this message]
2024-01-16 20:06   ` David Sterba
2024-01-16 20:13   ` Qu Wenruo
2024-01-17  0:56     ` 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=20240116184738.GE31555@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --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