[Bug 206530] ext2fs: fsck.ext3 reports "Inode 157938 has INDEX_FL flag set but is not a directory"
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Sat Jan 23 16:03:23 UTC 2016
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206530
Bug ID: 206530
Summary: ext2fs: fsck.ext3 reports "Inode 157938 has INDEX_FL
flag set but is not a directory"
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Keywords: patch
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: damjan.jov at gmail.com
CC: freebsd-fs at FreeBSD.org
Created attachment 166011
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=166011&action=edit
Initialize the inode's i_flag to 0 during allocation
fsck.ext3 on a cleanly unmounted EXT3 filesystem that went through heavy file
creation (OpenOffice build, about 80000 new files) gives a dozen or so of these
errors during "Pass 1: Checking inodes, blocks, and sizes":
Inode 157938 has INDEX_FL flag set but is not a directory.
Clear HTree index?
This error is benign to our ext2fs driver, as it requires the inode's mode to
be directory for this flag to have any effect. However it's not benign to other
EXT3 implementations - it breaks at least fsck.ext3 itself if the "-n" option
to it is used or "no" is answered to that question, since it misinterprets the
inode as a directory, giving further false errors because that pseudo-directory
will appear corrupt.
Adding this hack:
if (!S_ISDIR(ip->i_mode) && (ip->i_flag & IN_E4INDEX) != 0)
panic("non-directory has index!?\n");
to ext2_i2ei() to catch wrong use of this flag just before the inode is written
to disk, produces this revealing stack trace:
KDB: stack backtrace:
db_trace_self_wrapper()
vpanic()
panic()
ext2_i2ei()
ext2_update()
ext2_makeinode()
ext2_create()
VOP_CREATE_APV()
vn_open_cred()
kern_openat()
amd64_syscall()
Xfast_syscall()
Reading through those functions shows ext2_makeinode() calls ext2_valloc()
which apparently reuses inodes from disk without initializing their i_flag
field, hence if a previously deleted directory's inode is reused for a file,
the IN_E4INDEX flag from it will still be set, and wrongly written to the
file's inode!
I am attaching a patch that initializes i_flag to 0. With it, fsck.ext3 reports
a clean scan after the same test.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the freebsd-fs
mailing list