2Tb HDD for Hdr Fox T2

With 1.02.32 firmware installed it can't format a 2TB drive automatically, but 1.03.12 will format this correctly and align the sectors: check this with the 4kalign diagnostic afterwards to be sure.
Got 1.03.12, so I should be able to fit and format Seagare 2TB HDD. What is the 4kalign diagnostic, and how do I run it to check correct alignment?
 
Is there any point in checking? It's like getting a blood test when there is a risk of false positives and not much you could do to cure it anyway. Check by all means, but if the test says the disk has not been aligned by the standard Humax format operation then the only thing you can do about it is a manual format as per af123's blog on the wiki. It is not certain that the alignment matters.

The test results could be useful information however: does the standard Humax format operation align the tracks or not? If it says "no", then it doesn't. If it says "yes", that might have been accidental.
 
Thanks Martin.
I'll report back on 4k align when I have done it. HDD is now in the post.
 
It is not certain that the alignment matters.
I'm not certain whether alignment is essential for proper operation of the unit as a PVR, but unaligned data access can cause increased noise and heat, generally reduced data transfer rates and a shorter life for the drive. It is a very good idea to ensure alignment. It is possible for a Seagate drive that their SmartAlign feature means that the drive does some sort of translation in the firmware but they don't provides details on how the feature works - I wouldn't rely on it.

does the standard Humax format operation align the tracks or not? .
I've seen reports of Humax HDRs being shipped with 4k-sector drives and both aligned and unaligned partitions. That could depend on which firmware version was used to format them however.
 
Here is the output from 4kalign for a 2TB disk formatted by a HDR-FOX running 1.03.12 firmware:
Code:
Running: 4kalign

--> This is an Advanced Format (AF) drive.

    Model Number:       ST2000VM003-1ET164                     
    Logical  Sector size:                   512 bytes
    Physical Sector size:                  4096 bytes
    Logical Sector-0 offset:                  0 bytes
    Nominal Media Rotation Rate: 5900

Disk /dev/sdb: 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/sdb1               8     2104510     1052226   83  Linux
/dev/sdb2         2104512  3886043166  1941969330   83  Linux
/dev/sdb3      3886043168  3907024062    10490445   83  Linux

*  OK   * - partiton /dev/sdb1 is properly aligned.
*  OK   * - partiton /dev/sdb2 is properly aligned.
*  OK   * - partiton /dev/sdb3 is properly aligned.
I have installed another 2TB disk in a different unit with similar results..
 
Out of curiosity, how is the number of "blocks" calculated from the "start" and the "end" (er) logical sector address (?)?

2104510-8=2104502, /2=1052251 not 1052226 (difference -25)
3886043166-2104512=3883938654, /2=1941969327 not 1941969330 (difference 3)
3907024062-3886043168=20980894, /2=10490447 not 10490445 (difference -2)

And in any case, if a "block" is two units, shouldn't the end sector address be odd?


(I'm having a sleepless night)
 
Out of curiosity, how is the number of "blocks" calculated from the "start" and the "end" (er) logical sector address (?)?

2104510-8=2104502, /2=1052251 not 1052226 (difference -25)
3886043166-2104512=3883938654, /2=1941969327 not 1941969330 (difference 3)
3907024062-3886043168=20980894, /2=10490447 not 10490445 (difference -2)

And in any case, if a "block" is two units, shouldn't the end sector address be odd?
A block is 1024 bytes (don't ask me why... it's some bizarre Unix thing that nothing/nobody else is really interested in), so is obviously 2*512 byte sectors (for a conventional disk).
So, Blocks = (end LBA - start LBA + 1) / 2
fdisk (Busybox) displays the numbers correctly (it seems to use a + suffix to indicate the half block if you have an odd number of sectors).
gfdisk (GNU fdisk) is a curious beast. It rounds the number of sectors to the nearest track boundary and then calculates the number of blocks from that. This would be just about acceptable in default cylinder display mode (although I wouldn't support it), but is completely bizarre when in sector display mode (-u command line option).
You therefore get meaningless numbers almost all the time, as working in multiples of cylinders/tracks is an archaic unnecessary concept these days.

Using your example:
2104510-8+1=2104503
2104503/63=33404.81
33404*63=2104452
2104452/2=1052226
whereas:
2104503/2=1052251.5 (displayed as 1052251+)

This is slightly simplified for the purposes of illustration. The full hideousness of the code is here (around line 1000), if you understand C:
https://bitbucket.org/skypher/fdisk...584135fb9d753ab7582ded/src/fdisk.c?at=default

I wonder why af123 chose to use gfdisk rather than fdisk in the 4kalign diagnostic though...
 
Re My post #24
My 2TiB disk 4kalign report.
Running: 4kalign
--> This is an Advanced Format (AF) drive.
Model Number: ST2000VM003-1ET164
Logical Sector size: 512 bytes
Physical Sector size: 4096 bytes
Logical Sector-0 offset: 0 bytes
Nominal Media Rotation Rate: 5900
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 8 2104510 1052226 83 Linux
/dev/sda2 2104512 3886043166 1941969330 83 Linux
/dev/sda3 3886043168 3907024062 10490445 83 Linux
* OK * - partiton /dev/sda1 is properly aligned.
* OK * - partiton /dev/sda2 is properly aligned.
* OK * - partiton /dev/sda3 is properly aligned.

SMART data was fine, showing 5 power cycles and most of the other fields were zero.
It's quiet and runs cool.
 
Back
Top