2TB Disk Installation Blog

Note: This Blog was written prior to the release of the 1.03.xx firmware, When running 1.03.xx firmware the Humax is capable of formatting and 4K aligning a new 2TB hard drive

I've just replaced the hard disk in my Humax HDR Fox-T2 with a 2TB drive as my original factory-fitted 1TB drive has recently suffered from a bad sector which somehow corrupted all large reads and writes to the disk. I was able to force the drive to overwrite the sector which resolved the immediate problem (old recordings now play-back successfully but those recordings made during the problem have artifacts). However, I've lost confidence in the disk and it's making a lot more clicking noises in operation than it did previously; that said, it's never been particularly quiet. Besides, who would pass up the chance to double the capacity?

There are a couple of good write-ups on how to replace the drive (e.g. http://myhumax.org/blog/?p=22), but these rely on an interim step of plugging the drive into a desktop computer (usually Linux) in order to partition and format the drive. I wanted a process which could be done entirely on the Humax itself in conjunction with the customised firmware.

Which drive?

Since I was replacing the drive anyway, I wanted to go for the largest amount of storage that was practical, especially as there is typically only a relatively small incremental cost each time you double the capacity.

However, the Linux kernel that is used on the Humax HDR Fox-T2 does not support disks with a GUID Partition Table (GPT) which is required if you want any partitions to be larger than 2TB. (See http://en.wikipedia.org/wiki/GUID_Partition_Table for more details) That gives a practical upper bound to the drive size since almost all of it is allocated to the media partition. It would likely be possible to use a custom kernel on the Humax and add support for GPTs but that could cause other issues and any reversion to standard Humax firmware would be problematic.

Also, the Humax firmware can neither partition nor format an internal drive which is over 1TB in size, but there are several reports of people who have successfully installed a 2TB drive having manually partitioned and formatted it. In fact there are 14 HDR devices registered with the hummypkg remote scheduling portal which have a 2TB drive.

Whichever drive is chosen, it should be one specifically designed for use in a PVR. These drives are known as CE or AV drives and are optimised for AV content. They generally run cooler and quieter than desktop drives as well as consuming less power. They also behave differently as regards error detection, correction and reporting. A single read/write error when recording AV content usually matters a lot less than a pause while the drive or application stops, waits for the disk platter to revolve again then retries the read.

I selected the Seagate Pipeline HD 2TB Drive (ST2000VM002/3) for a number of reasons:

• The existing factory-fitted disk is a Seagate Pipeline;
• It spins at 5900rpm which is a compromise speed offering slightly more performance (most CE/AV drives are 5400rpm);
• It is qualified for operating temperatures up to 75°C;
• Like all 2TB drives, it is an Advanced Format (4K sector size) drive. However, unlike other 2TB drives, it uses a technology called SmartAlign to handle partition misalignment conditions in the drive firmware without impacting on performance. Most other drive manufacturers have realignment tools which should be run following partitioning of these drives. I intended to create aligned partitions anyway but this was extra insurance in case it proved impossible.
• The WD drives (the realistic alternative) will apparently attempt to park the read heads once every 8 seconds for the life of the HDD which is just horrible!

On the down side, I couldn't find any reports of anyone using one of these drives in their Humax. The drive that has most often been used by others is the Western Digital AV-GP (WD20EURS). I considered that drive too, not least because it is 10% cheaper than the Seagate, but I read some reports of it being noisy on spin-up and spin-down (although quiet in operation) as well as the known head-park issue which can only be disabled if power saving is disabled globally on the drive. The Seagate felt like a better bet.

Custom Firmware

I installed version 2.12 of the customised firmware prior to proceeding. This version includes several disk management utilities within the firmware itself which allowed me to partition and format the new disk.

Installation

The new drive has identical dimensions to the old one (1.03" high) so I didn't expect any problems with the physical installation and it proved to be straightforward.

Opening the case voids the warranty but I only had a short time remaining anyway and had already opened the case some months earlier to remove the orange filter from the vacuum flourescent display (see Fixes / Work Arounds for Known Bugs#Display Too Dim) Still, I like things to be neat so I used a hair drier to melt the glue on the warranty seal rather than breaking it.

Here's the Humax with the lid off, the old disk to the left and the new one on the right hand side. The old disk is sitting on top of a SATA to USB caddy that I bought for £10 to house the old disk.

After swapping the hard disk I booted the Humax and it displayed a message on the screen saying that I needed to format the storage in order to use recording functions. Fair enough, but I knew that the Humax firmware wouldn't do it so I pressed Exit at that point.

Partitioning

Although the drive uses a 4K sector size, it reports a 512 byte sector size to the operating system and emulates 512-byte sectors in firmware. This emulation is very fast but if the OS modifies a single 512 byte sector then the entire real 4K sector must be read from the disk, the 512 byte range updated and then the 4K sector written back. This requires at least one additional revolution of the disk platter to achieve and degrades performance. Seagate claim that their SmartAlign feature reduces this degradation automatically but they still recommend taking steps to minimise the problem.

The solution is to align your operating system file-system block size with the native sector size of the disk and to ensure that the partitions on the disk are aligned with the 4K sectors. The following diagram illustrates this (note that for simplicity the internal ECC, gap and address marks are not shown - see http://en.wikipedia.org/wiki/Advanced_Format#Advanced_Format_overview if you want a more complete overview of how 4K sectors are implemented)

The first part is easy - ext3 has a default block size of 4096 bytes so maps nicely onto a 4K disk sector. However, just using a 4K file-system block size isn't enough. In the diagram above, file-system block A is not aligned with a disk sector so when block A is changed sectors X and Y must be updated using a read-modify-write sequence including an additional platter rotation. The complete solution requires that partitions are aligned with disk sectors. There's a good article on IBM's web site (http://www.ibm.com/developerworks/linux/library/l-4kb-sector-disks/) on the performance impact of misaligned sectors.

To achieve this, I used the GNU Fdisk (gfdisk) utility which is built into Custom Firmware 2.12 and above. The u command changes the input units from cylinders to sectors. I then just ensured that the start sector of each partition was divisible by 8.

The default Humax partitioning is:

Partition	Size	Used for
1	1GB	EPG data/DLNA database
2	<rest>	Recorded media/TSR buffer
3	10GB	Streaming cache/Cookies

I had to do some shuffling around to work out the sector boundaries to achieve partitions of approximately the correct size. My final partition table looks like this:

 humax# gfdisk -lu /dev/sda

 Disk /dev/sda: 2000 GB, 2000396321280 bytes
 255 heads, 63 sectors/track, 243201 cylinders, total 3907024065 sectors
 Units = sectors of 1 * 512 = 512 bytes

   Device Boot      Start         End      Blocks   Id  System 
/dev/sda1              64     2104575     1060258   83  Linux                 
/dev/sda2         2104576  3886043175  1941969330   83  Linux             
/dev/sda3      3886043176  3907024064    10482412   83  Linux

Note: The GNU Fdisk program will warn that these partitions do not end on a cylinder boundary. That's fine, Linux does not care.

Once it was defined, I rebooted to make sure the new partition table was refreshed in the kernel.

Formatting the file-systems

The default file-systems that are created by the Humax firmware are ext3 with the following key properties:

Features	has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Errors behavior	Continue
Directory hash	tea
Check interval	15552000 (6 months)
Maximum mount count	25
Inode ratio	16384
Reserved blocks	5%

I created my filesystems using the same parameters apart from following changes:

Directory hash	half_md4
Inode ratio	1048576 on /mnt/hd2, default 16384 elsewhere.
Reserved blocks	0%

Rationale

• half_md4 is a faster and better directory hashing algorithm (and the default with recent versions of the extfs utilities);
• There is no point reserving 5% of the disk space for the root user when everything runs as root;
• Creating fewer inodes on the large video partition saves space, decreases filesystem creation and check (fsck) time. Since the average file size on that partition is so large, there's no problem in only having one inode for every 1MB of space. It still provides for almost two million files and directories. I could have used even sparser inodes of one for every 4MB of space but I like to have a bit more headroom - you can't change it later.

So:

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

Next I rebooted the Humax (using the remote control) and when it came back up it created all the necessary directories under the new filesystems automatically and no longer prompted for me to format the storage.

Here's the filesystem parameters for my new video partition:

humax# tune2fs -l /dev/sda2
tune2fs 1.41.14 (22-Dec-2010)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          febec9f3-8bbb-4b59-ad65-e39c78399079
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1896576
Block count:              485492325
Reserved block count:     0
Free blocks:              485291873
Free inodes:              1896565
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      908
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         128
Inode blocks per group:   8
Filesystem created:       Mon Aug  6 23:22:38 2012
Last mount time:          Mon Aug  6 23:25:38 2012
Last write time:          Mon Aug  6 23:25:38 2012
Mount count:              1
Maximum mount count:      37
Last checked:             Mon Aug  6 23:22:38 2012
Check interval:           15552000 (6 months)
Next check after:         Sat Feb  2 23:22:38 2013
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       1087233
Default directory hash:   half_md4
Directory Hash Seed:      595f9f4d-4105-4c52-91c5-08e8ec7c084c
Journal backup:           inode blocks

Having put the old disk into the external USB caddy and connected it, I can see both disks alongside each other and begin to copy the content back across.

Comparison between the old and new disk partition sizes and inodes

Filesystem	Size		Inodes
	Original	New	Original	New
/dev/sda1	1011.4M	1011.4M	65808	65795
/dev/sda2	906G	1.8T	60314787	1882693
/dev/sda3	9.8G	9.8G	655763	655875

The only significant change is to the number of inodes allocated to the AV partition.

Installing a Drive Larger Than 2TB - Possible?

Yes, work is being done on this front. Please take a look at how to fit a Humax HDR-Fox T2 with a very large hard drive.