Bug 209005 - xfs_repair 5.7.0: missing newline in message: entry at block N offset NN in directory inode NNNNNN has illegal name "/foo":
Summary: xfs_repair 5.7.0: missing newline in message: entry at block N offset NN in d...
Status: NEEDINFO
Alias: None
Product: File System
Classification: Unclassified
Component: XFS (show other bugs)
Hardware: All Linux
: P1 low
Assignee: FileSystem/XFS Default Virtual Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-23 10:07 UTC by Cameron Simpson
Modified: 2020-08-24 22:48 UTC (History)
1 user (show)

See Also:
Kernel Version: #1 SMP Debian 3.16.59-1 (2018-10-03)
Subsystem:
Regression: No
Bisected commit-id:


Attachments

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

Note You need to log in before you can comment on or make changes to this bug.