Btrfs progs release 4.16.1

Btrfs progs release 4.16.1

[David Sterba]

Hi,

btrfs-progs version 4.16.1 have been released.  This is a bugfix release.

Changes:

  * remove obsolete tools: btrfs-debug-tree, btrfs-zero-log, btrfs-show-super,
    btrfs-calc-size
  * sb-mod: new debugging tool to edit superblock items
  * mkfs: detect if thin-provisioned device does not have enough space
  * check: don't try to verify checksums on metadata dump images
  * build: fail documentation build if xmlto is not found
  * build: fix build of btrfs.static

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

Shortlog:

Baruch Siach (1):
      btrfs-progs: build btrfs.static needs libbtrfsutil to build

David Sterba (5):
      btrfs-progs: sb-mod: add preliminary support for non-u64 types
      btrfs-progs: sb-mod: add csum_type
      btrfs-progs: sb-mod: add compat bit to the recognized fields
      btrfs-progs: reorder extent buffer members for better packing
      btrfs-progs: update CHANGES for v4.16.1

Gu Jinxiang (4):
      btrfs-progs: send-utils: remove unused functions path_cat and path_cat3
      btrfs-progs: Let function find_device to be consistent with kernel
      btrfs-progs: Remove duplicate value-get for data_extents_scrubbed
      btrfs-progs: Do not add extra slash if given path end with it

Misono Tomohiro (1):
      btrfs-progs: configure: check if xmlto exists at configure time

Nikolay Borisov (4):
      btrfs-progs: Remove btrfs-debug-tree command
      btrfs-progs: Remove deprecated btrfs-zero-log standalone tool
      btrfs-progs: Remove deprecated btrfs-show-super
      btrfs-progs: Remove deprecated btrfs-calc-size tool

Qu Wenruo (9):
      btrfs-progs: check: Skip data csum verification for metadata dump
      btrfs-progs: tests/fsck: Add test case to check if btrfs check can skip data csum verfication for metadata dump
      btrfs-progs: extent_io: Fix NULL pointer dereference in free_extent_buffer_final()
      btrfs-progs: extent_io: Init eb->lru to avoid NULL pointer dereference
      btrfs-progs: extent_io: Refactor alloc_extent_buffer() to follow kernel parameters
      btrfs-progs: Unify btrfs_leaf_free_space() parameter with kernel
      btrfs-progs: print-tree: Remove btrfs_root parameter
      btrfs-progs: Rename OPEN_CTREE_FS_PARTIAL to OPEN_CTREE_TEMPORARY_SUPER
      btrfs-progs: Use more loose open ctree flags for dump-tree and restore

Su Yue (1):
      btrfs-progs: mkfs: return nozero value on thin provisioned device

Re: Btrfs progs release 4.16.1

[Duncan]

David Sterba posted on Tue, 24 Apr 2018 13:58:57 +0200 as excerpted:

> btrfs-progs version 4.16.1 have been released.  This is a bugfix
> release.
> 
> Changes:
> 
>   * remove obsolete tools: btrfs-debug-tree, btrfs-zero-log,
>   btrfs-show-super, btrfs-calc-size

Cue the admin-side gripes about developer definitions of micro-upgrade 
explicit "bugfix release" that allow disappearance of "obsolete tools".

Arguably such removals can be expected in a "feature release", but 
shouldn't surprise unsuspecting admins doing a micro-version upgrade 
that's specifically billed as a "bugfix release".

(Further support for btrfs being "still stabilizing, not yet fully stable 
and mature."  But development mode habits need to end /sometime/, if 
stability is indeed a goal.) 

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: Btrfs progs release 4.16.1

[David Sterba]

On Wed, Apr 25, 2018 at 06:31:20AM +0000, Duncan wrote:
> David Sterba posted on Tue, 24 Apr 2018 13:58:57 +0200 as excerpted:
> 
> > btrfs-progs version 4.16.1 have been released.  This is a bugfix
> > release.
> > 
> > Changes:
> > 
> >   * remove obsolete tools: btrfs-debug-tree, btrfs-zero-log,
> >   btrfs-show-super, btrfs-calc-size
> 
> Cue the admin-side gripes about developer definitions of micro-upgrade 
> explicit "bugfix release" that allow disappearance of "obsolete tools".
> 
> Arguably such removals can be expected in a "feature release", but 
> shouldn't surprise unsuspecting admins doing a micro-version upgrade 
> that's specifically billed as a "bugfix release".

A major version release would be a better time for the removal, I agree
and should have considered that.

However, the tools have been obsoleted for a long time (since 2015 or
2016) so I wonder if the deprecation warnings have been ignored by the
admins all the time.

> (Further support for btrfs being "still stabilizing, not yet fully stable 
> and mature."  But development mode habits need to end /sometime/, if 
> stability is indeed a goal.) 

What happened here was a bad release management decision, a minor one in
my oppinion but I hear your complaint and will keep that in mind for
future releases.

Do you really want to use that to perpetuate the 'still stabilizing and
not mature' claim? If you expect 0 bugs and essentially no other visible
problems, than I don't think you should use linux. Or wait until it's
fully stable, whatever that means.

In terms of features, btrfs is not done and will be actively developed
and maintained. Bugs will be found, reported and fixed, new features
will add more code that will have to be stabilized over time. This is
how the entire linux kernel evolves.

The focus in recent releases has been on cleanups and refactoring,
besides bugfixes. No big feature has been merged, to some disappointment
of developers and users, but this is namely to minimize the fallout of
new code that does not have enough review and testing.  My target is to
do slow and steady incremental changes with no regressions.

Re: Btrfs progs release 4.16.1

[Austin S. Hemmelgarn]

On 2018-04-25 07:02, David Sterba wrote:
> On Wed, Apr 25, 2018 at 06:31:20AM +0000, Duncan wrote:
>> David Sterba posted on Tue, 24 Apr 2018 13:58:57 +0200 as excerpted:
>>
>>> btrfs-progs version 4.16.1 have been released.  This is a bugfix
>>> release.
>>>
>>> Changes:
>>>
>>>    * remove obsolete tools: btrfs-debug-tree, btrfs-zero-log,
>>>    btrfs-show-super, btrfs-calc-size
>>
>> Cue the admin-side gripes about developer definitions of micro-upgrade
>> explicit "bugfix release" that allow disappearance of "obsolete tools".
>>
>> Arguably such removals can be expected in a "feature release", but
>> shouldn't surprise unsuspecting admins doing a micro-version upgrade
>> that's specifically billed as a "bugfix release".
> 
> A major version release would be a better time for the removal, I agree
> and should have considered that.
> 
> However, the tools have been obsoleted for a long time (since 2015 or
> 2016) so I wonder if the deprecation warnings have been ignored by the
> admins all the time.
While I can understand Duncan's point here, I'm inclined to agree with 
David, with the further addendum that these are all debug tools, and 
therefore no sane sysadmin should be depending on them for production 
operation anyway.
> 
>> (Further support for btrfs being "still stabilizing, not yet fully stable
>> and mature."  But development mode habits need to end /sometime/, if
>> stability is indeed a goal.)
> 
> What happened here was a bad release management decision, a minor one in
> my oppinion but I hear your complaint and will keep that in mind for
> future releases.
> 
> Do you really want to use that to perpetuate the 'still stabilizing and
> not mature' claim? If you expect 0 bugs and essentially no other visible
> problems, than I don't think you should use linux. Or wait until it's
> fully stable, whatever that means.
I think you mean 'I don't think you should use computers', given that 
other platforms are just as bad in slightly different ways.
> 
> In terms of features, btrfs is not done and will be actively developed
> and maintained. Bugs will be found, reported and fixed, new features
> will add more code that will have to be stabilized over time. This is
> how the entire linux kernel evolves.
> 
> The focus in recent releases has been on cleanups and refactoring,
> besides bugfixes. No big feature has been merged, to some disappointment
> of developers and users, but this is namely to minimize the fallout of
> new code that does not have enough review and testing.  My target is to
> do slow and steady incremental changes with no regressions.

Re: Btrfs progs release 4.16.1

[Christoph Anton Mitterer]

On Wed, 2018-04-25 at 07:22 -0400, Austin S. Hemmelgarn wrote:
> While I can understand Duncan's point here, I'm inclined to agree
> with 
> David

Same from my side... and I run a multi-PiB storage site (though not
with btrfs).

Cosmetically one shouldn't do this in a bugfix release, this should
have really no impact on the real world.

The typical sysadmin will anyway use some stable distribution... and is
there any which ships already 4.16?

Cheers,
Chris.

Re: Btrfs progs release 4.16.1

[Austin S. Hemmelgarn]

On 2018-04-25 07:29, Christoph Anton Mitterer wrote:
> On Wed, 2018-04-25 at 07:22 -0400, Austin S. Hemmelgarn wrote:
>> While I can understand Duncan's point here, I'm inclined to agree
>> with
>> David
> 
> Same from my side... and I run a multi-PiB storage site (though not
> with btrfs).
> 
> Cosmetically one shouldn't do this in a bugfix release, this should
> have really no impact on the real world.
> 
> The typical sysadmin will anyway use some stable distribution... and is
> there any which ships already 4.16?
Arch, Gentoo, and Void all have it ATM, but whether or not you want to 
consider them stable is another question.

OpenSUSE Tumbleweed and Fedora Rawhide also have 4.16, though those are 
also of questionable stability.

Re: Btrfs progs release 4.16.1

[Duncan]

David Sterba posted on Wed, 25 Apr 2018 13:02:34 +0200 as excerpted:

> On Wed, Apr 25, 2018 at 06:31:20AM +0000, Duncan wrote:
>> David Sterba posted on Tue, 24 Apr 2018 13:58:57 +0200 as excerpted:
>> 
>> > btrfs-progs version 4.16.1 have been released.  This is a bugfix
>> > release.
>> > 
>> > Changes:
>> > 
>> >   * remove obsolete tools: btrfs-debug-tree, btrfs-zero-log,
>> >   btrfs-show-super, btrfs-calc-size
>> 
>> Cue the admin-side gripes about developer definitions of micro-upgrade
>> explicit "bugfix release" that allow disappearance of "obsolete tools".
>> 
>> Arguably such removals can be expected in a "feature release", but
>> shouldn't surprise unsuspecting admins doing a micro-version upgrade
>> that's specifically billed as a "bugfix release".
> 
> A major version release would be a better time for the removal, I agree
> and should have considered that.
> 
> However, the tools have been obsoleted for a long time (since 2015 or
> 2016) so I wonder if the deprecation warnings have been ignored by the
> admins all the time.

Indeed, in practice, anybody still using the stand-alone tools in a 
current version has been ignoring deprecation warnings for awhile, and 
the difference between 4.16.1 and 4.17(.0) isn't likely to make much of a 
difference to them.

It's just that from here anyway, if I did a big multi-version upgrade and 
saw tools go missing I'd expect it, and if I did an upgrade from 4.16 to 
4.17 I'd expect it and blame myself for not getting with the program 
sooner.  But on an upgrade from 4.16 to 4.16.1, furthermore, an explicit 
"bugfix release", I'd be annoyed with upstream when they went missing, 
because it's just not expected in such a minor release, particularly when 
it's an explicit "bugfix release".

>> (Further support for btrfs being "still stabilizing, not yet fully
>> stable and mature."  But development mode habits need to end
>> /sometime/, if stability is indeed a goal.)
> 
> What happened here was a bad release management decision, a minor one in
> my oppinion but I hear your complaint and will keep that in mind for
> future releases.

That's all I was after.  A mere trifle indeed in the filesystem context 
where there's a real chance that bugs can eat data, but equally trivially 
held off for a .0 release.  What's behind is done, but it can and should 
be used to inform the future, and I simply mentioned it here with the 
goal /of/ informing future release decisions.  To the extent that it does 
so, my post accomplished its purpose. =:^)

Seems my way of saying that ended up coming across way more negative than 
intended.  So I have some changes to make in the way I handle things in 
the future as well. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman