[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <08c8618c-9573-35ca-f498-9e09520cf86f@huaweicloud.com>
Date: Tue, 27 Jun 2023 18:57:30 +0800
From: Kemeng Shi <shikemeng@...weicloud.com>
To: Theodore Ts'o <tytso@....edu>
Cc: linux-ext4@...r.kernel.org
Subject: Re: mkfs.ext4 failed when orphan_file is enabled
on 6/27/2023 10:46 AM, Kemeng Shi wrote:
>
>
> on 6/27/2023 2:00 AM, Theodore Ts'o wrote:
>> On Mon, Jun 26, 2023 at 08:48:23PM +0800, Kemeng Shi wrote:
>>> Hi all, I find that "kvm-xfstests -c ext4/1k ext4/049" is failed on
>>> current dev branch because of mkfs.ext4 failure.
>>
>> Hmm, I'm not seeing this mkfs.ext4 failure using 1.47.0. I have two
>> cherry-picks on top of 1.47, but neither relate to mkfs.ext4:
>>
>> 24a11cc371a4 ("e2fsck: Suppress "orphan file is clean" message in preen mode")
>>
>> and
>>
>> 8798bbb81687 ("e2fsck: fix handling of a invalid symlink in an inline_data directory")
>>
>> See:
>>
>> root@...-xfstests:~# /sbin/mkfs.ext4 -F -b 4096 -g 8192 -N 1024 -I 4096 /dev/vdc
>> mke2fs 1.47.0 (5-Feb-2023)
>> /dev/vdc contains a ext4 file system
>> last mounted on /vdc on Sun Jun 25 22:14:30 2023
>> Discarding device blocks: done
>> Creating filesystem with 1310720 4k blocks and 1280 inodes
>> Filesystem UUID: 127d490e-6caa-45cf-b5da-5616c5564a1a
>> Superblock backups stored on blocks:
>> 8192, 24576, 40960, 57344, 73728, 204800, 221184, 401408, 663552,
>> 1024000
>>
>> Allocating group tables: done
>> Writing inode tables: done
>> Creating journal (16384 blocks): done
>> Writing superblocks and filesystem accounting information: done
>>
>> Can you confirm what version of e2fsprogs you are using? Is it
>> exactly 1.47.0, or do you have some additional commits (either from
>> the upstream master or maint branches) applied?
> For virutal machine, I use built-in e2fsprogs in image[1]. For host mahcine, I build mke2fs
> from the upstream master branch with commit e76886f76dfca ("Merge branch 'maint' into next").
> I find some more clues that rename from mke2fs to mkfs.ext4 will cause this issue:
>
> /* make sure mkfs.ext4 and mke2fs is renamed */
> root@...-xfstests:~# md5sum /sbin/mkfs.ext4
> 746f94dbfef93ed68bd760530613b176 /sbin/mkfs.ext4
> root@...-xfstests:~# md5sum /sbin/mke2fs
> 746f94dbfef93ed68bd760530613b176 /sbin/mke2fs
>
> /* /sbin/mkfs.ext4 failed */
> root@...-xfstests:~# /sbin/mkfs.ext4 -F -b 4096 -g 8192 -N 1024 -I 4096 /dev/vdc
> mke2fs 1.47.0 (5-Feb-2023)
> /dev/vdc contains a ext2 file system
> created on Tue Jun 27 10:28:17 2023
> Discarding device blocks: done
> Creating filesystem with 1310720 4k blocks and 1280 inodes
> Filesystem UUID: d7287d23-c4fa-42da-8d53-14078dec8d70
> Superblock backups stored on blocks:
> 8192, 24576, 40960, 57344, 73728, 204800, 221184, 401408, 663552,
> 1024000
>
> Allocating group tables: done
> Writing inode tables: done
> Creating journal (16384 blocks): done
> * mkfs.ext4: Inode checksum does not match inode while creating orphan file *
>
> /* /sbin/mke2fs successed */
> root@...-xfstests:~# /sbin/mke2fs -F -b 4096 -g 8192 -N 1024 -I 4096 /dev/vdc
> mke2fs 1.47.0 (5-Feb-2023)
> Discarding device blocks: done
> Creating filesystem with 1310720 4k blocks and 1280 inodes
> Filesystem UUID: 0e01e99b-52bf-4c2c-b986-fb497780bf40
> Superblock backups stored on blocks:
> 8192, 24576, 40960, 57344, 73728, 204800, 221184, 401408, 663552,
> 1024000
>
> Allocating group tables: done
> Writing inode tables: done
> Writing superblocks and filesystem accounting information: done
>
> This can be reproduced in my host machine too.
>
> [1]https://mirrors.edge.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests/root_fs.img.amd64
>
There are some updates for the issue. After a quick look at mke2fs.c,
I think the bug is triggered as following:
main
...
/* unused inode is not zeroed dute as lazy_itable_init is set */
write_inode_tables(fs, lazy_itable_init, itable_zeroed) (lazy_flag=1,
itable_zeroed=0)
...
ext2fs_create_orphan_file
/* get a new uninitialized inode */
ext2fs_new_inode
/* read and check checksum of uninitialized inode */
ext2fs_read_inode
/* read uninitialized inode from disk */
io_channel_read_blk64
/* check checksum of non zeroed inode and failed here*/
ext2fs_inode_csum_verify
I disable lazy_itable_init by force lazy_flag=0 when calling
write_inode_tables to prove this and the problem is solved
as expected.
Wish this help and correct me if I missed anything.
--
Best wishes
Kemeng Shi
Powered by blists - more mailing lists