Btrfs progs release 6.19

Btrfs progs release 6.19

[David Sterba]

Hi,

btrfs-progs version 6.19 have been released (ther version 6.18 has been skipped).

There's change in mkfs.btrfs defaults, the block group tree is now enabled. A
note is printed (which was a last minute change and the release was redone, the
top commit is 9ac9a97ee3ebcc71).

Changelog:

* mkfs:
  * make block-group-tree default (support since linux 6.1), use -O ^bgt to
    unset it for backward compatibility
  * speed up initial device discard by procesing the ranges in order
  * disable block-grooup-tree feature if a dependent feature is explicitly
    unselected (like disabling no-holes), instead of erroring out
* check:
  * add ability to detect and fix missing orphan items in deleted subvolumes
  * add ability to fix inode refs from directory items
  * enhance detection on unknown inode keys
* libbtrfsutil:
  * minor version update to 1.4.0
  * add missing aliases for API updates done in 0.1.3, C and python
* libbtrfs:
  * patchlevel version update 0.1.5
  * error handling updates
* fixes:
  * with DUP profile and mixed sequential and conventional zoned make sure
    to track the right write pointers
  * scrub: fix ETA wraparound calculations, when many files get deleted
    during the operation bytes_scrubbed and bytes_total get too much out of
    sync, the ETA will be 0
* corrupt-block: add ability to specify key value when corrupting item keys
* experimental features:
  * initial remap tree support (new logical-to-logical mapping layer),
    coming in linux 7.0
* other:
  * documentation updates
  * CI updates, new and updated tests
  * code cleanups and refactoring

Tarballs: https://www.kernel.org/pub/linux/kernel/people/kdave/btrfs-progs/
Git: git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git
Release: https://github.com/kdave/btrfs-progs/releases/tag/v6.19
Python: https://pypi.org/project/btrfsutil/

Re: Btrfs progs release 6.19

[Christoph Anton Mitterer]

On Fri, 2026-02-13 at 19:56 +0100, David Sterba wrote:
>   * make block-group-tree default (support since linux 6.1), use -O
> ^bgt to
>     unset it for backward compatibility

I guess that also mean that this is now considered stable and has been
very well tested?

How about migrating an existing fs to use the block-group-tree (with
btrfstune --convert-to-block-group-tree)... has that also been well
tested and is considered safe to be used on filesystems with precious
data?


Thanks,
Chris.

Re: Btrfs progs release 6.19

[David Sterba]

On Sat, Feb 14, 2026 at 03:18:51AM +0100, Christoph Anton Mitterer wrote:
> On Fri, 2026-02-13 at 19:56 +0100, David Sterba wrote:
> >   * make block-group-tree default (support since linux 6.1), use -O
> > ^bgt to
> >     unset it for backward compatibility
> 
> I guess that also mean that this is now considered stable and has been
> very well tested?

Yes, the bgt feature has been part of the fstests runs.

> How about migrating an existing fs to use the block-group-tree (with
> btrfstune --convert-to-block-group-tree)... has that also been well
> tested and is considered safe to be used on filesystems with precious
> data?

The in-place conversions are a bit more tricky as they start from an
existing filesystem and there's a possibility of finding some corner
case. Last time this was in 6.15.

It should be doable to test the conversion using device mapper snapshot
devices on an existing valuable filesystem without destroying it.

Re: Btrfs progs release 6.19

[Christoph Anton Mitterer]

On Tue, 2026-03-17 at 17:34 +0100, David Sterba wrote:
> > How about migrating an existing fs to use the block-group-tree
> > (with
> > btrfstune --convert-to-block-group-tree)... has that also been well
> > tested and is considered safe to be used on filesystems with
> > precious
> > data?
> 
> The in-place conversions are a bit more tricky as they start from an
> existing filesystem and there's a possibility of finding some corner
> case. Last time this was in 6.15.

I see. Thanks for the information.


> It should be doable to test the conversion using device mapper
> snapshot
> devices on an existing valuable filesystem without destroying it.

But that would only tell me if the bug actually happens (and is
noticed) during conversion... not if something is simply stored in a
wrong way which I may not notice until much later (when it might
already be too late).

Thanks anyway :-)
Chris.

Re: Btrfs progs release 6.19

[joshua]

For what it’s worth, (not much) I used --convert-to-block-group-tree on a large fs with precious data (~10 drives, ~100Tb, Raid1 data, Raid1C3 metadata) and had no issues.

Convert took a LONG time, but afterwards, all my data integrity checks passed, scrub passed, and mount times are approximately 1 second now, compared to minutes previously.

—Joshua Villwock

> On Mar 24, 2026, at 6:00 PM, Christoph Anton Mitterer <calestyo@scientia.org> wrote:
> 
> On Tue, 2026-03-17 at 17:34 +0100, David Sterba wrote:
>>> How about migrating an existing fs to use the block-group-tree
>>> (with
>>> btrfstune --convert-to-block-group-tree)... has that also been well
>>> tested and is considered safe to be used on filesystems with
>>> precious
>>> data?
>> 
>> The in-place conversions are a bit more tricky as they start from an
>> existing filesystem and there's a possibility of finding some corner
>> case. Last time this was in 6.15.
> 
> I see. Thanks for the information.
> 
> 
>> It should be doable to test the conversion using device mapper
>> snapshot
>> devices on an existing valuable filesystem without destroying it.
> 
> But that would only tell me if the bug actually happens (and is
> noticed) during conversion... not if something is simply stored in a
> wrong way which I may not notice until much later (when it might
> already be too late).
> 
> Thanks anyway :-)
> Chris.
> 

Re: Btrfs progs release 6.19

[Christoph Anton Mitterer]

On Tue, 2026-03-24 at 21:18 -0700, joshua wrote:
> For what it’s worth, (not much) I used --convert-to-block-group-tree
> on a large fs with precious data (~10 drives, ~100Tb, Raid1 data,
> Raid1C3 metadata) and had no issues.
> 
> Convert took a LONG time, but afterwards, all my data integrity
> checks passed, scrub passed, and mount times are approximately 1
> second now, compared to minutes previously.

Thanks for the information. How long have you been running with it?

Cheers,
Chris.

Re: Btrfs progs release 6.19

[joshua]

On Wednesday, March 25, 2026 09:21 PDT, Christoph Anton Mitterer <calestyo@scientia.org> wrote:
> On Tue, 2026-03-24 at 21:18 -0700, joshua wrote:
> > For what it’s worth, (not much) I used --convert-to-block-group-tree
> > on a large fs with precious data (~10 drives, ~100Tb, Raid1 data,
> > Raid1C3 metadata) and had no issues.
> > 
> > Convert took a LONG time, but afterwards, all my data integrity
> > checks passed, scrub passed, and mount times are approximately 1
> > second now, compared to minutes previously.
> 
> Thanks for the information. How long have you been running with it?

Don't know exactly, but it was shortly after the new Debian stable release.
So probably around mid-to-late August.

I'd say a good 4-8 months at least since then, with no issues so far.

-- 
--Joshua Villwock