Does anybody here know how to read C?

Basically, my problem is this:

root# fdisk -l /dev/sdc

Disk /dev/sdc: 320.1 GB, 320072932864 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142447 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

    Device Boot      Start         End      Blocks   Id  System
/dev/sdc1              63      128519       64228+  af  HFS / HFS+
root# mount /dev/sdc1 /mnt
root# echo $?
0
root# umount /mnt
root# mount --ro -o offset=32256,sizelimit=6576994 /dev/sdc /mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop20,
        missing codepage or helper program, or other error
        In some cases useful info is found in syslog - try
        dmesg | tail or so
root# dmesg | tail
[164258.208493] hfs: unable to find HFS+ superblock
[164398.983651] hfs: invalid secondary volume header
[164398.983654] hfs: unable to find HFS+ superblock
[164404.235785] hfs: invalid secondary volume header
[164404.235787] hfs: unable to find HFS+ superblock
[164407.461400] hfs: invalid secondary volume header
[164407.461404] hfs: unable to find HFS+ superblock

In order words, if I mount /dev/sdc1, it works perfectly. But if I mount 
/dev/sdc, passing in the byte offsets to the start and end of the first 
partition, it doesn't work at all.

By pointing my web browser at kernel.org and wandering aimlessly through 
the Linux kernel source code, I was eventually able to discover that the 
first message ("unable to find HFS+ superblock") appears on line 410 of 
fs/hfsplus/super.c - which seems like a logical enough place for 
superblock-reading code to live.

My question: Can anybody figure out why the code is actually failing? 
What is it unhappy about? What has it expecting to find that wasn't 
there? (I guess it's kinda hard to conclusively pin this down without a 
copy of the disk...)

For me, just figuring out where the various functions are defined is 
quite hard. (C has this wonderful arrangement where any part of the code 
can refer to any other part of the code, with no algorithm for ever 
discovered WHERE that code is actually defined - except for 
whole-program analysis, obviously.) Also fun is that some of the 
"functions" are actually macros. Just to mess with your head.

OTOH, considering this is an OS kernel... it's not as awful as I had 
expected.

Post a reply to this message