From: Ma Xinjian <maxj.fnst@fujitsu.com>
To: fstests@vger.kernel.org
Cc: Ma Xinjian <maxj.fnst@fujitsu.com>
Subject: [Issue] xfs: g/754, xfs_repair reports mismatch between format and size in symlink ino
Date: Fri, 26 Jul 2024 11:33:42 +0800 [thread overview]
Message-ID: <20240726033342.1140741-1-maxj.fnst@fujitsu.com> (raw)
Hi
Using upstream kernel, the symlink does not get corrupted in the test of generic/754 on xfs.
But the check of xfs_repair still fails with "mismatch between format (2) and size (297) in symlink ino 139".
Does xfs_repair need to make corresponding modifications to the upstream kernel fix commit?
Could anyone help take a look?
Package Version:
kernel: 6.10.0
xfs_repair: 6.9.0
Results:
```
# ./check generic/754
FSTYP -- xfs (non-debug)
PLATFORM -- Linux/x86_64 localhost 6.10.0 #2 SMP PREEMPT_DYNAMIC Wed Jul 24 05:36:54 EDT 2024
MKFS_OPTIONS -- -f /dev/loop1
MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0 /dev/loop1 /mnt/xfstests/scratch
generic/754 _check_xfs_filesystem: filesystem on /dev/loop1 is inconsistent (r)
(see /root/xfstests-dev/results//generic/754.full for details)
HINT: You _MAY_ be missing kernel fix:
XXXXXXXXXXXXX xfs: allow symlinks with short remote targets
Ran: generic/754
Failures: generic/754
Failed 1 of 1 tests
```
Output of "xfs_repair -n":
```
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan (but don't clear) agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
mismatch between format (2) and size (297) in symlink ino 139
bad data fork in symlink 139
would have cleared inode 139
mismatch between format (2) and size (330) in symlink ino 140
bad data fork in symlink 140
would have cleared inode 140
- agno = 1
- agno = 2
- agno = 3
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
unknown block state, ag 0, blocks 14-15
- check for inodes claiming duplicate blocks...
- agno = 1
- agno = 0
entry "symlink.288" at block 0 offset 288 in directory inode 128 references free inode 139
would clear inode number in entry at offset 288...
- agno = 2
- agno = 3
entry "symlink.320" at block 0 offset 312 in directory inode 128 references free inode 140
would clear inode number in entry at offset 312...
mismatch between format (2) and size (297) in symlink ino 139
bad data fork in symlink 139
would have cleared inode 139
mismatch between format (2) and size (330) in symlink ino 140
bad data fork in symlink 140
would have cleared inode 140
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
- traversing filesystem ...
entry "symlink.288" in directory inode 128 points to free inode 139, would junk entry
entry "symlink.320" in directory inode 128 points to free inode 140, would junk entry
bad hash table for directory inode 128 (no data entry): would rebuild
would rebuild directory inode 128
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.
```
next reply other threads:[~2024-07-26 3:33 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-26 3:33 Ma Xinjian [this message]
2024-07-26 15:27 ` [Issue] xfs: g/754, xfs_repair reports mismatch between format and size in symlink ino Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240726033342.1140741-1-maxj.fnst@fujitsu.com \
--to=maxj.fnst@fujitsu.com \
--cc=fstests@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox