linux-ext4 - Re: Fwd: strange e2fsck magic number behaviour

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] [day] [month] [year] [list]

Date:	Thu, 12 Sep 2013 13:35:34 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Alexander Harrowell <a.harrowell@...il.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: Fwd: strange e2fsck magic number behaviour

On Thu, Sep 12, 2013 at 04:39:33PM +0000, Alexander Harrowell wrote:
> I'm currently trying to recover an ext4 filesystem. Last night, during
> a resize operation, the system (Ubuntu 12.04 LTS on my fix-stuff usb
> stick) locked up hard and eventually crashed. Restarting,
> unsurprisingly, gparted offered to check the volume. e2fsck, called
> from within gparted, replayed the journal overnight and completed the
> resize.

How big was this file system?  And it sounds like you were doing an
on-line resize (that is, the file system was mounted at the time when
you did the resize)?  There were some bugs there with file file
systems with block numbers > 32-bits (i.e., greater than 16TB).  But
for smaller file systems, online resize should have been fairly safe.
Certainly I'm not aware of any bugs that resulted in the system
locking up hard.

> and now comes the interesting bit - at some point, block 16777215
> starts to appear more and more often in the inodes, often duplicated,
> until it starts to print out the number 16777215 in a fast loop. in
> fact, it looks like it hits some inode and keeps printing block
> 16777215 to the same very long line (it's generated 500MB of log)

0xFFFFFF or 0x1000000 isn't a magic boundary as far as ext4 is
concerned.  It appears that this is showing up as part of the multiply
claimed blocks error message?  That usually happens because there was
garbage in an indirect block or in the extent tree.

What you might have remembered is that the maximum number of physical
blocks with ext4 is 48 bits, but what you are reporting is 24 bits,
which is something else quite different.

It would help to see a short except of exactly what e2fsck reported,
so we could see whether it is being reported as a logical block number
or a physical block number.  However, I suspect this is really much
more of a symptom rather than the cause.

Regards,

						- Ted
--
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