Re: Btrfs progs pre-release 5.15-rc1

From: David Sterba <dsterba@suse.cz>
To: Forza <forza@tnonline.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Btrfs progs pre-release 5.15-rc1
Date: Tue, 2 Nov 2021 17:30:27 +0100	[thread overview]
Message-ID: <20211102163027.GN20319@twin.jikos.cz> (raw)
In-Reply-To: <38e1b33.df69821a.17cd0454b6b@tnonline.net>

On Sat, Oct 30, 2021 at 10:16:14AM +0200, Forza wrote:
> 
> 
> ---- From: David Sterba <dsterba@suse.com> -- Sent: 2021-10-29 - 17:53 ----
> 
> > Hi,
> > 
> > this is a pre-release of btrfs-progs, 5.15-rc1 (version tag is v5.14.91).
> > 
> > The proper release is scheduled to next Friday, +7 days (2021-10-05).
> > 
> > The noticeable changes are in the mkfs defaults:
> > 
> >   * no-holes
> >   * free-space-tree
> >   * DUP for metadata unconditionally
> > 
> > This is based on numerous user requests and discussions, and after long period
> > where the respective features have been in released kernels.
> > 
> > Other changes:
> > 
> > * libbtrfs - minimize its impact on the other code, refactor and separate
> >   implementation where needed, cleanup afterwards, reduced header exports
> > 
> > * documentation - introduce sphinx build and RST versions of manual pages, will
> >   become the new format and replace asciidoc
> >   (Preview at https://deleteme12545.readthedocs.io/en/latest/index.html)
> > 
> > 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
> > 
> 
> Thank you for the release. It compiles and runs fine on my Gentoo 5.14.14 amd64 system. 
> 
> Here is the output and the corresponding dmesg bits. One note is the mention of "cleaning free space cache v1“ during mount. Is this intended? 

I'm not sure why it's there but it should not I think. At least it does
not make sense when the v2 is enabled right away.

> # mkfs.btrfs /dev/loop0p1 -fv --csum xxhash btrfs-progs v5.14.91
> See http://btrfs.wiki.kernel.org for more information.
> Performing full device TRIM /dev/loop0p1 (100.00GiB) ...
> NOTE: several default settings have changed in version 5.15, please make sure this does not affect your deployments: - DUP for metadata (-m dup) - enabled no-holes (-O no-holes) - enabled free-space-tree (-R free-space-tree)
> Label: (null) UUID: ee548f53-5639-4d90-8c23-810b4b1f0a69
> Node size: 16384
> Sector size: 4096
> Filesystem size: 100.00GiB
> Block group profiles: Data: single 8.00MiB Metadata: dup 1.00GiB System: dup 8.00MiB
> SSD detected: yes
> Zoned device: no
> Incompat features: extref, skinny-metadata, no-holes
> Runtime features: free-space-tree
> Checksum: xxhash64 Number of devices: 1
> Devices: ID SIZE PATH 1 100.00GiB /dev/loop0p1

> # dmesg ...
> [224380.260049] BTRFS: device fsid ee548f53-5639-4d90-8c23-810b4b1f0a69 devid 1 transid 6 /dev/loop0p1 scanned by mkfs.btrfs (6730)
> [224534.460239] BTRFS info (device loop0p1): flagging fs with big metadata feature
> [224534.460246] BTRFS info (device loop0p1): using free space tree
> [224534.460249] BTRFS info (device loop0p1): has skinny extents
> [224534.462430] BTRFS info (device loop0p1): enabling ssd optimizations
> [224534.462540] BTRFS info (device loop0p1): cleaning free space cache v1
> [224534.591074] BTRFS info (device loop0p1): checking UUID tree

The timestamp delta is about 0.13 so there could be something happening,
even if it's just checking some structures. It seems otherwise harmless
but I'd like to get this resolved before proper release. Now tracked as
https://github.com/kdave/btrfs-progs/issues/420 , thanks for the report.