Subject: ext2fs filesystem code bug in sorta-old recent current
To: NetBSD Current Users <>
From: Barry Bouwsma <>
List: current-users
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

barry bouwsma