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.
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.
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.
| 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.
