2TB Disk Installation Blog
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.
Contents
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 75C;
- 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). On balance, I stuck with the Seagate but I'm sure the WD would be fine too.
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.
Opening the case voids the warranty but I only had a few months 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 hairdryer to melt the glue on the warranty seal rather than breaking it.
On booting up the Humax, 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.
Partitioning
So, I needed to partition the hard disk. As this is an advanced format drive, it uses 4K sector sizes and there is performance degredation if the partitions aren't aligned to 4K. While Seagate say that the impact is minimal due to their SmartAlign feature, they still recommend aligning your partitions properly from the outset. As a result, I defined all of my partitions in terms of sectors rather than cylinders and ensured that the start sector of each partition was divisible by 8.
The default Humax partitioning is:
1 1GB EPG data
2 <rest> Recorded media
3 10GB Cache/Cookies.
I first needed to determine the number of sectors required for partition 3. Rather than calculate it I just created a single partition on the disk of size 10GB and read off the number of sectors:
humax# gfdisk /dev/sda
Using /dev/sda
Command (m for help): n
Partition type
e extended
p primary partition (1-4)
p
First cylinder (default 0cyl):
Last cylinder or +size or +sizeMB or +sizeKB (default 243200cyl): +10g
Command (m for help): w
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 63 19535039 9767488 83 Linux
Ignoring that this partition is not aligned, it uses 19535039 - 63 = 19534976 sectors.
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 2000063 1004031 83 Linux
/dev/sda2 2000064 3887489079 1942748482 83 Linux
/dev/sda3 3887489080 3907024064 9759487 83 Linux
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 | 4194304 on /mnt/hd2, 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 future check time. Since the average file size on that partition is so large, there's no problem in only having one inode for every 4MB of space. It still provides for almost half a million files and directories.
So:
humax# mkfs.ext3 -m 0 -O sparse_super /dev/sda1 humax# mkfs.ext3 -m 0 -O sparse_super -T largefile4 /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
Filesystem volume name: <none> Last mounted on: <not available> Filesystem UUID: 7f32c360-77af-406b-9a33-cc1277d4baf8 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: 474304 Block count: 485686127 Reserved block count: 0 Free blocks: 485574533 Free inodes: 474279 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 908 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 32 Inode blocks per group: 2 Filesystem created: Mon Aug 6 22:03:12 2012 Last mount time: Mon Aug 6 22:28:54 2012 Last write time: Mon Aug 6 22:28:54 2012 Mount count: 2 Maximum mount count: 25 Last checked: Mon Aug 6 22:03:12 2012 Check interval: 15552000 (6 months) Next check after: Sat Feb 2 22:03:12 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 Default directory hash: half_md4 Directory Hash Seed: f83c8831-ad94-471e-b207-1338bbb50f60 Journal backup: inode blocks
