[Bug 209005] New: xfs_repair 5.7.0: missing newline in message: entry at block N offset NN in directory inode NNNNNN has illegal name "/foo":

[Bug 209005] New: xfs_repair 5.7.0: missing newline in message: entry at block N offset NN in directory inode NNNNNN has illegal name "/foo":

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=209005

            Bug ID: 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
           Version: 2.5
    Kernel Version: #1 SMP Debian 3.16.59-1 (2018-10-03)
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: low
          Priority: P1
         Component: XFS
          Assignee: filesystem_xfs@kernel-bugs.kernel.org
          Reporter: cs@cskk.id.au
        Regression: No

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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[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":

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=209005

Eric Sandeen (sandeen@redhat.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sandeen@redhat.com

--- Comment #1 from Eric Sandeen (sandeen@redhat.com) ---
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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[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":

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=209005

Eric Sandeen (sandeen@redhat.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO

--- Comment #2 from Eric Sandeen (sandeen@redhat.com) ---
(or, an xfs_metadump image here or offline directly to me might be of use as
well)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[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":

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=209005

--- Comment #3 from Eric Sandeen (sandeen@redhat.com) ---
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[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":

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=209005

--- Comment #4 from Eric Sandeen (sandeen@redhat.com) ---
Actually, backing up, which version of xfsprogs are you using.

I'll wait for these answers before proceeding.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[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":

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=209005

--- Comment #5 from Eric Sandeen (sandeen@redhat.com) ---
Actually nvm on the metadump; I think I can reproduce this with a hand-edited
filesystem.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[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":

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=209005

--- Comment #6 from Cameron Simpson (cs@cskk.id.au) ---
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).

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[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":

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=209005

--- Comment #7 from Eric Sandeen (sandeen@redhat.com) ---
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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[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":

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=209005

--- Comment #8 from Cameron Simpson (cs@cskk.id.au) ---
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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.