Do you think we will see U.2 hard drives?

[cbn]

In the absence of a Windows Fusion drive, here is my guess on what is most likely for U.2 hard drive:

1. NAND based SSHD (Its gonna take 240GB of NAND (using the small dies) to approach saturating PCIe 3.0 x 4 though)
2. Optane based SSHD (Should only take 32GB of Optane to approach saturating PCIe 3.0 x 4)

For #2, I also wonder if the Optane can be used for the hard disk controller's dram buffer. If so, that then that is another chip that could be removed from the PCB.

With that noted, certainly there could also be a dual drive (operating as separate volumes of course) with at least 1TB of NAND possible as well. (re: 16 die package of 512Gb (64GB) 3D TLC = 1TB).

 

[Valantar]

Just wondering: do SSHDs use SLC for their cache? If not, how do they really improve on anything beyond response times with those tiny amounts of flash?

 

[VirtualLarry]

Just wondering: do SSHDs use SLC for their cache? If not, how do they really improve on anything beyond response times with those tiny amounts of flash?

Most commercial SSHDs are really just a sort of "smoke and mirrors" SSD-alike drive. They include just enough NAND flash cache memory, to allow for SSD-like boot times, but they do very little to speed up the HDD accesses beyond that.

 

[thecoolnessrune]

In the absence of a Windows Fusion drive, here is my guess on what is most likely for U.2 hard drive:

1. NAND based SSHD (Its gonna take 240GB of NAND (using the small dies) to approach saturating PCIe 3.0 x 4 though)
2. Optane based SSHD (Should only take 32GB of Optane to approach saturating PCIe 3.0 x 4)

For #2, I also wonder if the Optane can be used for the hard disk controller's dram buffer. If so, that then that is another chip that could be removed from the PCB.

With that noted, certainly there could also be a dual drive (operating as separate volumes of course) with at least 1TB of NAND possible as well. (re: 16 die package of 512Gb (64GB) 3D TLC = 1TB).

Technically, Windows does have a sort of feature that allows "Fusion" via Storage Space. Windows 10 has feature parity with Storage Spaces in Server 2012 R2, but you have to use PowerShell to configure the tiers. Of course Storage Spaces is not usable as a boot volume. As far as U.2 is concerned for it, the above I suppose could work if there was an internal PCI-e controller that could work with those. Multiple drives in one unit as already discussed would be a non-starter, as lane splitting is not really a consumer chipset feature (and isn't likely to become one anytime soon). Heck, we're still waiting on features like IOMMU, which is desperately needed in our PCI-e based feature.

Just wondering: do SSHDs use SLC for their cache? If not, how do they really improve on anything beyond response times with those tiny amounts of flash?

Seagate has been a big pusher for SSHDs. In reference to those, Gen 1 was SLC, whereas subsequent generations have been MLC (32GB on the current gen). As for capabilities, it is sensible. HDD achilles heel is random access, especially when many seeks are involved (like with small files). The Cache can make a measurable improvement on that. It's nothing amazing, but then again, a 1TB SSHD is a heck of a lot less money than a 1TB SSD, and an SSHD costs very little more compared to an HDD.

Most commercial SSHDs are really just a sort of "smoke and mirrors" SSD-alike drive. They include just enough NAND flash cache memory, to allow for SSD-like boot times, but they do very little to speed up the HDD accesses beyond that.

Once cached, depending on the drive use, it makes a very measurable difference. You get what you pay for, but an SSHD provides a noticeable improvement in many workloads vs. a standard HDD. Storage Review saw the same thing in their StorageMark 2010 Gaming Disk Capture Benchmark:

 

[heymrdj]

Pretty much this. Caching actually works really well for the cost. In the consumer market, where we see very little endurance and quality vs the enterprise stuff, a 512GB or 1TB SSD may make sense for every computer. But in enterprise, we've been swapping banks of 15K drives for a few SSD's for awhile now. I'm putting out S2D two node clusters with 4 400GB Enterprise Performance tier NVMe drivers, 4 800 GB Enterprise Mainstream Tier SAS (12Gbs) SSD's, and 16 4TB 7200 drives (all drives spread across the nodes, so half all that). Even though most of the data resides on 7200 RPM drives, we're running VM IOP workloads easily 20x higher than we could run on 48x 15K drives.

 

[Ichinisan]

Only SSDs have internal raid mechanisms

It's not "RAID" unless we're talking about multiple "... Independent Disks." We aren't talking about RAID.

CHS has been abstracted for a very long time. There's no good reason why hard drives wouldn't optimize locations so adjacent logical blocks are adjacent across platters.

 

[Hi-Fi Man]

Technically, Windows does have a sort of feature that allows "Fusion" via Storage Space. Windows 10 has feature parity with Storage Spaces in Server 2012 R2, but you have to use PowerShell to configure the tiers. Of course Storage Spaces is not usable as a boot volume. As far as U.2 is concerned for it, the above I suppose could work if there was an internal PCI-e controller that could work with those. Multiple drives in one unit as already discussed would be a non-starter, as lane splitting is not really a consumer chipset feature (and isn't likely to become one anytime soon). Heck, we're still waiting on features like IOMMU, which is desperately needed in our PCI-e based feature.

Do you have a source for how to configure tiered storage in Windows 10?

 

[master_shake_]

It's not "RAID" unless we're talking about multiple "... Independent Disks." We aren't talking about RAID.

CHS has been abstracted for a very long time. There's no good reason why hard drives wouldn't optimize locations so adjacent logical blocks are adjacent across platters.

no it's literally internal traditional raid at the hardware level in the SSD.

hard drives do not use it. only ssds.

 

[master_shake_]

wht!!!

 

[Ichinisan]

no it's literally internal traditional raid at the hardware level in the SSD.

hard drives do not use it. only ssds.

Then it's not "RAID"

I'm not talking about RAID either. Just the logical way for HDDs to structure data across platters since cylinder-head-sector became abstracted a long time ago.

 

[master_shake_]

it is RAID...

Imagine turning on your computer one day and discovering that you've suddenly lost some of the data you've saved. You look for your tax records, and suddenly, you can't find them. You try to send a photo to a friend, only to find the file isn't on your computer. Or you try and listen to a song you've downloaded, but it isn't in your music app. Data loss is a big deal, and that's why our engineers created industry-leading RAIN technology to help prevent this from ever happening to you.

At the most basic level, RAIN technology protects your data at the component level, similar to how RAID is used with multiple hard drives. Think of RAIN as you would real rain: When it's raining outside, rain lands all over the place. When you save data on a Crucial SSD that has RAIN, that's exactly what's happening. It's raining. Your data is being saved and dispersed (“landing”) on multiple different storage components on the drive. That way, if one of the components on the drive were to fail, your data would still be preserved elsewhere on the drive, and you'd still be able to access your tax records, photos, songs, and other files and applications.

http://www.crucial.com/usa/en/support-rain-technology

Redundant Array of Independent Silicon Elements (R.A.I.S.E.™) is a complementary technology to the Error Correcting Code (ECC) capabilities of the Flash Storage Processor (FSP) found in the LSI® SandForce® DuraClass™ technology component.

NAND Flash suffers from a number of naturally occurring bit errors (BE) during use. During the Beginning of Life (BOL) and End of Life (EOL) of the NAND Flash, these bit errors are then detected and corrected by the embedded Error Correcting Code (ECC) component.

https://www.kingston.com/en/ssd/raise

 

[Ichinisan]

it is RAID...



http://www.crucial.com/usa/en/support-rain-technology



https://www.kingston.com/en/ssd/raise

Yup. "RAIN" and "RAISE"

Not "RAID."

Traditional mechanical hard drives spreading contiguous blocks of data across multiple platters also wouldn't be called "RAID."

 

[master_shake_]

Yup. "RAIN" and "RAISE"

Not "RAID."

Traditional mechanical hard drives spreading contiguous blocks of data across multiple platters also wouldn't be called "RAID."

lol i'm arguing technical specs you semantics.

oh....kay...

 

[Ichinisan]

lol i'm arguing technical specs you semantics.

oh....kay...

I've also been saying traditional mechanical HDD manufacturers could have been doing "literally like internal RAID-0" across platters for a long time since C-H-S addressing has been abstract forever and C-H-S values no longer determine exactly where on the disk a block of data resides. I believe it would be kinda stupid if they didn't stripe contiguous data, interleaved across multiple platters.

Can anyone confirm if there's some reason HDD manufacturers would not?

 

[thecoolnessrune]

Do you have a source for how to configure tiered storage in Windows 10?

When I built a Storage Spaces test environment on Windows 10 Pro, I actually followed the TechNet article for 2012 R2: https://blogs.technet.microsoft.com...age-spaces-tiering-in-windows-server-2012-r2/

Worked without issue for me!

Of course, nowadays, if you have the resources, you can install a copy of Server 2012 R2 on a spare drive, configure your Storage Spaces in their GUI (you still might have to manually set the MediaType flags via PowerShell, since many consumer SSDs don't get read properly as SSD's by Storage Spaces), and then import the Storage Spaces into Windows 10.

 

[master_shake_]

I've also been saying traditional mechanical HDD manufacturers could have been doing "literally like internal RAID-0" across platters for a long time since C-H-S addressing has been abstract forever and C-H-S values no longer determine exactly where on the disk a block of data resides. I believe it would be kinda stupid if they didn't stripe contiguous data, interleaved across multiple platters.

Can anyone confirm if there's some reason HDD manufacturers would not?

you ever run a raid array and then lose power?

most raid cards have a cache and a battery backup unit, if you lose power in the middle of a write your data sits on the cache and waits top be written.

if you don't have a battery back unit your data disappears. and in a RAID 0 you can't recover from that.

so every drive would need some kind of battery/capacitor unit (like ssds have) to save the data from being cleared from the cache in case power goes out.

that increases costs and does very little in terms of performance and at the same time decreases reliability.

so that is why it is a bad idea.

you're probably thinking well hard drives already have a cache, they do but without a write back cache the speeds are dismal.

 

[Ichinisan]

you ever run a raid array and then lose power?

I fail to see the relevance. You ever write to a single hard drive and lose power? Yes. Sometimes data gets corrupted.

I'm talking about how the drive optimizes where to place data on its own platters. Optimally, it would fill the faster-spinning outer areas of each platter first. Taking more time to finish a write operation would certainly increase the likelihood of data corruption from power loss! It wouldn't make sense to have contiguous data fill a single side of a single platter before it starts filling the next one.

most raid cards have a cache and a battery backup unit, if you lose power in the middle of a write your data sits on the cache and waits top be written.

if you don't have a battery back unit your data disappears. and in a RAID 0 you can't recover from that.

Relevance? Talking about utilization of the multiple platters inside a single drive.

so every drive would need some kind of battery/capacitor unit (like ssds have) to save the data from being cleared from the cache in case power goes out.

Are you saying HDDs don't have read/write cache? If so, that's absolutely incorrect.

that increases costs and does very little in terms of performance and at the same time decreases reliability.

so that is why it is a bad idea.

R/W performance is HUGELY impacted by the capacity of HDD cache! It means the heads don't have to thrash as much. Command queueing is part of AHCI before SSDs were really a thing.

you're probably thinking well hard drives already have a cache, they do but without a write back cache the speeds are dismal.

They use the cache for both reads and writes.

 

[master_shake_]

I fail to see the relevance. You ever write to a single hard drive and lose power? Yes. Sometimes data gets corrupted.

I'm talking about how the drive optimizes where to place data on its own platters. Optimally, it would fill the faster-spinning outer areas of each platter first. Taking more time to finish a write operation would certainly increase the likelihood of data corruption from power loss! It wouldn't make sense to have contiguous data fill a single side of a single platter before it starts filling the next one.


Relevance? Taking about utilization of the multiple platters inside a single drive.


Are you saying HDDs don't have read/write cache? If so, that's absolutely incorrect.


R/W performance is HUGELY impacted by the capacity of HDD cache! It means the bass don't have to trash as much. Command queueing is part of AHCI before SSDs were really a thing.


They use the cache for both reads and writes.

they have a read cache not write.

your whole premise is basically stupid.

the heads don't move independently there goes your speed boost. that's it, that whole dream ids dead. move on.

caching with a 16gb amount of flash is better than raid inside a hard drive.

that's why seagate does it.

 

[Ichinisan]

they have a read cache not write.

You sure about that?

your whole premise is basically stupid.

the heads don't move independently there goes your speed boost. that's it, that whole dream ids dead. move on.

"the heads don't move independently" is the entire reason for storing blocks of logically-contiguous data above and below each other on multiple platters would help with performance and reduce seek/thrashing.

caching with a 16gb amount of flash is better than raid inside a hard drive.

that's why seagate does it.

Certainly. I'm talking about something I assume to be common practice in traditional mechanical HDDs -- since long before SSDs became practical
This would be a complementary technique, even when used with a hybrid SSD cache. One does not replace the other and they certainly wouldn't compete. Whether it's the system or the caching controller accessing the drive, any time something needs to be moved to-or-from the platters, it would make sense to structure the data so logically-contiguous data is spread vertically through multiple platters/sides to reduce seeking distance across the disk surface. I see no reason why it shouldn't store blocks in such an arrangement for optimal efficiency.

Also, DRAM as a buffer is not at all the same as an SSD cache. Again, they can be complementary to each other. DRAM writes more quickly and doesn't wear out from r/w cycles. I don't read much about SSDs, but I'd bet many of them still have a DRAM buffer.

 

[VirtualLarry]

Can anyone confirm if there's some reason HDD manufacturers would not?

Yeah, the tolerances are too tight to do that, and the signal processing issue of having every head enabled simultaneously would be too big a challenge, I guess.

Suffice to say, modern HDDs do not work the way that you are suggesting.

Edit: As "proof", I offer the fact that sequential read/write speeds go UP, when platter count (at the same drive capacity) DECREASES. If it were done the way that you suggested, then performance should be higher, with higher platter counts, for higher parallelism. The fact that that is not true, suggests that your theory is not true.

 

[cbn]

HDD achilles heel is random access, especially when many seeks are involved (like with small files). The Cache can make a measurable improvement on that. It's nothing amazing, but then again, a 1TB SSHD is a heck of a lot less money than a 1TB SSD, and an SSHD costs very little more compared to an HDD.

I wonder how a $100 2TB 3.5" SSHD (which has 8GB MLC) compares to two $50 1TB 3.5" HDDs in RAID-0? (re: RAID-0 increases IOPs in addition to Sequential Read and Write).

If the RAID-0 wins in the 3.5" category, how about 2.5" SSHD (with 8GB MLC) vs. 2.5" HDDs in RAID-0?

 

[Ichinisan]

Yeah, the tolerances are too tight to do that, and the signal processing issue of having every head enabled simultaneously would be too big a challenge, I guess.

Suffice to say, modern HDDs do not work the way that you are suggesting.

Edit: As "proof", I offer the fact that sequential read/write speeds go UP, when platter count (at the same drive capacity) DECREASES. If it were done the way that you suggested, then performance should be higher, with higher platter counts, for higher parallelism. The fact that that is not true, suggests that your theory is not true.

Thanks, although the reason sequential r/w gets faster with fewer platters is because the data is more densely packed while rotational speed remains the same.

 

[thecoolnessrune]

I wonder how a $100 2TB 3.5" SSHD (which has 8GB MLC) compares to two $50 1TB 3.5" HDDs in RAID-0? (re: RAID-0 increases IOPs in addition to Sequential Read and Write).

If the RAID-0 wins in the 3.5" category, how about 2.5" SSHD (with 8GB MLC) vs. 2.5" HDDs in RAID-0?

It would depend very heavily on your workload. RAID-0 increases your IOPS, but it doesn't help you with your latency. Additionally, if your recurring dataset is small (and again, you can fit a lot of small files in 6 or so GB), then the IOPS assist of that cash will still be an order of magnitude greater than a striped array. But data reads / writes will be faster on the striped array initially because without the cache, an SSHD is just an HDD.

But again, if your file transfers are mostly large sequential datasets, or you don't access the same data sets often, SSHD will be of little benefit.

With the price difference being roughly $30 between a 1TB SSHD and a 1TB HDD (though there's also a much pricier $175 1TB SSHD with 4x the NAND), I'd say it's a small cost to add the boost. If you could deal with the extra room, and much higher failure probabilities, RAID-0 would probably be a decent idea if you work with ever-changing data.

I'd say most home users though would find better performance from an SSHD. When you count key Windows boot files, and then some common startup apps (Browser, small games, etc.), the boost from the NAND would likely be greater than the more consistent, but much slower spinning rust.

 

[cbn]

It would depend very heavily on your workload. RAID-0 increases your IOPS, but it doesn't help you with your latency. Additionally, if your recurring dataset is small (and again, you can fit a lot of small files in 6 or so GB), then the IOPS assist of that cash will still be an order of magnitude greater than a striped array. But data reads / writes will be faster on the striped array initially because without the cache, an SSHD is just an HDD.

I agree the latency would be much less on the SSHD (on files that are cached)....and thanks for the info on the IOPs.

At some point I will probably pick up a FireCUDA 3.5" to try out. However, In my experience the general performance of two modern 3.5" 7200 rpm hard drives in RAID-0 for OS/basic tasks is actually quite impressive. To be honest I wasn't really missing my 240GB PNY CS2211 SSD.

 

[cbn]

Intel releases Optane M.2 cache drives:

http://www.anandtech.com/show/11227/intel-launches-optane-memory-m2-cache-ssds-for-client-market

Notice the drive cannot be used to cache secondary storage (only the primary storage device). Also it must be used with a 200 Series chipset (not 100 Series).

So yeah, it makes me wonder why these aren't in SSHDs?