IIRC, this is expected behavior.

"   At last, fsck_ext2fs should be improved because, after a crash, it detects
   (and attempts to correct!) far more errors than its Linux counterpart. It
   can end up destroying some data that ought to be correct in the first
   place because it thinks is incorrect."

See http://www.netbsd.org/contrib/projects.html

--Blair

On 11/17/06, Barry Bouwsma <NOSPAM@net.bsd.linux.dk> wrote:
> [like the other two messages, I won't be able to reply for a long time]
>
>
> Moin,
>
> I accidentally ran NetBSD-current's fsck_ext2fs (from source a few
> months ago now) on an unclean Linux ext2fs filesystem.  The result
> was not pretty, and I couldn't fix it quickly with the native Linux
> e2fsck, so I simply newfs-ed the whole thing.
>
> (I believe the filesystem had been mounted rw under Linux, when a
> power outage occurred, and I rebooted into NetBSD-current, which
> ran the fsck_ext2fs at boot on the unclean filesystem, so the hacks
> I mentioned in earlier messages are probably irrelevant here.)
>
> I haven't looked at all at the code to see what might be at fault.
> As I note, the range of inode numbers used in ext2fs differs by one
> from that in most other ufs filesystems -- perhaps this is the
> problem, where the wrong inodes numbers are referred to in the fsck
> code.  Or it could be something else.
>
> If someone wants to look at this, please do so -- you'll likely
> be able to fix it before I go online, even if I find the problem
> tomorrow.
>
> This can probably be reproduced by force-fsck_ext2fs'ing a Linux
> filesystem with something on it under NetBSD-current, and then
> running the native Linux e2fsck to see what it thinks, but I have
> tried nothing since having the problem.
>
>
> thanks
> barry bouwsma
>
>


-- 
Support WFMU-FM: free-form radio for the masses!

<http://www.wfmu.org/>
91.1 FM Jersey City, NJ
90.1 FM Mt. Hope, NY

"The Reggae Schoolroom":
<http://www.wfmu.org/playlists/RS/>