Re: btrfs-convert with --no-datasum and --no-inline. How can I enable those features now?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux