(sorry, reply all this time) On Sun, Apr 26, 2020 at 12:23 AM Yegor Yegorov <gochkin@xxxxxxxxx> wrote: > $> btrfs insp dump-s -f /dev/nvme0n1p3 > > chunk_root 1048576 > chunk_root_level 1 > sys_chunk_array[2048]: > item 0 key (FIRST_CHUNK_TREE CHUNK_ITEM 1048576) > length 4194304 owner 2 stripe_len 65536 type SYSTEM > io_align 4096 io_width 4096 sector_size 4096 > num_stripes 1 sub_stripes 0 > stripe 0 devid 1 offset 1048576 > dev_uuid e2815a2c-6ec8-45c6-baae-7f429a5f0f78 Super and backups say the system chunk is at 1048576, and root is at 8612052992. btrfs insp dump-t -b 8612052992 btrfs insp dump-t -b 1048576 > superblock: bytenr=274877906944, device=/dev/nvme0n1p3 > --------------------------------------------------------- > ERROR: bad magic on superblock on /dev/nvme0n1p3 at 274877906944 ? OK but why does it even go looking for this 3rd super? A file system of this size doesn't have a 3rd super, which appears at 256G. There's no dmesg for the resize? This should report the block group changes that happen as part of the resize; and also the fs size change; and also the partition map change. And if it is rebooted, then dump-super shouldn't be looking for a 3rd super. What do you get for 'lsblk' -- Chris Murphy
