Re: [PATCH 4/4] xfs_db: add command to copy directory trees out of filesystems

["Darrick J. Wong" <djwong@kernel.org>]

On Wed, Feb 19, 2025 at 12:04:36PM -0600, Eric Sandeen wrote:
> On 2/18/25 12:36 AM, Christoph Hellwig wrote:
> > On Thu, Feb 06, 2025 at 03:03:32PM -0800, Darrick J. Wong wrote:
> >> From: Darrick J. Wong <djwong@kernel.org>
> >>
> >> Aheada of deprecating V4 support in the kernel, let's give people a way
> >> to extract their files from a filesystem without needing to mount.
> > 
> > So I've wanted a userspace file access for a while, but if we deprecate
> > the v4 support in the kernel that will propagte to libxfs quickly,
> > and this code won't help you with v4 file systems either.  So I don't
> > think the rationale here seems very good.
> 
> I agree. And, I had considered "migrate your V4 fs via an older kernel" to
> be a perfectly acceptable answer for the v4 deprecation scenario.

I thought about that some more after you and I chatted, and decided to
go for a userspace rdump because (a) other people asked for it, and (b)
the "use an older kernel" path has its own problems.

Let's say it's 2037 and someone finds an old XFSv4 filesystem and decide
to migrate it.  That means they'll have to boot a kernel from 2030,
format a new (2030-era) V5 filesystem on a secondary device, and copy
everything to it.  If that old kernel doesn't boot for whatever reason
(outdated drivers, mismatched mitigations on the VM host, etc) they're
stuck debugging hardware support.  If they're lucky enough that the 2030
kernel actually boots with a 2037-era userspace, then they've got a
fresh filesystem and they're done.

If instead it turns out that 2037-era userspace (coughsystemdcough)
doesn't work on an old 2030 kernel, then they'll have to go install a
2030-era userspace, boot the 2030 kernel, and migrate the data.  Now
they have a V5 filesystem with 2030 era features.  If they want 2037 era
features, they have to move the device to the new system and migrate a
second time.

Contrast this to the userspace approach -- they'll have to go find a
xfs_db binary + libraries from 2030.  If that doesn't work they can try
to build the 2030 source code.  Then they can create a new filesystem on
their 2037 era machine, mount it, and tell the old xfs_db binary to
rdump everything to the new filesystem.  Now they have an XFS with
2037-era features, and they're done.

Frankly I'm more confident in our future ability to help people
run/build userspace source code from years ago than the kernel, because
there's so much more that can go wrong with the kernel.  We guarantee
that new kernels won't break old binaries; we don't guarantee that new
hardware won't break old kernels.

--D

> Christoph, can you say more about why you're eager for the functionality?
> 
> Thanks,
> -Eric
>