• The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm

    There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.

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.
 
af123 said:
... 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.
Click to expand...

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
 
af123 said:
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):
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top