In order to get the maximum performance, you need a driver that is aware of dual actuators. This was added to Linux 6.3, which became available to Ubuntu LTS users in 22.04.
A detailed tutorial on how to specifically partition these for the 10Gbe NAS users (following the methods outlined in the Level1Techs thread) for us non-savvy SSH/GIT users would be so amazing.
Good question. To be honest, I'm not sure. I think anyone serious about these drives would go with SAS version which show as two individual disks out of the gate. The SATA version and how they implemented it is a mystery to me.
@@htwingnut honestly if you got a huge pile of unstructed data as in an object store it will balance out even with the SATA version. of course SAS will have much better iops; but it seems in the end ideal setup is some raid 0+1 construction where you have, say, 12 of these per 1U node as a spanned Raid1 made out of 12 Raid0's. I suspect for anyone working with Software Defined Storage this disk is awesome, can't have anything better than twice the bandwidth per rack unit.
on linux you'd need to set the stripe/stride values for the raid to max out the performance, i suppose. i also wonder if you'd need to increase the NCQ depth. you'd probably also need to set --corelog to avoid having a block change bitmap on the same raid (which you WANT for real-life use but not for getting the raw performance)
never have understood why HDD being as legendary as it is the longest-used storage home use doesn't have way faster speeds Like why has it never been models with the rpm of 10k/20/40/50k as standards Why has the only real upgrade been mostly just bigger in sizes with TB
Back before ssds became cheap enough for the average consumer to throw in their system and call it a day. Western digital had 2 cool drives 1. The wd velociraptor was pretty fast for it's time It was a 15mm thick 2.5" drive. (Compared to the 7-9.5mm thickness that is common for laptop hdds.) And had a 10k rpm. The big caveat was the needed a dedicated 3.5" adapter sled called the "icepack" to keeps it's temps down. 2. They made a 128gb ssd and 1tb hdd combo laptop hard drive that, after installing a driver in windows, would show up as a dedicated 128gb ssd and 1tb hdd on a single 9.5mm hdd. Pretty cool, I had one for a laptop back in the day. As far as I know that's the only size the ever exist though. And things like firecuda drives replaced it later with the small ssd cache built into hdd for files that needed to be accessed quickly.
You can be sure these pathways have been researched. They could be done but would be too expensive. If you go for a huge number of heads and arms, you add failure points. If you go for extreme RPM, you need very advanced (read: expensive) materials and the failure possibility also increases. The least costly seems to be to increase density and use a number of plates. One more possibility to increase speed is to use larger sector sizes but then you "lose" useful surface as even a 1 byte file will take up the sector size, i.e. if you set 32kb, then it will take up 32kb. And a 32379 byte file will take up 2x32kb and so on. This idea to split the head handling is interesting as well. But sooner or later SSDs will become cheap enough that we can stop using HDDs, at least at home. It will be used for storage for a while still.
Dang. My QNAP has a SFP+ Port so I'd really hoped that a set of Mach.2 drives would eventually be a real speed upgrade when I run out of space on my current 14TB drives. But it seems that I can't even count on it to recognize the drive, much less get better performance than a regular drive. Disappointing - but thanks for testing.
Raid 0 of the two partitions makes them act in sync. Which might not be really different from having 10 platters and a single actuator (at least from the iops and latency perspective). Instead of doing so, is it possible to treat them as jbod and span across them? The OS IO scheduler would need to treat these partitions as separate volumes for the purpose of scheduling, rather than being the same disk. Otherwise, it looks like the dual actuator, while nice in concept, doesn't work well in practice. At least the sata single LUN implementation
Another excllent breakdown and summary.
Thank you for the kind words. Glad you found it useful!
In order to get the maximum performance, you need a driver that is aware of dual actuators. This was added to Linux 6.3, which became available to Ubuntu LTS users in 22.04.
A detailed tutorial on how to specifically partition these for the 10Gbe NAS users (following the methods outlined in the Level1Techs thread) for us non-savvy SSH/GIT users would be so amazing.
Great review! Very thorough
Is there a server OS that is used in datacenters that can recognize these dual actuator drives off the bat?
Good question. To be honest, I'm not sure. I think anyone serious about these drives would go with SAS version which show as two individual disks out of the gate. The SATA version and how they implemented it is a mystery to me.
@@htwingnut honestly if you got a huge pile of unstructed data as in an object store it will balance out even with the SATA version. of course SAS will have much better iops; but it seems in the end ideal setup is some raid 0+1 construction where you have, say, 12 of these per 1U node as a spanned Raid1 made out of 12 Raid0's. I suspect for anyone working with Software Defined Storage this disk is awesome, can't have anything better than twice the bandwidth per rack unit.
I was hoping for a little better results, but very interesting video nonetheless ^-^
Title says "in Windows" but the benchmarking also shows in Linux, which I was hoping for. :)
:) Glad you were pleasantly surprised! A bit disappointing though to be honest. Looked promising with CrystalDiskInfo at first.
@@htwingnut curious if there is a performance difference with the latest kernel/drivers in archlinux or nixos. :)
@@Crftbt I am not sure, but I am no longer in possession of these hard drives. If I get ahold of another one I will check it out.
@@CrftbtI mean you don't have to run nix or arch to run the latest kernel but you should be running nix ;)
I use nix btw.
@@KyesaRRi I guess there's unstable debian.
i shucked a Seagate Expansion 14tb and got an Exos 2x14 Mach.2 inside. I was quite surprised, to say the least.
Can we set the SATA 2x18 into 2 logical drives and configure as RAID 1 in software ? My Ryzen board doesn't have port multiplier though
Wonder if synology would work with those, and take advantage of the performance? Since I guess it only works with sata, and we'll see one disk.
on linux you'd need to set the stripe/stride values for the raid to max out the performance, i suppose. i also wonder if you'd need to increase the NCQ depth. you'd probably also need to set --corelog to avoid having a block change bitmap on the same raid (which you WANT for real-life use but not for getting the raw performance)
never have understood why HDD being as legendary as it is the longest-used storage home use doesn't have way faster speeds
Like why has it never been models with the rpm of 10k/20/40/50k as standards
Why has the only real upgrade been mostly just bigger in sizes with TB
Back before ssds became cheap enough for the average consumer to throw in their system and call it a day. Western digital had 2 cool drives
1. The wd velociraptor was pretty fast for it's time
It was a 15mm thick 2.5" drive. (Compared to the 7-9.5mm thickness that is common for laptop hdds.) And had a 10k rpm. The big caveat was the needed a dedicated 3.5" adapter sled called the "icepack" to keeps it's temps down.
2. They made a 128gb ssd and 1tb hdd combo laptop hard drive that, after installing a driver in windows, would show up as a dedicated 128gb ssd and 1tb hdd on a single 9.5mm hdd. Pretty cool, I had one for a laptop back in the day. As far as I know that's the only size the ever exist though. And things like firecuda drives replaced it later with the small ssd cache built into hdd for files that needed to be accessed quickly.
You can be sure these pathways have been researched. They could be done but would be too expensive. If you go for a huge number of heads and arms, you add failure points. If you go for extreme RPM, you need very advanced (read: expensive) materials and the failure possibility also increases. The least costly seems to be to increase density and use a number of plates. One more possibility to increase speed is to use larger sector sizes but then you "lose" useful surface as even a 1 byte file will take up the sector size, i.e. if you set 32kb, then it will take up 32kb. And a 32379 byte file will take up 2x32kb and so on. This idea to split the head handling is interesting as well. But sooner or later SSDs will become cheap enough that we can stop using HDDs, at least at home. It will be used for storage for a while still.
Dang. My QNAP has a SFP+ Port so I'd really hoped that a set of Mach.2 drives would eventually be a real speed upgrade when I run out of space on my current 14TB drives. But it seems that I can't even count on it to recognize the drive, much less get better performance than a regular drive. Disappointing - but thanks for testing.
Raid 0 of the two partitions makes them act in sync. Which might not be really different from having 10 platters and a single actuator (at least from the iops and latency perspective). Instead of doing so, is it possible to treat them as jbod and span across them? The OS IO scheduler would need to treat these partitions as separate volumes for the purpose of scheduling, rather than being the same disk.
Otherwise, it looks like the dual actuator, while nice in concept, doesn't work well in practice. At least the sata single LUN implementation