How to format a disk such that it's System is HPFS/NTFS/exFAT rather than GPT
 

Platform: A product that runs Ubuntu and streams to/from external drives.
When an external drive is connected, it's mounted and tested for throughput. A benchmark value is listed for each drive. Both ext4 and NTFS formats are supported. The GUI provides the option to format either ext4 or NTFS (so I don't know how it's done). Drives formatted NTFS on the system have very low benchmark (400 kB/s).
Issue: I have an NTFS drive that gets a benchmark of 1600 MB/s but I don't know how it was formatted. I'm looking for differences.

fdisk -l lists the drive's "System" as GPT on slow drives and as HPFS/NTFS/exFAT on the "good" drive.

Q1: Is System type the performance issue?
Q2: If yes, how do I format a drive with the right System?
If not, what else might be the problem?

GPT is partition type, NTFS, Ext4 and so on are filesystems. What kind of benchmark are you using, 1600 MB/s is unreal.

Oops. That should be 160 MB/s. (Shouldn't have used a slide rule to calculate it ;-)
The benchmark tool is internal to the system; I don't know what it is or (much about) how it works.
I just know the it rates this "golden" drive much higher than identical drives (SSDs) that were formatted by the system.

What kind of hardware is used to connect external drives?

The numbers I quoted were for a USB3 interface. On the eSATA interface the "slow" disks are still 100 kB/s, the golden unit is over 300 MB/s

Is this benchmark doing write or read tests? SSD drives may need "trimmed" to restore the write speed, also if the drive is partitioned it is possible the partition is misaligned. Won't happen with Ext4 if you do not partition the drive.

The benchmark does both read and write tests (and bypasses the cache, I'm told). There is only one partition on the drives.
The question remains, why is the benchmark rating so different on two identical SSDs formatted NTFS?

Thanks for your suggestions.

It seems to me there is some kind of mis-identification going on. Linux operating systems' access to NTFS is always inferior to native filesystems, and compared to Windows access to NTFS, and by multiple orders of magnitude. IOW, Linux access to NTFS is downright slow regardless of bus type. There's simply less difference to notice on slower buses because the bus is the ultimate bottleneck rather than the media. Is that faster "NTFS" SDD really NTFS?

When GPT disks are involved, gdisk -l should be used rather than fdisk -l.

Yes. Connected to a Windows PC, its format is listed as NTFS
And remember that the benchmark is running on the Ubuntu system.

Here's what fdisk -l returns for the "good" drive:

Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x000f10cb

Device Boot Start End Blocks Id System
/dev/sdc1 2048 1953521663 976759808 7 HPFS/NTFS/exFAT


For an identical SSD formatted by the system, fdisk returns:

Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdc1 1 1953525167 976762583+ ee GPT

So what is the make and model number of these drives?

ee GPT is the boot partition and as suggested we need to see the output of the

gdisk -l /dev/sdc
or
parted /dev/sdc print

The first drive is a legacy MBR formatted drive and the second is a GPT. In a nutshell GPT allows bootable drives larger then 2TB and almost an unlimited number of primary partitions.

What version of Ubuntu are you running? Does it support GPT? Now that was a stupid question...

Is this the first GPT drive you have tested?

Data that might explain the difference is missing for the "bad" ee GPT device because you didn't show us gdisk -l. The "bad" might actually be using a less efficient (smaller than 4k) I/O blocksize, while the "good" has clearly been partitioned in alignment with its 4k physical sectors.

They are Crucial MX200 (1TB SSD)

parted print results: (both results with the SSD in the same docking station)

"slow"

Model: ATA Crucial_CT1024MX (scsi)
Disk /dev/sdc: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number Start End Size File system Name Flags
1 1049kB 1000GB 1000GB ntfs primary


"fast"

Model: ATA Crucial_CT1024MX (scsi)
Disk /dev/sdc: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos

Number Start End Size Type File system Flags
1 1049kB 1000GB 1000GB primary ntfs


Thanks for your effort to help.

This 512 sector size is certainly bogus, the real sector size is 4096. Thus, the partition is misaligned.

While misalignment is a probable explanation for poor reported performance, I cannot believe fdisk output is reliable when an unknown version of it reports both ee as only partition and 512 physical block size on a 1T device. We need to know parted and/or gdisk output to be sure what the reality is.