Subject: ext2fs filesystem code bug in sorta-old recent current
To: NetBSD Current Users <email@example.com>
From: Barry Bouwsma <NOSPAM@Net.BSD.Linux.dk>
Date: 11/17/2006 10:43:28
[I probably won't be able to follow-up on this, so please drop me
from any replies -- I discovered this problem and wrote this some
time ago while not online, so it's rather stale]
There appears to have been a bug introduced into NetBSD-current's
ext2fs support with the recent change in timecounters. If I read
my CVS repository correctly, that bug has propagated into branches
other than -current as well.
The bug manifests itself as complaints from Linux e2fsck about a
corrupted orphaned inode list.
The bug seems to be a result of the change in the inode dtime from
tv.sec to be time_uptime instead, which is quite different from the
Unix time normally found in the dtime field.
All instances of this can be found readily by grepping for `uptime'
within the src/sys/ufs/ext2fs directory, cuz I don't have the source
at hand to make a real patch. I'm guessing time_sec was meant in
place of time_uptime.
I don't know if any other files were affected by this error in other
parts of the kernel...
(I think I've patched and rebuilt the kernel dated from the time I
discovered this problem to see if this solved the fsck problem,
which occurs when a file has been deleted, giving it a dtime -- soon
after a reboot -- less than the number of inodes in a large filesystem,
which causes e2fsck to suspect a linked list of orphan inodes (from ext3?)
in Linux. I think that this problem was solved by that, but don't
quote me on it)
To reproduce this, with access to a native Linux system, mount an
ext2fs filesystem rw and delete some files, on a recently-rebooted
NetBSD-current system. Then force-run Linux e2fsck (NOT NetBSD's
version, that has problems I'll report later) from Linux and see what
it says about the inodes deleted by NetBSD-current.
Apologies if this problem has already been noted and fixed.
There are a couple other ext2fs-related problems I've observed that
I'll report separately. Sorry for not sending a pr, but being almost
never online, I wouldn't be able to offer the needed feedback and stuff