[ANNOUNCE] xfsdump 3.1.10 released

[ANNOUNCE] xfsdump 3.1.10 released

[Eric Sandeen]

[-- Attachment #1.1: Type: text/plain, Size: 2072 bytes --]

Hi folks,

The xfsdump repository at:

	git://git.kernel.org/pub/scm/fs/xfs/xfsdump-dev.git

has just been updated.

The new head of the master branch is commit:

3607469 (HEAD -> master, tag: v3.1.10, origin/master, origin/HEAD, korg/master) xfsdump: Release 3.1.10

I've deferred Darrick's patch to remove dmapi interfaces for now,
because I don't want to stall on getting the fix for the root inode
problems out there any longer. It's been ... quite long enough.

Next release we can think about the dmapi junk, and possibly the
workaround for the broken dumps with the root inode problem.

This should at least be generating valid dumps on those filesystems
with "interesting" geometry, again.

New Commits:

Anthony Iliopoulos (2):
      [15689d8] xfsdump: remove obsolete code for handling mountpoint inodes
      [f8c9cdc] xfsdump: remove obsolete code for handling xenix named pipes

Eric Sandeen (3):
      [5f9f0ca] xfsdump: rename worker threads
      [25b42fb] xfsdump: don't try to generate .ltdep in inventory/
      [3607469] xfsdump: Release 3.1.10

Gao Xiang (2):
      [3b71c7f] xfsdump: Revert "xfsdump: handle bind mount targets"
      [0717c1c] xfsdump: intercept bind mount targets


Code Diffstat:

 VERSION                 |  2 +-
 common/drive.h          |  2 +-
 common/drive_minrmt.c   | 16 +++++------
 common/drive_scsitape.c | 16 +++++------
 common/main.c           |  8 +++---
 common/ring.c           | 58 ++++++++++++++++++-------------------
 common/ring.h           | 32 ++++++++++-----------
 common/stream.c         |  2 +-
 common/ts_mtio.h        |  2 +-
 configure.ac            |  2 +-
 debian/changelog        |  7 +++++
 doc/CHANGES             |  5 ++++
 doc/files.obj           |  2 +-
 doc/xfsdump.html        |  6 ++--
 dump/content.c          | 89 +++++++++++++++++++++++++++++++++++++++++----------------
 dump/inomap.c           |  3 --
 inventory/Makefile      |  2 --
 restore/content.c       |  8 ------
 18 files changed, 149 insertions(+), 113 deletions(-)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [ANNOUNCE] xfsdump 3.1.10 released

[L A Walsh]

On 2022/02/11 12:59, Eric Sandeen wrote:
> Hi folks,

> because I don't want to stall on getting the fix for the root inode
> problems out there any longer. It's been ... quite long enough.
> 
> Next release we can think about the dmapi junk, and possibly the
> workaround for the broken dumps with the root inode problem.
> 
> This should at least be generating valid dumps on those filesystems
> with "interesting" geometry, again.
----

Thanks for the Cc.

  As near as I understand your comments, this should generate new dumps that won't
have the problem I'm seeing, but will still leave previous dumps in the old format
that may show problems upon restoration.

  FWIW, xfs/restore-dump aren't the only util to have problems with little-used geometries.

 The BSD-DB libs of 10-15 years ago used in in perl have problems with a RAID50 setup. AFAIK, the problem was never fixed, because the perl punted the problem to the bsdlib.  Unfortunately, no one was supporting that lib anymore. I think a new db-lib was added
(mariadb?, I forget) that replaced the older format), so newer perls may not
have that bug.

  It only appeared when the "POSIX-Optimal-I/O" size was NOT a *power*-of-2.
The lib confused *factor*-of-2 alignment with Pow-of-2 for use in db-internal
size-allocations provided resulting in some internal allocations being of size-0, which doesn't work very well.
 
  Of course perl doesn't check for this error case, since the problem isn't considered
to be a problem in the perl-code.

Re: [ANNOUNCE] xfsdump 3.1.10 released

[Eric Sandeen]

On 2/12/22 8:47 PM, L A Walsh wrote:
> 
> 
> On 2022/02/11 12:59, Eric Sandeen wrote:
>> Hi folks,
> 
>> because I don't want to stall on getting the fix for the root inode
>> problems out there any longer. It's been ... quite long enough.
>>
>> Next release we can think about the dmapi junk, and possibly the
>> workaround for the broken dumps with the root inode problem.
>>
>> This should at least be generating valid dumps on those filesystems
>> with "interesting" geometry, again.
> ----
> 
> Thanks for the Cc.
> 
>  As near as I understand your comments, this should generate new dumps that won't
> have the problem I'm seeing, but will still leave previous dumps in the old format
> that may show problems upon restoration.

Correct, I want to spend more time on the workaround to be sure we have confidence
in it, sorry.

>  FWIW, xfs/restore-dump aren't the only util to have problems with little-used geometries.
> 
> The BSD-DB libs of 10-15 years ago used in in perl have problems with a RAID50 setup. AFAIK, the problem was never fixed, because the perl punted the problem to the bsdlib.  Unfortunately, no one was supporting that lib anymore. I think a new db-lib was added
> (mariadb?, I forget) that replaced the older format), so newer perls may not
> have that bug.
> 
>  It only appeared when the "POSIX-Optimal-I/O" size was NOT a *power*-of-2.
> The lib confused *factor*-of-2 alignment with Pow-of-2 for use in db-internal
> size-allocations provided resulting in some internal allocations being of size-0, which doesn't work very well.
> 
>  Of course perl doesn't check for this error case, since the problem isn't considered
> to be a problem in the perl-code.

Funky ;)

-Eric

Re: [ANNOUNCE] xfsdump 3.1.10 released

[L A Walsh]

On 2022/02/14 06:28, Eric Sandeen wrote:
> On 2/12/22 8:47 PM, L A Walsh wrote:
>>
>> On 2022/02/11 12:59, Eric Sandeen wrote:
>>> Hi folks,
>>> because I don't want to stall on getting the fix for the root inode
>>> problems out there any longer. It's been ... quite long enough.
>>>
>>> Next release we can think about the dmapi junk, and possibly the
>>> workaround for the broken dumps with the root inode problem.
>>>
>>> This should at least be generating valid dumps on those filesystems
>>> with "interesting" geometry, again.
>> ----
>>
>> Thanks for the Cc.
>>
>>  As near as I understand your comments, this should generate new dumps that won't
>> have the problem I'm seeing, but will still leave previous dumps in the old format
>> that may show problems upon restoration.
> 
> Correct, I want to spend more time on the workaround to be sure we have confidence
> in it, sorry.
---

	No need to apologize, Fixing the problem in stages is perfectly logical
Even if some existing dumps have inconsistencies in them, cutting off the source
of them will guarantee the number of those existing dumps will 
decrease, eventually, assuming recycling of dump-space to zero.  :-)