Installing a Drive Larger Than 2TB - Possible?

Looking at the disassembly, it actually just counts the partitions and doesn't even check the types. That's a good thing.
I've set up the GPT label with a protective MBR in front of it. That means that I should be able to put anything I want into that MBR table and it won't actually end up being used. I just need to make sure that there are three entries (to satisfy the Humax software) and that at least one of the entries starts at sector 1 and is of type EFI GPT (ee). From reading the kernel source code, that will be enough to make the kernel treat it as a protective MBR and look for the GPT table afterwards.
 
Cracked it. I created an MBR partition table with three 1GB partitions (size chosen so that I could see that it was definitely the GPT ones which were being mounted). fdisk refused to create a partition starting at sector 1 so I created the first one from the lowest allowed (63) and then moved it down to 1 in expert mode.

Code:
humax% fdisk /dev/sda
Command (m for help): u
Changing display/entry units to sectors

Command (m for help): n
Command action
  e  extended
  p  primary partition (1-4)
p
Partition number (1-4): 1
First sector (63-976773167, default 63): Using default value 63
Last sector or +size or +sizeM or +sizeK (63-976773167, default 976773167): +1G

Command (m for help): x
Expert command (m for help): b
Partition number (1-4): 1
New beginning of data (0-1953188, default 63): 1
Recalculate C/H/S values? (Y/N): n

Expert command (m for help): r

Command (m for help): p

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes

  Device Boot  Start  End  Blocks  Id System
/dev/sda1  1  1953188  976594  83 Linux
Partition 1 does not end on cylinder boundary

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): ee
Changed system type of partition 1 to ee (EFI GPT)

When I'd finished the partition table looked like this:

Code:
humax# fdisk -lu /dev/sda

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes

   Device Boot      Start         End      Blocks  Id System
/dev/sda1               1     1975994      987997  ee EFI GPT
/dev/sda2         1975995     3951989      987997+ 83 Linux
/dev/sda3         3951990     5927984      987997+ 83 Linux

Then, using gdisk, created a GPT table and three partitions within:

Code:
humax# gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: hybrid
  BSD: not present
  APM: not present
  GPT: not present

***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
typing 'q' if you don't want to convert your MBR partitions
to GPT format!
***************************************************************
Command (? for help): d
Partition number (2-3): 2

Command (? for help): d
Using 3

Command (? for help): n
Partition number (1-128, default 1): 1
First sector (34-976773134, default = 40) or {+-}size{KMGTP}:
Last sector (40-976773134, default = 976773134) or {+-}size{KMGTP}: +1G
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'

Command (? for help): n
Partition number (2-128, default 2):
First sector (34-976773134, default = 2097192) or {+-}size{KMGTP}:
Last sector (2097192-976773134, default = 976773134) or {+-}size{KMGTP}: -10G
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'

Command (? for help): n
Partition number (3-128, default 3):
First sector (34-976773134, default = 955801616) or {+-}size{KMGTP}:
Last sector (955801616-976773134, default = 976773134) or {+-}size{KMGTP}:
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'

Command (? for help): p
Disk /dev/sda: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 33082507-847C-4877-9429-FC75EE67C17B
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 8-sector boundaries
Total free space is 7 sectors (3.5 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40         2097191   1024.0 MiB  8300  Linux filesystem
   2         2097192       955801614   454.8 GiB   8300  Linux filesystem
   3       955801616       976773134   10.0 GiB    8300  Linux filesystem

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sda.

After a reboot, formatted:

Code:
humax# mkfs.ext3 -m 0 -O sparse_super /dev/sda1
humax# mkfs.ext3 -m 0 -O sparse_super -T largefile /dev/sda2
humax# mkfs.ext3 -m 0 -O sparse_super /dev/sda3

and one reboot later, all working.

Code:
humax# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                21.4M     21.4M         0 100% /
tmpfs                    60.9M     48.0K     60.9M   0% /tmp
tmpfs                    60.9M         0     60.9M   0% /media
/dev/mtdblock1            2.0M    516.0K      1.5M  25% /var/lib/humaxtv
/dev/mtdblock2            2.0M    500.0K      1.5M  24% /var/lib/humaxtv_backup
/dev/sda1              1007.9M     38.8M    969.1M   4% /mnt/hd1
/dev/sda2               454.6G      2.2G    452.4G   0% /mnt/hd2
/dev/sda3                 9.8G    150.6M      9.7G   1% /mnt/hd3

Code:
humax# status
Recording RED_20160127_2210
Watching 15: Film4 - RED (21:00 - 23:10) [56%]
Idle: 00:00:00

humax# ls -l /media/My\ Video/
-rw-r--r--    1 root     root         13184 Jan 27 22:14 RED_20160127_2210.hmt
-rw-r--r--    1 root     root        183264 Jan 27 22:14 RED_20160127_2210.nts
-rw-r--r--    1 root     root      82206720 Jan 27 22:14 RED_20160127_2210.ts

So, it is possible to use an internal disk with a GPT partition table, at least on a disk with 512 byte physical sectors.

Note that the gdisk utility isn't in the current firmware so if anyone wants a test version to try this themselves let me know.
 
... the version of Linux in use doesn't support GUID partition tables on 4K sector disks properly.
A full fix would involve backporting the fix for the last issue from a later kernel version.

I've mentioned this once or twice. Here's at least part of the patch we need:

http://git.kernel.org/cgit/linux/ke...4&id=7d13af3279985f554784a45cc961f706dbcdbdd1

I have it ported over to Broadcom stblinux 2.6.18 now. It might not actually be required since it appears that the disk I have ordered will still present 512 byte logical sectors.
 
Last edited:
More work required...

Code:
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F0000)
ata1.00: ATA-9, max UDMA/133, 7814037168 sectors: LBA48 NCQ (depth 0/32)
ata1.00: configured for UDMA/133
ata1: EH complete
  Vendor: ATA       Model: ST4000VM000-1F31  Rev: SC25
  Type:   Direct-Access                      ANSI SCSI revision: 05
sda : very big device. try to use READ CAPACITY(16).
sda : unsupported sector size -1095827456.
SCSI device sda: 0 512-byte hdwr sectors (0 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sd 0:0:0:0: Attached scsi disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0
 
With a couple of further changes to the kernel (which I need to do some more research into as I don't understand why they were necessary - it appears that the disk is not returning the right information in response to a READ_CAPACITY_16 inquiry - the data is there but in the wrong place - my 2TB disk does the same though):

Screenshot%202016-01-29%2022.04.03.png



Screenshot%202016-01-29%2022.09.35.png

Code:
humax# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                21.4M     21.4M         0 100% /
tmpfs                    60.9M     48.0K     60.9M   0% /tmp
tmpfs                    60.9M         0     60.9M   0% /media
/dev/mtdblock1            2.0M    568.0K      1.4M  28% /var/lib/humaxtv
/dev/mtdblock2            2.0M      1.3M    764.0K  63% /var/lib/humaxtv_backup
/dev/sda1              1007.9M     38.6M    969.3M   4% /mnt/hd1
/dev/sda2                 3.6T    282.4M      3.6T   0% /mnt/hd2
/dev/sda3                 9.8G    150.6M      9.7G   1% /mnt/hd3

Code:
humax# dmesg
sda : very big device. try to use READ CAPACITY(16).
SCSI device sda: 7814037168 512-byte hdwr sectors (4000787 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
 sda:<7>GUID Partition Table is valid!  Yea!
 sda1 sda2 sda3
 
With a couple of further changes to the kernel (which I need to do some more research into as I don't understand why they were necessary - it appears that the disk is not returning the right information in response to a READ_CAPACITY_16 inquiry - the data is there but in the wrong place - my 2TB disk does the same though):
Impressive. Can you record to it?
 
So...

Installing a Drive Larger Than 2TB - Possible?

Yes, however:
  • This requires custom firmware 3.10 or above*;
  • You will be unable to use stock firmware. In fact, loading stock firmware may well destroy the drive contents**;
  • It has only been tested with a 4TB Seagate Video drive (ST4000VM000);
  • It's early days***;
  • Higher capacity drives generally use more power and take longer to become ready;
  • it has only been tested up to 4TB (although there is no reason it should not work for larger drives);
  • it has only been tested a drive that advertises a 512-byte logical sector size (I'd expect more kernel work to be required for a drive advertising a 4K size).
* - not yet released but I will have a version available for testing in the next few days.
** - Careful selection of the MBR guard partitions should be able to prevent this from corrupting actual recordings making it recoverable.
*** - even though I have no need for 4TB of storage in my main DVR I will install this drive and use it daily to see how it goes.
 
Back
Top