From: Eric Sandeen <sandeen@redhat.com>
To: Alexander Harrowell <a.harrowell@gmail.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Fwd: strange e2fsck magic number behaviour
Date: Thu, 12 Sep 2013 11:44:45 -0500 [thread overview]
Message-ID: <5231EF7D.20501@redhat.com> (raw)
In-Reply-To: <CA+qGm=_BBsNM6ZYYWhHucMiP7QWCfD0ApVQNa3ijN22AMN8mGw@mail.gmail.com>
On 9/12/13 11:39 AM, Alexander Harrowell wrote:
> I'm currently trying to recover an ext4 filesystem. Last night, during
> a resize operation,
from what size to what size? On what kernel?
> 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.
hmmm... perhaps.
> however, where I was expecting a volume with about 3.5GB of free
> space, there was now a volume with 32GB free space, a bit more than
> 50% utilised. inevitably, trying to boot the linux that lives in there
> dropped into grub rescue.
>
> going back, I tried to e2fsck it. this reported large numbers of inode
> issues and eventually reported clean. I could mount the volume, but
> file metadata looked generally broken (lots of ?s). testdisk showed
> the partitions were intact, although it claimed the drive was the
> wrong size (incorrectly), and found lots of deleted files within my
> ecryptfs home folder. It also found the backup superblocks for the
> damaged volume.
>
> the first couple I tried were corrupt, but the third was valid. e2fsck
> -b [superblock] -y reports fixing a lot of inode things, checksums,
> and then restarts. it then starts to report hunormous numbers of
> multiply-claimed blocks.
>
> 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)
= 111111111111111111111111 binary.
Guessing it's maybe a bitmap block?
Resize2fs has had a lot of trouble lately it seems. You may have just
been the unlucky recipient of a resize2fs bug...
-Eric
> I removed the first inode containing this block via debugfs, without
> this helping.
>
> It sticks out that 16777215 is a magic number (the maximum in a 48 bit
> address space) and I google that either ext4 or e2fsck has had a bug
> involving it before.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2013-09-12 16:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CA+qGm=-0w+gTh6=ZJhns_=4LKksJueiaYF0gxogmj=TmFN7yQg@mail.gmail.com>
2013-09-12 16:39 ` Fwd: strange e2fsck magic number behaviour Alexander Harrowell
2013-09-12 16:43 ` Alexander Harrowell
2013-09-12 16:44 ` Eric Sandeen [this message]
[not found] ` <CA+qGm=-jHzxFmb1yHqoB9UC8c7nvJN-WVP2Bb67=G63OKE3_2Q@mail.gmail.com>
2013-09-12 16:56 ` Fwd: Fwd: " Alexander Harrowell
2013-09-12 18:59 ` Eric Sandeen
2013-09-12 19:33 ` Alexander Harrowell
2013-09-13 11:46 ` Alexander Harrowell
2013-09-13 13:33 ` Alexander Harrowell
2013-09-13 13:34 ` Alexander Harrowell
2013-09-13 19:46 ` Theodore Ts'o
2013-09-12 17:35 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5231EF7D.20501@redhat.com \
--to=sandeen@redhat.com \
--cc=a.harrowell@gmail.com \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.