How to use fdisk -e in terminal?

Question

My problem is bit complicated, I will try explain this simple as possible.
It started because disk drive random eject, detail on this thread:
http://discussions.apple.com/message.jspa?messageID=13106931#13106931
Now one of my partition didn't mount. I try to fix this using disk utility -repair disk function- and disk warrior, both not succeed. Then I want to try repair it using Ubuntu live cd, but before that, some tutorial that I found in someone blog says I must disable journaling. It success at other 2 partition but the one that I need to repair wasn't return any dialog after about 2 minutes, that made me close Terminal. Disk1s2 is the problem.
My assumption after some googling, my partition table is messed up and need repairing. I found enlightenment when found tesdisk http://www.cgsecurity.org/wiki/TestDisk . Summaries from what I read there, I should able repair it after run test disk to analyze then using pdisk function in terminal to restore or fix the partition.
What is this mean CHS and LBA didn't match? I assume this value is needed to be repaired.
From the explanation on that site, "use pdisk to recreate the Mac partition map using the values given by TestDisk." Then I realized my partition scheme isn't Apple Partition Map. Refer to image screenshoot #1 it written Fdiskpartitonscheme or better known as MBR. Pdisk only support APM, and so far tutorial I found only write about pdisk:
http://perrohunter.com/read/30/repair-a-mac-os-x-hfs-partition-table
CMIIW but fdisk -e, edit function probably able to insert this new values on MBR. I just don't know how to do this.
So is there anyone in that able for *helping me to understand how I could edit this value using fdisk -e?* Please don't refer me to http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/ man8/fdisk.8.html . I've read that and still confused.
If possible using step by step explanation, similar with perrohunter pdisk. I'm not really expert with CLI.
Re-format the disk is not solution.
As for now my external drive condition is:
1. Random eject still occur.
2. One partition didn't mount.
3. Diskutil failed to disable journaling. Thus make worrying if fdisk also unable to do the job. But at least I want to give a try.
4. Slow write/read speed even on detected partition.

Answer 1

GPT fdisk (gdisk) will automatically look at the two partition tables and if they aren't the same will offer to fix them. There's ample info on the web about gdisk's options. I wouldn't let fdisk touch a GPT partitioned disk, it's for MBR disks only.
GPT disks do include an MBR, the so-called protective MBR. This is usually configured with four partitions of OS-type codes of EF or EE, IIRC.
Mac OS only uses LBA with hard drives. Internally the hard drive maps those logical block addresses to physical sectors, it's entirely possible mismatches are normal. The drive will take "bad" sectors out of use, keeping the LBA the same, but pointing to a different physical sector from a spare set of sectors.
I haven't seen anybody use CHS or ECHS in years. Not outside of some very specialized or legacy environments. The layout of the blocks on the disk surface aren't conducive to using that model any more (as the numbers of sectors present can vary by the track), and given that most everything after the first or second generation of ATA storage allows LBA. All the low-level driver stuff now tosses block numbers at the disk controller, and the disk controller and the disk map that to the particular physical or virtual geometry and figure out where the data with that address is stored, and returns it. SSD geometry, for instance, is entirely synthetic.
As for the GPT, EFI can find and fix what it considered bogus GPTs, which royally twisted some of the OS code I was working with around online disk volume expansions, and also snarled some stuff around non-GPT aware file systems with the copy of the GPT that is located at the highest LBA addresses. (I haven't checked this with the Apple implementation of EFI, but I've met a number of versions of EFI that do (often silently) repair corrupt GPTs. The EFI folks were probably better served by not silently repairing the GPT but rather tossing some diagnostics, but that's another discussion.)
As for the OP, the fix for a corrupted disk volume structure is to get the data off of the disk (quite possibly with the brute-force dd approach, if there's no current backup), and to then reinitialize and reload the disk volume. The dd gets you a copy of whatever is out there before repairs are attempted.
And to the OP, if you want to learn about the GPT structures, go have a look at the Intel EFI site or the UEFI forum sites. The details on the GPT structures are in the EFI specifications there.