* btrfs-convert aborts with an assert
@ 2022-06-06 14:03 Torbjörn Jansson
2022-06-06 14:14 ` Nikolay Borisov
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Torbjörn Jansson @ 2022-06-06 14:03 UTC (permalink / raw)
To: linux-btrfs
Hello
i tried to do a btrfs-convert of a ext4 filesystem and after a short while
after starting it i was greeted with:
# btrfs-convert /dev/xxxx
btrfs-convert from btrfs-progs v5.16.2
convert/main.c:1162: do_convert: Assertion `cctx.total_bytes != 0` failed, value 0
btrfs-convert(+0xffb0)[0x557defdabfb0]
btrfs-convert(main+0x6c5)[0x557defdaa125]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f66e1f8bd0a]
btrfs-convert(_start+0x2a)[0x557defdab52a]
Aborted
Any idea whats going on?
Is it a known bug?
Is the btrfs-progs that come with my dist too old?
FYI the ext4 filesystem is a bit large ~10tb of used data on it.
I assume the convert didn't even start in this case and nothing was modified on
the ext4 filesystem, correct? or?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: btrfs-convert aborts with an assert
2022-06-06 14:03 btrfs-convert aborts with an assert Torbjörn Jansson
@ 2022-06-06 14:14 ` Nikolay Borisov
2022-06-06 14:31 ` Nikolay Borisov
2022-06-06 14:34 ` David Sterba
2 siblings, 0 replies; 9+ messages in thread
From: Nikolay Borisov @ 2022-06-06 14:14 UTC (permalink / raw)
To: Torbjörn Jansson, linux-btrfs
On 6.06.22 г. 17:03 ч., Torbjörn Jansson wrote:
> Hello
>
> i tried to do a btrfs-convert of a ext4 filesystem and after a short
> while after starting it i was greeted with:
>
> # btrfs-convert /dev/xxxx
> btrfs-convert from btrfs-progs v5.16.2
>
> convert/main.c:1162: do_convert: Assertion `cctx.total_bytes != 0`
> failed, value 0
> btrfs-convert(+0xffb0)[0x557defdabfb0]
> btrfs-convert(main+0x6c5)[0x557defdaa125]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f66e1f8bd0a]
> btrfs-convert(_start+0x2a)[0x557defdab52a]
> Aborted
>
> Any idea whats going on?
> Is it a known bug?
> Is the btrfs-progs that come with my dist too old?
> FYI the ext4 filesystem is a bit large ~10tb of used data on it.
>
> I assume the convert didn't even start in this case and nothing was
> modified on the ext4 filesystem, correct? or?
>
This suggests that btrfs progs is unable to properly read/parse the
superblock of the ext4 filesystem. So you are right that convert hasn't
even started in this case so your ext4 is intact.
However, that's strange since for ext* related queries we do use libext2fs.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: btrfs-convert aborts with an assert
2022-06-06 14:03 btrfs-convert aborts with an assert Torbjörn Jansson
2022-06-06 14:14 ` Nikolay Borisov
@ 2022-06-06 14:31 ` Nikolay Borisov
2022-06-06 15:00 ` Torbjörn Jansson
2022-06-06 14:34 ` David Sterba
2 siblings, 1 reply; 9+ messages in thread
From: Nikolay Borisov @ 2022-06-06 14:31 UTC (permalink / raw)
To: Torbjörn Jansson, linux-btrfs
On 6.06.22 г. 17:03 ч., Torbjörn Jansson wrote:
> Hello
>
> i tried to do a btrfs-convert of a ext4 filesystem and after a short
> while after starting it i was greeted with:
>
> # btrfs-convert /dev/xxxx
> btrfs-convert from btrfs-progs v5.16.2
>
> convert/main.c:1162: do_convert: Assertion `cctx.total_bytes != 0`
> failed, value 0
> btrfs-convert(+0xffb0)[0x557defdabfb0]
> btrfs-convert(main+0x6c5)[0x557defdaa125]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f66e1f8bd0a]
> btrfs-convert(_start+0x2a)[0x557defdab52a]
> Aborted
>
> Any idea whats going on?
> Is it a known bug?
> Is the btrfs-progs that come with my dist too old?
> FYI the ext4 filesystem is a bit large ~10tb of used data on it.
>
> I assume the convert didn't even start in this case and nothing was
> modified on the ext4 filesystem, correct? or?
>
Care too run the following command and share the output:
echo "show_super_stats -h" | debugfs -f /dev/stdin /dev/loop0
change /dev/loop0 to wherever is your ext4 filesyste, however debugfs
require the fs to be unmounted.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: btrfs-convert aborts with an assert
2022-06-06 14:03 btrfs-convert aborts with an assert Torbjörn Jansson
2022-06-06 14:14 ` Nikolay Borisov
2022-06-06 14:31 ` Nikolay Borisov
@ 2022-06-06 14:34 ` David Sterba
2 siblings, 0 replies; 9+ messages in thread
From: David Sterba @ 2022-06-06 14:34 UTC (permalink / raw)
To: Torbjörn Jansson; +Cc: linux-btrfs
On Mon, Jun 06, 2022 at 04:03:33PM +0200, Torbjörn Jansson wrote:
> Hello
>
> i tried to do a btrfs-convert of a ext4 filesystem and after a short while
> after starting it i was greeted with:
>
> # btrfs-convert /dev/xxxx
> btrfs-convert from btrfs-progs v5.16.2
>
> convert/main.c:1162: do_convert: Assertion `cctx.total_bytes != 0` failed, value 0
> btrfs-convert(+0xffb0)[0x557defdabfb0]
> btrfs-convert(main+0x6c5)[0x557defdaa125]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f66e1f8bd0a]
> btrfs-convert(_start+0x2a)[0x557defdab52a]
> Aborted
Please open an issue on github, thanks.
> Any idea whats going on?
> Is it a known bug?
> Is the btrfs-progs that come with my dist too old?
Two versions back is not that old, but there are bugfixes in each
release, so it's better to stay up to date.
> FYI the ext4 filesystem is a bit large ~10tb of used data on it.
This looks similar to another issue that caused weird checksum errors
(but no problems during conversion).
https://github.com/kdave/btrfs-progs/issues/349 the common point here is
thatt it's 2TB and a multiple in your case.
> I assume the convert didn't even start in this case and nothing was modified on
> the ext4 filesystem, correct? or?
Yeah, until the conversion is completely finished without errors, the
old ext4 is left intact and the new partial btrfs structures are not
recognized as a valid filesystem.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: btrfs-convert aborts with an assert
2022-06-06 14:31 ` Nikolay Borisov
@ 2022-06-06 15:00 ` Torbjörn Jansson
2022-06-06 15:21 ` Nikolay Borisov
2022-06-07 18:24 ` Chris Murphy
0 siblings, 2 replies; 9+ messages in thread
From: Torbjörn Jansson @ 2022-06-06 15:00 UTC (permalink / raw)
To: Nikolay Borisov, linux-btrfs
On 2022-06-06 16:31, Nikolay Borisov wrote:
>
>
> On 6.06.22 г. 17:03 ч., Torbjörn Jansson wrote:
>> Hello
>>
>> i tried to do a btrfs-convert of a ext4 filesystem and after a short while
>> after starting it i was greeted with:
>>
>> # btrfs-convert /dev/xxxx
>> btrfs-convert from btrfs-progs v5.16.2
>>
>> convert/main.c:1162: do_convert: Assertion `cctx.total_bytes != 0` failed,
>> value 0
>> btrfs-convert(+0xffb0)[0x557defdabfb0]
>> btrfs-convert(main+0x6c5)[0x557defdaa125]
>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f66e1f8bd0a]
>> btrfs-convert(_start+0x2a)[0x557defdab52a]
>> Aborted
>>
>> Any idea whats going on?
>> Is it a known bug?
>> Is the btrfs-progs that come with my dist too old?
>> FYI the ext4 filesystem is a bit large ~10tb of used data on it.
>>
>> I assume the convert didn't even start in this case and nothing was modified
>> on the ext4 filesystem, correct? or?
>>
>
> Care too run the following command and share the output:
>
> echo "show_super_stats -h" | debugfs -f /dev/stdin /dev/loop0
>
> change /dev/loop0 to wherever is your ext4 filesyste, however debugfs require
> the fs to be unmounted.
>
See output below.
one more thing, when i ran fsck.ext4 -f on the device before trying to run
btrfs-convert it said things like:
Inode 61475702 extent tree (at level 1) could be shorter. Optimize<y>? yes
Inode 61477092 extent tree (at level 2) could be narrower. Optimize<y>? yes
and then a bunch more, all aditonal looked similar and said narrower.
Filesystem volume name: <none>
Last mounted on: /mnt/data
Filesystem UUID: 78b93577-0bb5-41a1-89d7-3027cf0b9bc2
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr dir_index filetype meta_bg
extent 64bit flex_bg casefold sparse_super large_file huge_file dir_nlink
extra_isize metadata_csum
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 536870912
Block count: 4294967296
Reserved block count: 0
Overhead clusters: 12982806
Free blocks: 2134612618
Free inodes: 536845192
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 4096
Inode blocks per group: 256
First meta block group: 1792
Flex block group size: 16
Filesystem created: Fri Aug 13 17:27:43 2021
Last mount time: Sat May 21 13:56:20 2022
Last write time: Mon Jun 6 15:33:45 2022
Mount count: 0
Maximum mount count: -1
Last checked: Mon Jun 6 15:33:45 2022
Check interval: 0 (<none>)
Lifetime writes: 93 TB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 79d63f5e-1fd3-443f-ba05-1a90b7358160
Journal backup: inode blocks
Checksum type: crc32c
Checksum: 0xb53baa13
Character encoding: utf8-12.1
Directories: 138
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: btrfs-convert aborts with an assert
2022-06-06 15:00 ` Torbjörn Jansson
@ 2022-06-06 15:21 ` Nikolay Borisov
2022-06-06 15:31 ` Torbjörn Jansson
2022-06-07 18:24 ` Chris Murphy
1 sibling, 1 reply; 9+ messages in thread
From: Nikolay Borisov @ 2022-06-06 15:21 UTC (permalink / raw)
To: Torbjörn Jansson, linux-btrfs
On 6.06.22 г. 18:00 ч., Torbjörn Jansson wrote:
> On 2022-06-06 16:31, Nikolay Borisov wrote:
>>
>>
>> On 6.06.22 г. 17:03 ч., Torbjörn Jansson wrote:
>>> Hello
>>>
>>> i tried to do a btrfs-convert of a ext4 filesystem and after a short
>>> while after starting it i was greeted with:
>>>
>>> # btrfs-convert /dev/xxxx
>>> btrfs-convert from btrfs-progs v5.16.2
>>>
>>> convert/main.c:1162: do_convert: Assertion `cctx.total_bytes != 0`
>>> failed, value 0
>>> btrfs-convert(+0xffb0)[0x557defdabfb0]
>>> btrfs-convert(main+0x6c5)[0x557defdaa125]
>>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f66e1f8bd0a]
>>> btrfs-convert(_start+0x2a)[0x557defdab52a]
>>> Aborted
>>>
>>> Any idea whats going on?
>>> Is it a known bug?
>>> Is the btrfs-progs that come with my dist too old?
>>> FYI the ext4 filesystem is a bit large ~10tb of used data on it.
>>>
>>> I assume the convert didn't even start in this case and nothing was
>>> modified on the ext4 filesystem, correct? or?
>>>
>>
>> Care too run the following command and share the output:
>>
>> echo "show_super_stats -h" | debugfs -f /dev/stdin /dev/loop0
>>
>> change /dev/loop0 to wherever is your ext4 filesyste, however debugfs
>> require the fs to be unmounted.
>>
>
> See output below.
>
> one more thing, when i ran fsck.ext4 -f on the device before trying to
> run btrfs-convert it said things like:
> Inode 61475702 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 61477092 extent tree (at level 2) could be narrower. Optimize<y>?
> yes
> and then a bunch more, all aditonal looked similar and said narrower.
>
>
> Filesystem volume name: <none>
> Last mounted on: /mnt/data
> Filesystem UUID: 78b93577-0bb5-41a1-89d7-3027cf0b9bc2
> Filesystem magic number: 0xEF53
> Filesystem revision #: 1 (dynamic)
> Filesystem features: has_journal ext_attr dir_index filetype
> meta_bg extent 64bit flex_bg casefold sparse_super large_file huge_file
> dir_nlink extra_isize metadata_csum
> Filesystem flags: signed_directory_hash
> Default mount options: user_xattr acl
> Filesystem state: clean
> Errors behavior: Continue
> Filesystem OS type: Linux
> Inode count: 536870912
> Block count: 4294967296
> Reserved block count: 0
> Overhead clusters: 12982806
> Free blocks: 2134612618
> Free inodes: 536845192
> First block: 0
> Block size: 4096
> Fragment size: 4096
> Group descriptor size: 64
> Blocks per group: 32768
> Fragments per group: 32768
> Inodes per group: 4096
> Inode blocks per group: 256
> First meta block group: 1792
> Flex block group size: 16
> Filesystem created: Fri Aug 13 17:27:43 2021
> Last mount time: Sat May 21 13:56:20 2022
> Last write time: Mon Jun 6 15:33:45 2022
> Mount count: 0
> Maximum mount count: -1
> Last checked: Mon Jun 6 15:33:45 2022
> Check interval: 0 (<none>)
> Lifetime writes: 93 TB
> Reserved blocks uid: 0 (user root)
> Reserved blocks gid: 0 (group root)
> First inode: 11
> Inode size: 256
> Required extra isize: 32
> Desired extra isize: 32
> Journal inode: 8
> Default directory hash: half_md4
> Directory Hash Seed: 79d63f5e-1fd3-443f-ba05-1a90b7358160
> Journal backup: inode blocks
> Checksum type: crc32c
> Checksum: 0xb53baa13
> Character encoding: utf8-12.1
> Directories: 138
>
So indeed it seems like you've hit a bug with the way progs interacts
with the information provided by e2fsprogs. I will work on a fix and
will post it to the mailing list probably tomorrow. In the mean time it
would be best to open a github issue to track progress there as well.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: btrfs-convert aborts with an assert
2022-06-06 15:21 ` Nikolay Borisov
@ 2022-06-06 15:31 ` Torbjörn Jansson
0 siblings, 0 replies; 9+ messages in thread
From: Torbjörn Jansson @ 2022-06-06 15:31 UTC (permalink / raw)
To: Nikolay Borisov, linux-btrfs
On 2022-06-06 17:21, Nikolay Borisov wrote:
>
>
> On 6.06.22 г. 18:00 ч., Torbjörn Jansson wrote:
>> On 2022-06-06 16:31, Nikolay Borisov wrote:
>>>
>>>
>>> On 6.06.22 г. 17:03 ч., Torbjörn Jansson wrote:
>>>> Hello
>>>>
>>>> i tried to do a btrfs-convert of a ext4 filesystem and after a short while
>>>> after starting it i was greeted with:
>>>>
>>>> # btrfs-convert /dev/xxxx
>>>> btrfs-convert from btrfs-progs v5.16.2
>>>>
>>>> convert/main.c:1162: do_convert: Assertion `cctx.total_bytes != 0` failed,
>>>> value 0
>>>> btrfs-convert(+0xffb0)[0x557defdabfb0]
>>>> btrfs-convert(main+0x6c5)[0x557defdaa125]
>>>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f66e1f8bd0a]
>>>> btrfs-convert(_start+0x2a)[0x557defdab52a]
>>>> Aborted
>>>>
>>>> Any idea whats going on?
>>>> Is it a known bug?
>>>> Is the btrfs-progs that come with my dist too old?
>>>> FYI the ext4 filesystem is a bit large ~10tb of used data on it.
>>>>
>>>> I assume the convert didn't even start in this case and nothing was
>>>> modified on the ext4 filesystem, correct? or?
>>>>
>>>
>>> Care too run the following command and share the output:
>>>
>>> echo "show_super_stats -h" | debugfs -f /dev/stdin /dev/loop0
>>>
>>> change /dev/loop0 to wherever is your ext4 filesyste, however debugfs
>>> require the fs to be unmounted.
>>>
>>
>> See output below.
>>
>> one more thing, when i ran fsck.ext4 -f on the device before trying to run
>> btrfs-convert it said things like:
>> Inode 61475702 extent tree (at level 1) could be shorter. Optimize<y>? yes
>> Inode 61477092 extent tree (at level 2) could be narrower. Optimize<y>? yes
>> and then a bunch more, all aditonal looked similar and said narrower.
>>
>>
>> Filesystem volume name: <none>
>> Last mounted on: /mnt/data
>> Filesystem UUID: 78b93577-0bb5-41a1-89d7-3027cf0b9bc2
>> Filesystem magic number: 0xEF53
>> Filesystem revision #: 1 (dynamic)
>> Filesystem features: has_journal ext_attr dir_index filetype meta_bg
>> extent 64bit flex_bg casefold sparse_super large_file huge_file dir_nlink
>> extra_isize metadata_csum
>> Filesystem flags: signed_directory_hash
>> Default mount options: user_xattr acl
>> Filesystem state: clean
>> Errors behavior: Continue
>> Filesystem OS type: Linux
>> Inode count: 536870912
>> Block count: 4294967296
>> Reserved block count: 0
>> Overhead clusters: 12982806
>> Free blocks: 2134612618
>> Free inodes: 536845192
>> First block: 0
>> Block size: 4096
>> Fragment size: 4096
>> Group descriptor size: 64
>> Blocks per group: 32768
>> Fragments per group: 32768
>> Inodes per group: 4096
>> Inode blocks per group: 256
>> First meta block group: 1792
>> Flex block group size: 16
>> Filesystem created: Fri Aug 13 17:27:43 2021
>> Last mount time: Sat May 21 13:56:20 2022
>> Last write time: Mon Jun 6 15:33:45 2022
>> Mount count: 0
>> Maximum mount count: -1
>> Last checked: Mon Jun 6 15:33:45 2022
>> Check interval: 0 (<none>)
>> Lifetime writes: 93 TB
>> Reserved blocks uid: 0 (user root)
>> Reserved blocks gid: 0 (group root)
>> First inode: 11
>> Inode size: 256
>> Required extra isize: 32
>> Desired extra isize: 32
>> Journal inode: 8
>> Default directory hash: half_md4
>> Directory Hash Seed: 79d63f5e-1fd3-443f-ba05-1a90b7358160
>> Journal backup: inode blocks
>> Checksum type: crc32c
>> Checksum: 0xb53baa13
>> Character encoding: utf8-12.1
>> Directories: 138
>>
>
> So indeed it seems like you've hit a bug with the way progs interacts with the
> information provided by e2fsprogs. I will work on a fix and will post it to the
> mailing list probably tomorrow. In the mean time it would be best to open a
> github issue to track progress there as well.
>
Thanks.
i created a bugreport: https://bugzilla.kernel.org/show_bug.cgi?id=216086
i will probably try to do what i wanted in a different way due to this bug so i
don't have to rely on btrfs-convert.
i was going to convert from md (raid1) + lvm + ext4 to plain btrfs with raid1
but now i think i will split the md mirror first, create a new btrfs filesystem
and them copy over the data myself.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: btrfs-convert aborts with an assert
2022-06-06 15:00 ` Torbjörn Jansson
2022-06-06 15:21 ` Nikolay Borisov
@ 2022-06-07 18:24 ` Chris Murphy
2022-06-09 17:55 ` Torbjörn Jansson
1 sibling, 1 reply; 9+ messages in thread
From: Chris Murphy @ 2022-06-07 18:24 UTC (permalink / raw)
To: Torbjörn Jansson; +Cc: Nikolay Borisov, Btrfs BTRFS
On Mon, Jun 6, 2022 at 12:51 PM Torbjörn Jansson <torbjorn@jansson.tech> wrote:
> Filesystem features: has_journal ext_attr dir_index filetype meta_bg
> extent 64bit flex_bg casefold sparse_super large_file huge_file dir_nlink
> extra_isize metadata_csum
^^casefold
I don't think this is related to the reported problem, but it occurs
to me maybe btrfs-progs should check for this feature and warn? The
feature being set means there could be behavioral expectations that
Btrfs can't currently provide since it doesn't support casefolding.
--
Chris Murphy
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: btrfs-convert aborts with an assert
2022-06-07 18:24 ` Chris Murphy
@ 2022-06-09 17:55 ` Torbjörn Jansson
0 siblings, 0 replies; 9+ messages in thread
From: Torbjörn Jansson @ 2022-06-09 17:55 UTC (permalink / raw)
To: Chris Murphy; +Cc: Nikolay Borisov, Btrfs BTRFS
On 2022-06-07 20:24, Chris Murphy wrote:
> On Mon, Jun 6, 2022 at 12:51 PM Torbjörn Jansson <torbjorn@jansson.tech> wrote:
>
>> Filesystem features: has_journal ext_attr dir_index filetype meta_bg
>> extent 64bit flex_bg casefold sparse_super large_file huge_file dir_nlink
>> extra_isize metadata_csum
>
> ^^casefold
>
> I don't think this is related to the reported problem, but it occurs
> to me maybe btrfs-progs should check for this feature and warn? The
> feature being set means there could be behavioral expectations that
> Btrfs can't currently provide since it doesn't support casefolding.
>
In my case i planed on using it but since, at the time, the ext4 tools for my
dist did not support changing the flag properly i never started to use it.
i'm not a dev and don't know all the details about this but i think at least
there should not be possible to end up with duplicate filenames as a result of
this.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-06-09 17:55 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-06 14:03 btrfs-convert aborts with an assert Torbjörn Jansson
2022-06-06 14:14 ` Nikolay Borisov
2022-06-06 14:31 ` Nikolay Borisov
2022-06-06 15:00 ` Torbjörn Jansson
2022-06-06 15:21 ` Nikolay Borisov
2022-06-06 15:31 ` Torbjörn Jansson
2022-06-07 18:24 ` Chris Murphy
2022-06-09 17:55 ` Torbjörn Jansson
2022-06-06 14:34 ` David Sterba
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.