Re: [ANNOUNCE] xfsdump 3.1.10 released

[L A Walsh <xfs@tlinx.org>]

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.