Page 1 of 1

Mac-formatted harddisk: Unreadable partition table?

Posted: Mon Apr 02, 2012 12:28 pm
by ^rooker
[PROBLEM]
I've received an external USB drive, claiming to have 4 partitions.
At least that's what /dev says:

Code: Select all

brw-rw---- 1 root floppy 8, 32 2012-04-02 11:44 /dev/sdc
brw-rw---- 1 root floppy 8, 33 2012-04-02 11:44 /dev/sdc1
brw-rw---- 1 root floppy 8, 34 2012-04-02 11:44 /dev/sdc2
brw-rw---- 1 root floppy 8, 35 2012-04-02 11:44 /dev/sdc3
brw-rw---- 1 root floppy 8, 36 2012-04-02 11:44 /dev/sdc4
It should only have had 1, so I tried to run "fdisk", but was greeted with another, interesting message:
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0x72a2763b.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.
Plugging the drive into a Windows7 machine, Windows told me that it had to initialize the drive before being able to use it.
The output of "dmesg" slightly confirms my assumption that this disk has been re-formatted on a Mac:

Code: Select all

[1720533.501332] Initializing USB Mass Storage driver...
[1720533.501415] scsi4 : SCSI emulation for USB Mass Storage devices
[1720533.501483] usb-storage: device found at 5
[1720533.501484] usb-storage: waiting for device to settle before scanning
[1720533.501493] usbcore: registered new interface driver usb-storage
[1720533.501528] USB Mass Storage support registered.
[1720538.518664] usb-storage: device scan complete
[1720538.554897] scsi 4:0:0:0: Direct-Access     ST950032 5AS              0002 PQ: 0 ANSI: 5
[1720538.642475] sd 4:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 GB/465 GiB)
[1720538.929720] sd 4:0:0:0: [sdc] Write Protect is off
[1720538.929755] sd 4:0:0:0: [sdc] Mode Sense: 23 00 00 00
[1720538.929759] sd 4:0:0:0: [sdc] Assuming drive cache: write through
[1720539.428995] sd 4:0:0:0: [sdc] Assuming drive cache: write through
[1720539.429034]  sdc: [mac] sdc1 sdc2 sdc3 sdc4
[1720540.331641] sd 4:0:0:0: [sdc] Assuming drive cache: write through
[1720540.331679] sd 4:0:0:0: [sdc] Attached SCSI disk
The interesting line here being:
[1720539.429034] sdc: [mac] sdc1 sdc2 sdc3 sdc4
Trying to mount one of the partitions inspite of fdisk's output:

Code: Select all

sudo mount /dev/sdc1 /mnt/usb
was unsuccessful:
mount: you must specify the filesystem type
Ok, so I tried again with "-t hfsplus":

Code: Select all

sudo mount /dev/sdc1 -t hfsplus /mnt/usb
Again, unsuccessfully:
mount: wrong fs type, bad option, bad superblock on /dev/sdc1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Dmesg said:
[1724183.567124] attempt to access beyond end of device
[1724183.567160] sdc1: rw=0, want=262211, limit=63
[1724183.567189] hfs: unable to find HFS+ superblock
[SOLUTION]
I haven't been able to read the partition table to find out which partition is which, but I've successfully mounted partitions.
It seemed that the first two (sdc1, sdc2) and the last one (sdc4) are "something else" - and not HFS+.
Mounting /dev/sdc3 worked:

Code: Select all

sudo mount /dev/sdc3 /mnt/usb
I didn't even have to specificy "-t hfsplus".

Not perfect, but at least usable...

Re: Mac-formatted harddisk: Unreadable partition table?

Posted: Tue Apr 03, 2012 10:22 am
by ^rooker
Just a short update:
The performance of accessing data on the HFS+ partition is unbearable. It's currently about 870kB/sec! :shock:
WTF?

It's not limited by CPU, as this is running on a 3.6GHz Dual-Core. I'm using rsync to copy the files, and htop shows the rsync process with about 0.7% CPU usage. Hm...?
The system load, on the other hand, is around 1.70.

UPDATE:
According to a benchmark on "Girly 'n' Geek"'s blog, HFS+ supports regular read/write speeds under Linux - With a similar Kernel than the one I'm using: 2.6.32-bpo.5-686 (Debian Lenny Backports)).
This means, that the problem is somewhere else...

However, the ~870kB/sec remind me of 11 MBit performance - which could mean:
Maybe wrong-USB-driver-or-version (again)?

Hunting the slow wabbit!

Posted: Tue Apr 03, 2012 1:06 pm
by ^rooker
In order to confirm or refute my assumption about USB being the reason for the low transfer speeds, I've checked "dmesg" for suspicious output.
Unfortunately, I don't see any:
[1720532.998852] usb 1-1.3: new high speed USB device using ehci_hcd and address 5
[1720533.338339] usb 1-1.3: New USB device found, idVendor=059f, idProduct=1051
[1720533.338377] usb 1-1.3: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[1720533.338429] usb 1-1.3: Product: Rugged Mini USB 3
[1720533.338462] usb 1-1.3: Manufacturer: LaCie
[1720533.338492] usb 1-1.3: SerialNumber: 00000000e452d16800ad
[1720533.338580] usb 1-1.3: configuration #1 chosen from 1 choice
[1720533.501332] Initializing USB Mass Storage driver...
[1720533.501415] scsi4 : SCSI emulation for USB Mass Storage devices
[1720533.501483] usb-storage: device found at 5
[1720533.501484] usb-storage: waiting for device to settle before scanning
[1720533.501493] usbcore: registered new interface driver usb-storage
[1720533.501528] USB Mass Storage support registered.
[1720538.518664] usb-storage: device scan complete
[1720538.554897] scsi 4:0:0:0: Direct-Access ST950032 5AS 0002 PQ: 0 ANSI: 5
[1720538.642475] sd 4:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 GB/465 GiB)
[1720538.929720] sd 4:0:0:0: [sdc] Write Protect is off
[1720538.929755] sd 4:0:0:0: [sdc] Mode Sense: 23 00 00 00
[1720538.929759] sd 4:0:0:0: [sdc] Assuming drive cache: write through
[1720539.428995] sd 4:0:0:0: [sdc] Assuming drive cache: write through
[1720539.429034] sdc: [mac] sdc1 sdc2 sdc3 sdc4
[1720540.331641] sd 4:0:0:0: [sdc] Assuming drive cache: write through
[1720540.331679] sd 4:0:0:0: [sdc] Attached SCSI disk
It says:
usb 1-1.3: new high speed USB device using ehci_hcd and address 5
Also, the ohci kernel module is not loaded (according to "lsmod |grep ohci"), but ehci is - and I've even tried "modprobe xhci" - and "lsmod" confirms it being loaded.