Created attachment 211591 [details]
btrfsimage binary

[root@f23s /]# btrfs-image -c9 -t4 /dev/VG/hooka bug115851.btrfs.img

More info. 

- Reproduces with btrfs-progs 4.5.1 (btrfs-progs-4.5.1-1.fc25.x86_64)
- Does not crash with seed device mounted alone.
- Crashes upon adding first device (while still ro, and after rw remount)

# btrfs dev add /dev/VG/disk4 /mnt/0
Performing full device TRIM (15.00GiB) ...
# btrfs fi usage /mnt/0
cmds-fi-usage.c:538: load_device_info: Assertion `ndevs >= fi_args.num_devices` failed.
btrfs(+0x3e35f)[0x55a898e8c35f]
btrfs(load_chunk_and_device_info+0x27)[0x55a898e8c3c7]
btrfs(cmd_filesystem_usage+0x18a)[0x55a898e8c59a]
btrfs(main+0x7d)[0x55a898e5dc4d]
/lib64/libc.so.6(__libc_start_main+0xf0)[0x7f3a54d8f580]
btrfs(_start+0x29)[0x55a898e5dd59]

This looks like an interesting bug to hunt down for a newcomer to Btrfs as myself. If others agree, I am happy to have this assigned to me and I will start looking into it this evening.

IIRC there's insufficient information obtained from kernel through the FS_INFO ioctl, the seeding device is not accounted. Fixing that would need add a v2 ioctl or provide the information via the sysfs interface. Both need a lot of work as they're touching interfaces, but we could get rid of the assertion and see what's possible to do here.

Thanks for assigning this to me David.

I will study this and report soon :)

Sorry I got sidetracked and dropped the ball here.

I am going to check if this bug still happens since I have a new contributor who might be interested in solving it.

Will share what I find.

Hello!

I'm a btrfs newbie and trying to learn more about it by resolving this issue. 

And thanks Luis for sharing this with me!

With btrfs-progs 4.10.1-1 (Arch Linux) I can reproduce this issue but with a different outcome. (assertion is replaced with a program error)

# btrfstune -S 1 /dev/vda1
# mkdir /mnt/0 && mount /dev/vda1 /mnt/0
# btrfs dev add /dev/vdb1 /mnt/0
# btrfs dev add /dev/vdc1 /mnt/0
# btrfs dev add /dev/vdd1 /mnt/0

# btrfs fi show /mnt/0
Label: none  uuid: ad8c6e66-d1f4-4ef1-99c0-4c46e866aaaf
        Total devices 4 FS bytes used 304.00KiB
        devid    1 size 5.00GiB used 519.88MiB path /dev/vda1
        devid    2 size 5.00GiB used 832.00MiB path /dev/vdb1
        devid    3 size 5.00GiB used 0.00B path /dev/vdc1
        devid    4 size 5.00GiB used 0.00B path /dev/vdd1

# btrfs fi usage /mnt/0 
ERROR: unexpected number of devices: 3 >= 3
ERROR: cannot get space info on '/mnt/0': No such device

I'm not sure but to me, this means that the issue still exists.

Shall I start implementing a fix? 

If so, I'd be very happy if you provide some pointers to me. (pun not intended)

Have a great day

First step is we need you to run a development kernel.

https://btrfs.wiki.kernel.org/index.php/Developer's_FAQ#How_to_get_started_-_development

This is the branch you want to run:
https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git/log/?h=for-next

Let me know how that goes. I can help :)

Luis

This might be better discussed on list to ensure there's congruence in dev and user expectations; and in particular I think this needs a design that accounts for the realistic long term goal, so that a short term scope doesn't interfere or make the long term more difficult.

The matrix of possibilities, most of which are not yet implemented in btrfs-progs:

1. 1 dev seed -> 1 dev sprout
2. 2+ dev seed -> 1 dev sprout
3. 1 dev seed -> 2+ dev sprout
4. 2+ dev seed -> 2+ dev sprout

Near as I can tell 2, 3, 4 are not implemented. It's an immediate problem whether and how the profile (single, raid0, raid1) is to be inherited from seed to sprout. If I have a 4 disk raid1 volume, to create a sprout must I add a minimum of two devices? Or is it valid to have raid1 profile seed chunks, where writes to go single profile sprout chunks? Anyway point is, it needs a design to answer these things.

Next, and even more importantly as it applies to the simple case of single to single, the way we do this right now is beyond confusing because the remount ro to rw changes the volume UUID being mounted. The ro mount is the seed, the rw mount is the sprout. This is not really a remount, it's a umount of the seed, and a mount of the sprout. But what if there's more than one sprout? This is asking for trouble so I think the remount rw should be disallowed making it clear the ro seed cannot be mounted rw. Instead it's necessary to umount it and explicitly mount the rw sprout, and which sprout.

Also part of the ambiguity is that 'btrfs dev add' is more like mkfs.btrfs in the context of seed-sprout. The new device isn't really added to the seed, because the seed is read only. What's really happening is a mkfs.btrfs with a "backing device" which is the seed; in some sense it has more in common with the mkfs.btrfs --rootdir option. 

So I even wonder if 'btrfs dev add' is appropriate for creating sprouts, and if instead it should be in mkfs.btfs with a --seed option to specify the backing seed, and thereby what we are making is a sprout, which has a new UUID, and possibly different chunk profiles than the seed.

I've created a thread in the mailing list:
https://mail-archive.com/linux-btrfs@vger.kernel.org/msg64036.html

Chris, I hope it is OK that I quoted you in the email :)

Cengiz, I assumed you have subscribed to the mailing list. If not, let me know and I will CC you in this mail thread.

Thanks for looking into this

This is a semi-automated bugzilla cleanup, report is against an old kernel version. If the problem still happens, please open a new bug. Thanks.