I have a 500GB Toshiba 2.5' HD, which I formated using Debian Wheezy 64bit. I created 2 partitions (180GB and 320GB).
RPi would only recognize the first partition. 

So, I tried creating the partitions using the raspberrypi. Here are my surprising findings:

root@raspberrypi:/home/ozn# fdisk -l

Disk /dev/mmcblk0: 4025 MB, 4025483264 bytes
4 heads, 16 sectors/track, 122848 cylinders, total 7862272 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: 0x000dbfc6

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1            8192      122879       57344    c  W95 FAT32 (LBA)
/dev/mmcblk0p2          122880     7862271     3869696   83  Linux

Disk /dev/sda: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 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: 0x950e3b8d

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048   625142447   312570200   83  Linux
/dev/sda2       625142448   976773167   175815360   83  Linux


First, /dev/sda is NOT recognized correctly! This disk is 500GB. 

Second, mounting /dev/sda2 is not possible:

root@raspberrypi:/home/ozn# mount -t ext4 /dev/sda2 /media/usbhdd1/
mount: special device /dev/sda2 does not exist
# although fdisk -l showed this device !


Third, trying to format the disk, it really sees only the sectors until 320GB:
When I start fdisk I am warned:

Building a new DOS disklabel with disk identifier 0x6784fc4b.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.


I have other USB hard drives with 320GB and they really mount fine. 


Is this a limitation of RPi? Or a problem with this specific Hard Drive?   
How can I use this large disk with my RPi? 


update: solved the issue with help of the commentators here...

here is what I did ...


I thought I have some weired issue with Debian Wheezy &amp; gparted. So, I reformatted the hard drive to NTFS. Before that I ERASED the partition table. 
And created a new single NTFS partition. 
Bingo! RPi, identified the partition. However, it claimed my Drive is now 2TB big, and recommended I will use GPT:

root@raspberrypi:/home/ozn# fdisk -l /dev/sda

Disk /dev/sda: 2199.0 GB, 2199023255552 bytes
255 heads, 63 sectors/track, 267349 cylinders, total 4294967296 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: 0xf720f720

Disk /dev/sda doesn't contain a valid partition table
root@raspberrypi:/home/ozn# fdisk  /dev/sda
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0xb7032c3f.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

WARNING: The size of this disk is 2.2 TB (2199023255552 bytes).
DOS partition table format can not be used on drives for volumes
larger than (2199023255040 bytes) for 512-byte sectors. Use parted(1) and GUID 
partition table format (GPT).



whoops! That is WRONG!

So, I disconnected the hard drive again. re-connented it to my laptop. I erased the partition table again, and re-created the partition table using fdisk on RPi! not on my laptop! This time, I took a short cut, and created the disk partition with ext4 directly. 
    I plugged the hard-drive to RPi and BINGO!

root@raspberrypi:/home/ozn# fdisk -l

Disk /dev/sda: 500.1 GB, 500107862016 bytes
81 heads, 63 sectors/track, 191411 cylinders, total 976773168 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: 0x000505b8

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048   976773167   488385560   83  Linux

Disk /dev/mmcblk0: 4025 MB, 4025483264 bytes
4 heads, 16 sectors/track, 122848 cylinders, total 7862272 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: 0x000dbfc6

Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1            8192      122879       57344    c  W95 FAT32 (LBA)
/dev/mmcblk0p2          122880     7862271     3869696   83  Linux

Disk /dev/sda: 500.1 GB, 500107862016 bytes
81 heads, 63 sectors/track, 191411 cylinders, total 976773168 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: 0x000505b8

Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048   976773167   488385560   83  Linux


The disk is now identified correctly on my laptop with Debian. 

ozdeb@yenitiny:~$ sudo fdisk -l /dev/sdb

Disk /dev/sdb: 500.1 GB, 500107862016 bytes
81 heads, 63 sectors/track, 191411 cylinders, total 976773168 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: 0x000505b8

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048   976773167   488385560   83  Linux


conclusion (?)

My guess is that gparted in Debian Wheezy includes some nasty bug which is sometimes showing it's ugly face. I would report a bug if I had more solid evidence. But ... since I have only one 500GB hard drive, and I don't want to
risk the health of this hard drive reformatting it so many time, I will settle this with it. If you happen to bump into this post, and you have had similar problems with large SATA drives and partitioning on wheezy, I would be happy to know.


Question: Equivalent Key Signatures
Answer: There is a strong case for certain enharmonic key uses
depending on the mode (minor/Major).

These four little tables show that Eb is significantly 
easier to write than D# for a major scale as
the latter would involve double sharps in the signature.

But F# and Gb Major are really close in complexity.

Major scales

Number of #s (upper lines) versus enharmonic number of bs



Number of bs (upper lines) versus enharmonic number of #s



Likewise C# minor is to be prefered to Db minor
but D# and Eb are interchangeable and this is indeed
what Bach did in its Well Tempered Keyboard (Preludium 8 and Fugue 8, BWV 853). He used
one for the prelude and the other for the fugue (See Alex Basson's answer about the validity of this substitution).

Minor scales

Number of #s (upper lines) versus enharmonic number of bs



Number of bs (upper lines) versus enharmonic number of #s



It explains that one favor keys that are practical in both modes
especially in styles when it is frequent to make modulations
or to switch between modes, such as variations.