View source for 2TB Disk Installation Blog

__NOTOC__
{{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&deg;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.

[[File:Disk_swap.png|Frame|right]]

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)

[[File:4kblocks.png]]

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:

{| class=wikitable
! 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:

{| class="wikitable"
! 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:

{| class="wikitable"
! 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.

{| class="wikitable"
|+ Comparison between the old and new disk partition sizes and inodes
|-
!rowspan=2| Filesystem
!colspan=2| Size
!colspan=2| 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|very large hard drive]].