The problem is caused by the design of btrfs-progs which doesn't have a reliable way to determine whether we should preallocate extents. The problem is mostly exposed by recent delayed-ref patches, as tree blocks are not committed to trees immediately, delaying block group used space update, and basically screw up chunk preallocator. -d/-n can not fix the problem, as long as our metadata usage exceed one block group, we will hit ENOSPC anyway. This bug should also affect mkfs.btrfs --rootdir. We can have a workaround to make transaction commit more frequently thus has a higher chance to make chunk preallocator work, but it's not the ultimate solution. I'll keep you updated on this bug. Thanks, Qu On 2019/5/23 上午6:44, Qu Wenruo wrote: > > > On 2019/5/22 下午10:37, Daniel Martinez wrote: >> Hello, >> >> I've converted an ext4 filesystem (after a few attempts, and after >> rolling back to a system running both the kernel and btrfs-progs 4.12) >> to a single disk btrfs filesystem, but to do so I needed to disable >> data checksums and small file inlining, otherwise I would get ENOSPC. > > We need extra debugging info and output in btrfs-progs to make it clear > what's the root cause of the ENOSPC during convert. > > If you have a small enough image, would you please upload the image for > us to analyse? > >> >> Now that I've defragged everything, > > Defrag in ext4 may not help much for btrfs-convert. > > The ext4 block group design makes it fragmented in nature, each block > group will have some space used in its beginning, which fragments the > usable space of btrfs. > > IIRC there is a feature for ext4 to make unused block group completely > blank, not sure what the feature is. > >> I want to enable those features >> back for all the existing files (datasums mainly). How can I go about >> doing that? > > You can manually remove the NOCOW attr by "chattr -C" > And then re-write all existing files, you'll get back the csum. > > For inlined file, as long as you're not using "max_inline=0", any new > file smaller than 2K should already be inlined. > >> >> I assume `--init-csum-tree` would recreate the checksums, but will it >> also set the appropriate flags so that all new files in all >> subdirectories have checksums aswell? > > Don't use that, unless you know what you're doing. > > It's for heavily corrupted fs to rebuild its csum tree, not for your use > case. > > Thanks, > Qu > >> >> When I tried to run it (back on 4.19 kernel and btrfs-progs 4.20), it >> ran for a few hours and then gave me this error: >> >> Creating a new CRC tree >> Opening filesystem to check... >> Checking filesystem on /dev/sdb2 >> UUID: eb930a78-f6f7-4552-8200-6ebdd6c56b93 >> Reinitialize checksum tree >> Unable to find block group for 0 >> Unable to find block group for 0 >> Unable to find block group for 0 >> ctree.c:2245: split_leaf: BUG_ON `1` triggered, value 1 >> btrfs(+0x141e9)[0x55d3c529d1e9] >> btrfs(+0x14284)[0x55d3c529d284] >> btrfs(+0x169ad)[0x55d3c529f9ad] >> btrfs(btrfs_search_slot+0xf24)[0x55d3c52a0f9f] >> btrfs(btrfs_csum_file_block+0x25f)[0x55d3c52ae888] >> btrfs(+0x4aa30)[0x55d3c52d3a30] >> btrfs(cmd_check+0x10b1)[0x55d3c52dfc9e] >> btrfs(main+0x1f3)[0x55d3c529ce63] >> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f2eb872309b] >> btrfs(_start+0x2a)[0x55d3c529ceaa] >> Aborted >> >> Did this actually generate checksums for some files and then stop, or >> was nothing written at all? How can I verify checksums are calculated >> and enabled, or otherwise make sure its working as intended? >> >
Attachment:
signature.asc
Description: OpenPGP digital signature
