Some disks lie about sector size, for compatibility with certain OS. If that is the case disk needs to be partitioned manually, I would go without partitioning and put the filesystem on raw device, can't go wrong with that.

Look at post 13

All things being equal I do not believe that GPT is slower then a MSDOS partitioned drive. Do you have another drive of the same model number? Easy enough to partition the slow one to MBR.

True , if both drives are of identical make/models and partitioned the same for start then what could be the difference.

You can use "hdparm -I /dev/sdc" to see what the drive actually reports. Note the upper case "I". That command might not work over a USB interface, but should always work over SATA/eSATA.

For the slow disk:

GPT fdisk (gdisk) version 0.8.1

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdc: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 32792A9E-FD22-4C4C-9160-4D0028DCBA06
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 3437 sectors (1.7 MiB)

Number Start (sector) End (sector) Size Code Name
1 2048 1953523711 931.5 GiB 0700 primary


For the good/fast drive:

Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format.
***************************************************************

Disk /dev/sdc: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 7D5E7EF5-6576-40D6-A20D-13EFB5CD8708
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 5485 sectors (2.7 MiB)

Number Start (sector) End (sector) Size Code Name
1 2048 1953521663 931.5 GiB 0700 Microsoft basic data

That didn't work on either drive (using eSATA). Results:
/dev/sdc:
HDIO_DRIVE_CMD(identify) failed: Bad address

Yes. How?

The recovery and transformation menu in gdisk can convert a GPT back to MBR. Out of curiosity are most of the disks using MBR that you test?

ext4 has been the common format; we're adding NTFS as a supported format but when the system formats a disk with NTFS, the benchmark is too low to be useful. I was trying to determine the limits and couldn't understand how one could work so well. I don't know how I created the "good" one but the more I learn about how it's formatted, the worse it sounds. Especially regarding GPT. We just qualified a 4TB SSD, and single files can be that large, so GPT is a requirement.

Pursuing this is probably not worth the effort. GPT may not be the performance issue but I don't know how the benchmark works. The benchmark routine belongs to Engineering and it's not worth it to them to figure it out until a customer wants it.

I've learned a few things. Thanks (to everyone) for helping,

I don't know why you assume that, fdisk on a 2tb seagate on fedora 23 shows 512/512.
Also, misalignment isn't that significant on newer drives, in reality we never see the real physical sector alignments, the drive firmware maps things physically unseen by the os.

When was it manufactured? Some drives lie. I have more than one such, and most I own made since 2010 are Seagate.

Got any proof? That's directly opposite my understanding, at least WRT writing. Check this Seagate explanation.