Date:	Thu, 12 Sep 2013 16:56:59 +0000
From:	Alexander Harrowell <a.harrowell@...il.com>
To:	linux-ext4@...r.kernel.org
Subject: Fwd: Fwd: strange e2fsck magic number behaviour

---------- Forwarded message ----------
From: Alexander Harrowell <a.harrowell@...il.com>
Date: Thu, Sep 12, 2013 at 4:54 PM
Subject: Re: Fwd: strange e2fsck magic number behaviour
To: Eric Sandeen <sandeen@...hat.com>


It was 63GB and I just wanted to fork over 3GB of extra space from my
Windows partition...

The fstab is as follows

/dev/sda1 SYSTEM_DRV ntfs 1.17g (boot)
/dev/sda2 Windows7_OS ntfs 63.4G
/dev/sda4 extended partition containing:
-- /dev/sda6 swap linux-swap 8.05G
-- /dev/sda5 /home ext4 66.14G
/dev/sda3 Lenovo_Recovery ntfs 10.25G
unallocated 1M

that's what was intended and is what gparted reports. (however,
weirdly, if you ask Ubuntu Disk Utility, it says /dev/sda5 is 71GB and
/dev/sda4 is correspondingly bigger. this I have only just noticed.)

kernel is 3.2.0-29-generic, machine is a ThinkPad X200s with 160GB disk.

thanks for your help.


On Thu, Sep 12, 2013 at 4:44 PM, Eric Sandeen <sandeen@...hat.com> wrote:
> 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@...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

Powered by blists - more mailing lists