Message-ID: <CAGpXXZK=AUu=xARVUGfU6mWCRm1FENLvnU89zG4SV0gpFG1Png@mail.gmail.com>
Date:	Sun, 27 Nov 2011 14:16:37 -0500
From:	Greg Freemyer <greg.freemyer@...il.com>
To:	Lucas Teixeira <lucas@...asteixeira.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: Ext4 newbie trying to recover its partition table

See interspersed

On Sun, Nov 27, 2011 at 11:06 AM, Lucas Teixeira
<lucas@...asteixeira.com> wrote:
> Hello,
>
> For more than a year I've been trying to recover data from a harddisk
> of mine. I have really important personal files there, and I would
> like to recover it myself, as I don't know of any recovering service
> that I would trust to analyze ext4 partitions.

x-ways forensics supports ext4, and recovery experts work from a
"image" of your drive, so they should not cause any non-recoverable
damage.

(I do computer forensics for a living.  I use X-Ways primarily to do
my work, but your right, I rarely see a ext4 filesystem to analyse.)

If this is really valuable info, the first thing you should do is make
a "image" of the drive:

You'll need a second disk with enough freespace to hold the entire
original disk, then its just:

dd if=/dev/sdx of=image_file bs=4K conv=noerror,sync

bs=4k I just a speed optimization thing
noerror says not to abort on a bad block
sync says if there is a bad block, output nulls to fill it up.  That
is very important.

X-ways can work directly from that image, but it costs about $1K (US)
and further it may not work well for this case.

Once you have that backup, you can try gpart?  I think it is available
in most distros and can try to rebuild a partition table.

(I'd separately backup just sector 0 before I tried gpart, then if you
don't like the results you can put it back.)

Also, I personally would install the "sleuthkit" package.  It has lots
of command line tools designed to work with images like the above.

Here's one tool that may help:

http://wiki.sleuthkit.org/index.php?title=Mmls

sleuthkit is packaged by at least a few of the distros.

> I don't know if anyone here even has the time to read my diagnosis
> (pasted below).
>
> **I would like good resources and tips to learn ext4 structure and
> dive into e2fsprogs source code, in order to recover the files in my
> misteriously lost partitions.**
>
> My C experience is limited to CRUD programs, linked lists and search
> trees (learned at college, before I dropped out), but I am determined
> to learn what is needed.
>
> Thank you very much, and sorry for the sometimes confusing english
> (I'm from Brazil)
>
> I'm pasting here what I said at reddit.com a year ago:
>
>
>        TL;DR: The partition table that I recovered with TestDisk say that
>        my three ext4 partitions begin exactly 316 bytes before they really
>        begin. I don't know how to make a partition table that says exactly
>        where it starts. (see fdisk output after the jump
>
>        Hello,
>
>        I have a Seagate Barracuda ST31000333AS HD (1TB of storage), and I
>        recently bought an external case for it. It was already formatted with
>        3 ext4 partitions.
>
>        The last thing I remember is deleting a HFS partition (it has
>        something to do with my love's Macbook), and then... the partition
>        table was gone.
>
>        I tried some tools to recover the partition table, and I finally
>        thought that TestDisk got it right... well, it almost did.
>
>        The sizes and positions of the recovered partitions seemed just right,
>        but I couldn't mount it. And the type of the partitions in this new
>        table was ext3, not ext4.
>
>        After a lot of hexdump's and dd's, I learned a few things about
>        partition tables *and* (sort of) discovered the problem:
>
>            lucas@...ckie:~$ sudo dd if=/dev/sdc1 of=/tmp/with_offset ibs=1
>        skip=316 count=1048576     /dev/null lucas@...ckie:~$ file
>        /tmp/with_offset /tmp/with_offset: Linux rev 1.0 ext4 filesystem data,
>        UUID=d94f8233-7b02-4d9e-a20a-18831225c990, volume name "todomundo"
>        (extents) (large files) (huge files)
>
>        What I'm doing here is copying the the first megabyte of the partition
>        with an offset of 316 bytes. The result is recognized as the original
>        partition. This happens with all the three ext4 partitions that are in
>        the disk.
>
>        But partition tables deal with cylinders and sectors, not bytes. I
>        can't put the right address in the table with any of these two units.

cylinders are extremely rarely used anymore.  I think any drive over
4GB cannot be accessed via CHS.  Focus exclusively on sectors.

>        I didn't mess with disk geometry at any point of this story. Anyway, I
>        don't know if TestDisk changes the geometry without warnings, so the
>        geometry may be wrong. The geometry of the disk *right now* is:
>
>            255 heads, 63 sectors/track, 121601 cylinders Sector size
>        (logical/physical): 512 bytes / 512 bytes

None of the tools will pay attention to head/cylinders/etc.

Al that matters is sectors from the start of the drive.

>        I downloaded the HD manual, and it says that the default geometry is:
>
>            Heads: 6 Discs: 3 Bytes per sector: 512 Default sectors per track:
>        63 Default read/write heads: 16 Default cylinders 16,383

Don't worry about geometry.

>        But when I try to feed TestDisk with this information, it says that my
>        HD has 8455MiB, which is not true.
>
>        I have an intermittent connection with the Internet (I have no
>        Internet at home, and I usually have to take a bus or walk ~30min to
>        access it), but I did my homework: applied my google fu, flirted with
>        hexdump and dd, RTFM... I have no idea what to do.
>
>        ### fdisk -l -u: ###
>
>            Disco /dev/sdc: 1000.2 GB, 1000204886016 bytes 255 heads, 63
>        sectors/track, 121601 cylinders, total de 1953525168 setores Unidades
>        = setores de 1 * 512 = 512 bytes Sector size (logical/physical): 512
>        bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes
>        Identificador do disco: 0x000e09b9
>
>            Dispositivo Boot Início Fim Blocos Id Sistema /dev/sdc1
>        63  1232731709   616365823+  83  Linux /dev/sdc2   *  1234675575
>        1646325134   205824780   83  Linux /dev/sdc3      1646325135
>        1953520064   153597465   83  Linux
> l

Good Luck
Greg
--
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