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@xxxxxxxxxx> > >> > >> 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 >
