linux-ext4 - Re: e2fsprogs/ext4 version compatibility

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTi=cgVAbEd+vmXeRRHD7wWdbt_Dyf=vYRLFH-45r@mail.gmail.com>
Date:	Thu, 24 Feb 2011 11:22:34 +0200
From:	Amir Goldstein <amir73il@...il.com>
To:	Hari Subramanian <hari@...are.com>
Cc:	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: e2fsprogs/ext4 version compatibility

On Wed, Feb 23, 2011 at 11:09 PM, Hari Subramanian <hari@...are.com> wrote:
> Hi,
>
> I'm running a SLES11 SP1 GA based kernel (2.6.32.23) with ext4 filesystem. The e2fsprogs package that's installed on the box is version 1.41.9 (22-Aug-2009). I was wondering if there was a version in compatibility between the filesystem implementation and the tools package, esp. since there have been 5 revisions of the package since 1.41.9
>

I am using the same kernel/e2fsprogs versions and they don't seem to
have any comparability issues
(none of the kernel/e2fsprogs versions should have comparability issues AFAIK)

> The reason I'm asking the question is my machine recently rebooted after a crash but fsck failed with an error code of 4 and the following message:
>
> "Inodes that were part of a corrupted orphan linked list found"
> "UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY"

This doesn't look like a kernel/e2fsprogs compatibility issue.
Fsck is telling you it found an inode, which looks like it should have
been on the orphan list,
but wasn't found on the list.

It could also be that you deleted an inode back in the 80's,
but I think the code is trying to rule that option out somehow
with the busted_fs_time:

                if (inode->i_dtime && !busted_fs_time &&
                    inode->i_dtime < ctx->fs->super->s_inodes_count) {
                        if (fix_problem(ctx, PR_1_LOW_DTIME, &pctx)) {
                                inode->i_dtime = inode->i_links_count ?
                                        0 : ctx->now;
                                e2fsck_write_inode(ctx, ino, inode,
                                                   "pass1");
                        }
                }

In any case, saying yes to fix that problem seems to be mostly harmless.
later passes of fsck would figure out what to do with that inode, which
is why fsck requires you to run it manually, so you can answer important
questions like: delete inode XXX?

>
> There were no files being created or deleted at the time of the crash although IOs were probably inflight. So, the inodes being a part of orphaned link list doesn't make sense to me. I don't claim deep knowledge in filesystem internals either. Before I go suspecting a corrupted filesystem, I wanted to make sure I was running the right version of fsck.

An inode is added to orphan list before every write that is about to
change the file size, so it does make sense to
have inodes on the orphan list after crash, but it doesn't explain why
the orphan list is corrupted.

Could it be that your system had skewed time before the crash? 1/1/1970?

>
> Thanks in advance for your help!
> ~ Hari
>
> P.S. I wasn't sure if this is the right forum to post this question but I couldn't find a e2fsprogs mailing list and linux-ext4 seemed like a good alternative. Sorry, if this is the wrong forum.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html