On 9/12/13 11:56 AM, Alexander Harrowell wrote: > ---------- Forwarded message ---------- > From: Alexander Harrowell <a.harrowell@xxxxxxxxx> > Date: Thu, Sep 12, 2013 at 4:54 PM > Subject: Re: Fwd: strange e2fsck magic number behaviour > To: Eric Sandeen <sandeen@xxxxxxxxxx> > > > It was 63GB and I just wanted to fork over 3GB of extra space from my > Windows partition... Ok, so you tried to resize from 63G to 66G? Should have been relatively easy/safe. I forgot to ask which version of e2fsprogs you had, but if you did the grow online/mounted, most of the work is done in the kernel. As Ted said, knowing more info might yield clues: 1) what e2fsprogs version? 2) what were the kernel messages when it crashed/hung? 3) what was the fsck output? If you didn't save that stuff, it makes it harder to do a post-mortem... > 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.) TBH, I have no idea what Ubuntu Disk Utility does. I'd trust fdisk -lu output or /proc/partitions for accurate size info. Oh; 61.14GiB (powers of 2) == 71 GB (powers of 10) (61.14*1024*1024*1024/1000/1000/1000 = 71) So Ubuntu Disk Utility is in cahoots w/ the drive manufacturers, and using more favorable units. ;) -Eric > 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx >>> 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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
