* btrfs-progs test error on fsck/012-leaf-corruption
@ 2021-02-18 2:56 Sidong Yang
2021-02-19 16:17 ` David Sterba
0 siblings, 1 reply; 3+ messages in thread
From: Sidong Yang @ 2021-02-18 2:56 UTC (permalink / raw)
To: linux-btrfs
Hi!
I found some error when I run unittest code in btrfs-progs.
fsck/012-leaf-corruption test corrupt leaf and check that it's recovered.
but the test was failed and demsg below
[ 47.284095] BTRFS error (device loop5): device total_bytes should be at most 27660288 but found 67108864
[ 47.284207] BTRFS error (device loop5): failed to read chunk tree: -22
[ 47.286465] BTRFS error (device loop5): open_ctree failed
I'm using kernel version 5.11 and there is no error in old version kernel.
I traced the kernel code and found the code that prints error message.
When it tried to mount btrfs, the function read_one_dev() failed.
I found that code added by the commit 3a160a9331112 cause this problem.
The unittest in btrfs-progs should be changed or kernel code should be patched?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: btrfs-progs test error on fsck/012-leaf-corruption
2021-02-18 2:56 btrfs-progs test error on fsck/012-leaf-corruption Sidong Yang
@ 2021-02-19 16:17 ` David Sterba
2021-02-21 14:09 ` Sidong Yang
0 siblings, 1 reply; 3+ messages in thread
From: David Sterba @ 2021-02-19 16:17 UTC (permalink / raw)
To: Sidong Yang; +Cc: linux-btrfs
On Thu, Feb 18, 2021 at 02:56:14AM +0000, Sidong Yang wrote:
> I found some error when I run unittest code in btrfs-progs.
> fsck/012-leaf-corruption test corrupt leaf and check that it's recovered.
> but the test was failed and demsg below
>
> [ 47.284095] BTRFS error (device loop5): device total_bytes should be at most 27660288 but found 67108864
> [ 47.284207] BTRFS error (device loop5): failed to read chunk tree: -22
> [ 47.286465] BTRFS error (device loop5): open_ctree failed
>
> I'm using kernel version 5.11 and there is no error in old version kernel.
> I traced the kernel code and found the code that prints error message.
> When it tried to mount btrfs, the function read_one_dev() failed.
> I found that code added by the commit 3a160a9331112 cause this problem.
> The unittest in btrfs-progs should be changed or kernel code should be patched?
The kernel check makes sense. The unit test fails because the image is
restored from a dump and not extended to the full size automatically.
After 'extract_image' the image is
-rw-r--r-- 1 root root 27660288 Feb 19 17:47 good.img.restored
-rw-r--r-- 1 root root 186392 Jul 27 2020 good.img.xz
-rwxr-xr-x 1 root root 2788 Feb 19 17:46 test.sh
but with a manual 'truncate -s 67108864 good.img.restored' the test
succeeds.
btrfs-image enlarges the file but it's probably taking the wrong size
2281 dev_size = key.offset + btrfs_dev_extent_length(path.nodes[0], dev_ext);
2282 btrfs_release_path(&path);
2283
2284 btrfs_set_stack_device_total_bytes(dev_item, dev_size);
2285 btrfs_set_stack_device_bytes_used(dev_item, mdres->alloced_chunks);
2286 ret = fstat(out_fd, &buf);
2287 if (ret < 0) {
2288 error("failed to stat result image: %m");
2289 return -errno;
2290 }
2291 if (S_ISREG(buf.st_mode)) {
2292 /* Don't forget to enlarge the real file */
2293 ret = ftruncate64(out_fd, dev_size);
2294 if (ret < 0) {
2295 error("failed to enlarge result image: %m");
2296 return -errno;
2297 }
2298 }
here it's the 'dev_size'. In the superblock dump, the sb.total_size and
sb.dev_item.total_size are both 67108864, which is the correct value.
The size as obtained from the device item in the device tree also matches the
right value
item 6 key (1 DEV_EXTENT 61210624) itemoff 3667 itemsize 48
dev extent chunk_tree 3
chunk_objectid 256 chunk_offset 61210624 length 5898240
chunk_tree_uuid b2834867-4e78-47ee-9877-94d4e39bda43
Which is the key.offset + length = 61210624 + 5898240 = 67108864.
But the code is not called in restore_metadump because of condition
"btrfs_super_num_devices(mdrestore.original_super) != 1"
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: btrfs-progs test error on fsck/012-leaf-corruption
2021-02-19 16:17 ` David Sterba
@ 2021-02-21 14:09 ` Sidong Yang
0 siblings, 0 replies; 3+ messages in thread
From: Sidong Yang @ 2021-02-21 14:09 UTC (permalink / raw)
To: dsterba, linux-btrfs
On Fri, Feb 19, 2021 at 05:17:07PM +0100, David Sterba wrote:
> On Thu, Feb 18, 2021 at 02:56:14AM +0000, Sidong Yang wrote:
> > I found some error when I run unittest code in btrfs-progs.
> > fsck/012-leaf-corruption test corrupt leaf and check that it's recovered.
> > but the test was failed and demsg below
> >
> > [ 47.284095] BTRFS error (device loop5): device total_bytes should be at most 27660288 but found 67108864
> > [ 47.284207] BTRFS error (device loop5): failed to read chunk tree: -22
> > [ 47.286465] BTRFS error (device loop5): open_ctree failed
> >
> > I'm using kernel version 5.11 and there is no error in old version kernel.
> > I traced the kernel code and found the code that prints error message.
> > When it tried to mount btrfs, the function read_one_dev() failed.
> > I found that code added by the commit 3a160a9331112 cause this problem.
> > The unittest in btrfs-progs should be changed or kernel code should be patched?
>
> The kernel check makes sense. The unit test fails because the image is
> restored from a dump and not extended to the full size automatically.
>
> After 'extract_image' the image is
>
> -rw-r--r-- 1 root root 27660288 Feb 19 17:47 good.img.restored
> -rw-r--r-- 1 root root 186392 Jul 27 2020 good.img.xz
> -rwxr-xr-x 1 root root 2788 Feb 19 17:46 test.sh
>
> but with a manual 'truncate -s 67108864 good.img.restored' the test
> succeeds.
>
> btrfs-image enlarges the file but it's probably taking the wrong size
>
> 2281 dev_size = key.offset + btrfs_dev_extent_length(path.nodes[0], dev_ext);
> 2282 btrfs_release_path(&path);
> 2283
> 2284 btrfs_set_stack_device_total_bytes(dev_item, dev_size);
> 2285 btrfs_set_stack_device_bytes_used(dev_item, mdres->alloced_chunks);
> 2286 ret = fstat(out_fd, &buf);
> 2287 if (ret < 0) {
> 2288 error("failed to stat result image: %m");
> 2289 return -errno;
> 2290 }
> 2291 if (S_ISREG(buf.st_mode)) {
> 2292 /* Don't forget to enlarge the real file */
> 2293 ret = ftruncate64(out_fd, dev_size);
> 2294 if (ret < 0) {
> 2295 error("failed to enlarge result image: %m");
> 2296 return -errno;
> 2297 }
> 2298 }
>
> here it's the 'dev_size'. In the superblock dump, the sb.total_size and
> sb.dev_item.total_size are both 67108864, which is the correct value.
>
> The size as obtained from the device item in the device tree also matches the
> right value
>
> item 6 key (1 DEV_EXTENT 61210624) itemoff 3667 itemsize 48
> dev extent chunk_tree 3
> chunk_objectid 256 chunk_offset 61210624 length 5898240
> chunk_tree_uuid b2834867-4e78-47ee-9877-94d4e39bda43
>
> Which is the key.offset + length = 61210624 + 5898240 = 67108864.
>
> But the code is not called in restore_metadump because of condition
> "btrfs_super_num_devices(mdrestore.original_super) != 1"
Thanks for reply. I read the commit 73dd4e3c87c and I understood a
purpose of the commit. but I'm confused the code block that isn't called
in restore_metadump should be called in multi device?
I also checked that test goes good when removing the condition in
restore_metadump().
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-02-21 14:10 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-02-18 2:56 btrfs-progs test error on fsck/012-leaf-corruption Sidong Yang
2021-02-19 16:17 ` David Sterba
2021-02-21 14:09 ` Sidong Yang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).