Bug 209005

Summary: xfs_repair 5.7.0: missing newline in message: entry at block N offset NN in directory inode NNNNNN has illegal name "/foo":
Product: File System Reporter: Cameron Simpson (cs)
Component: XFSAssignee: FileSystem/XFS Default Virtual Assignee (filesystem_xfs)
Status: NEEDINFO ---    
Severity: low CC: sandeen
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: #1 SMP Debian 3.16.59-1 (2018-10-03) Subsystem:
Regression: No Bisected commit-id:

Description Cameron Simpson 2020-08-23 10:07:00 UTC
Here's an example:

entry at block 0 offset 1728 in directory inode 21997239545 has illegal name "/gnome-dev-harddisk-1394.png": entry at block 0 offset 1768 in directory inode 21997239545 has illegal name "/gnome-dev-harddisk-usb.png": entry at block 0 offset 1808 in directory inode 21997239545 has illegal name "/gnome-dev-harddisk.png":

I presume there's a missing newline or some missing trailing message component.
Comment 1 Eric Sandeen 2020-08-24 17:48:27 UTC
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
Comment 2 Eric Sandeen 2020-08-24 17:49:53 UTC
(or, an xfs_metadump image here or offline directly to me might be of use as well)
Comment 3 Eric Sandeen 2020-08-24 21:03:40 UTC
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.
Comment 4 Eric Sandeen 2020-08-24 21:29:44 UTC
Actually, backing up, which version of xfsprogs are you using.

I'll wait for these answers before proceeding.
Comment 5 Eric Sandeen 2020-08-24 21:49:46 UTC
Actually nvm on the metadump; I think I can reproduce this with a hand-edited filesystem.
Comment 6 Cameron Simpson 2020-08-24 22:27:19 UTC
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).
Comment 7 Eric Sandeen 2020-08-24 22:35:16 UTC
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
Comment 8 Cameron Simpson 2020-08-24 22:48:03 UTC
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