#51 --read-sector output should not be byte-swapped

[Mark K]

The --read-sector option prints a hex dump of one disk sector. However, on little-endian machines (e.g. any x86/x86-64), the output is byte-swapped. That's because hdparm treats the sector data as an array of words. It shouldn't do.

To see the problem, try this:
(copy sector 0 data to a file using dd)
# dd if=/dev/sda of=sector0.bin bs=512 count=1
(get a hex dump of sector 0)
# hd -v sector0.bin
(now compare with hdparm's output)
# hdparm --read-sector 0 /dev/sda

Some actual data as output by hd:
eb 0e 03 00 04 00 0d 02 00 00 00 00 00 00 4e 50
fa 33 c0 bc 00 66 8e d0 50 07 50 1f fb fc bf 00

Now the corresponding extract from hdparm output:
reading sector 0: succeeded
0eeb 0003 0004 020d 0000 0000 0000 504e
33fa bcc0 6600 d08e 0750 1f50 fcfb 00bf

Notice each pair of bytes are flipped, so e.g. what would be "hello there!" is actually "ehll ohtre!e"

There's a similar problem with the --Istdout option too. The hex dump has its bytes swapped, when it should show the raw data received from the drive.

[Mark Lord]

Version 9.42 will use le16 format for all hexdumps, regardless of host endian.

[Andreas E]

This is 2 years old. But I have 9.43 here and the behavior is exactly as described far above. All output of --read-sector is still byte-swapped, so unfortunately nothing has changed in 9.43. (But maybe later?)
Lubuntu Utopic, on a x86 machine, 32 bit.

[Mark Lord]

Current version of hdparm has this fixed. Try something from the past two years, eg. hdparm-9.45.

[Andreas E]

Hello Mark, thanks for the speedy reply.
Well, I the origin of the problem is that even Utopic still ships a (as I know now) fairly old version of hdparm. (And I thought 9.43 is somewhat recent!!)
This is all quite a bad joke. https://launchpad.net/ubuntu/+source/hdparm Vivid will obviously be shipping the very same version as Utopic. Well, while I have nothing against shipping (seemingly) more stable previous versions - they ought not be 2 years old. And no, there is even no PPA of 9.45+.
Though I feel very uneasy mixing tools from various distros, I will make an exception, taking 9.45 from Arch core repo or even 9.48 from Arch testing repo.

TESTED. Byte order is indeed CORRECT now - no more pointless tweaking needed, thank you so much!! BUT: as it shows above, it will take until next year's Christmas until every server distro like RHEL/SLES... will have "made it" to 9.45, since everyone knows with server systems, warranty means "warranty for the tool versions installed by default".

Anyways...Problem solved, thanks again.