Bug 209005

Can you attach the whole xfs_repair log?

In most of these cases, we set "junkit=1" and later, if that's set,
we complete the string with something like:

                /*
                 * Clear junked entries.
                 */
                if (junkit) {
                        if (!no_modify) {
                                dep->name[0] = '/';
                                *dirty = 1;
                                do_warn(_("clearing entry\n"));
                        } else {
                                do_warn(_("would clear entry\n"));
                        }
                }

but the logic is pretty tangled up in this function. It might help to see the full xfs_repair output if you can provide it.

Thanks,
-Eric

(or, an xfs_metadump image here or offline directly to me might be of use as well)

IOWs this looks like more than just a missing "\n" - setting the first character of a directory entry to "/" is an internal flag for certain entries which is normally handled in a specific way.

But it doesn't look like your filenames are overwritten; it looks like they actually started with "/" prior to repair?  So it may not be handling this flagging properly when the leading "/" came from elsewhere... a metadump would be helpful.

Actually, backing up, which version of xfsprogs are you using.

I'll wait for these answers before proceeding.

Actually nvm on the metadump; I think I can reproduce this with a hand-edited filesystem.

Sorry for the delay, been asleep.

Alas, the filesystem has been repaired and I didn't keep a log, or alas, a transcript.

The xfs_repair is from xfsprogs 5.7.0.

By contrast, the filesystem is made by quite an old kernel:

Linux octopus 3.16.0-7-amd64 #1 SMP Debian 3.16.59-1 (2018-10-03) x86_64 GNU/Linux

and I have seen this filenames-with-a-leading-slash in a previous repair of an XFS filesystem from this machine.

This bug report is really about the messaging, not the bogus filenames; I accept that the kernel is old and the XFS implementation therefore many bugfixes behind.

For added fun the FS is on an iscsi device from a QNAP NAS (because QNAPs don't do XFS); I started the repair after getting link errors on the FS, after a building wide power out took out the machine and the NAS; and we had to reseat a drive in the raidset. It's just backups, but it has 5TB of highly linked files in it.

Just FYI, BTW, a second run of xfs_repair after the big repair corrected a few hardlink counts (but a mere handful, maybe 4, after the previous repair did thousands of fixes).

Thanks for the info, and sorry for missing the 5.7.0 in the title.  And no reason to apologize for sleeping in .au during my day in the US ;)

I think I can recreate the problem now, and the code is just kind of messy in there, I'll see what I can do to make it a bit saner (with sane messages too).

Thanks,
-Eric

No worries. Let me know if I can add info; I've got to down the FS at somepoint today or tomorrow to reboot the NAS, which is being sullen. A prime opportunity to rerun an xfs_repair, which I will do anyway, since I've just thrown another 2TB into it.

Any special options for the xfs_repair run to produce a log or transcript, or any pre-repair dump instructions I could do (eg the metadump you mentioned)?

I'd like to do these things anyway this time around.

Cheers,
Cameron