I just changed my work video editing workstation order. I will have two 970 EVO NVMe for my OS and Project drives. There actually is a bottle next with raw 4K, 5K and 8K Video and playing it in an editor.
I searched through the article and didn't see much discussion at all on storage as a bottleneck. If it actually is a bottleneck, is color grading more of a sequential or random data access workload?
It doesn't seem like the 970 Evo is much faster than the 960 Evo.
They're still faster than all of the competition (aside from super-expensive Intel Optane). So its not a big deal. But there are some reviews that show the 960 Evo winning some performance tests out there.
Your terminology is slightly off, so I'm not entirely sure what you mean. M.2 is a form-factor, which can be NVMe (PCIe-based) or SATA-based. Yeah, a bit confusing but M.2 supports two different protocols.
If you mean RAID0 SATA drives (in the M.2 form factor), well the processor's south-bridge has a lower limit compared to the direct-to-CPU connections most NVMe drives get.
SATA is great for bulk storage: either cheaper SSDs (~$250 for 1TB for MX500) or big hard drives (~5TB Toshiba Hard Drives for $150). But for maximum performance, you have to go NVMe.
After all, RAID0 NVMe drives will simply perform better than RAID0 SATA.
---------------------
Case in point: the Samsung 970 Evo has a specified read bandwidth of 3700 MB/s.
The SATA3 connector has a maximum speed of 600MB/s theoretical (and in practice, SSDs only achieve ~550 MB/s). So you'll need SIX RAID0 SATA drives to keep up with this single Samsung 970 Evo. Assuming your southbridge can even sustain 6x RAID0 (probably not. In my experience, south-bridges seem to slow down dramatically by 3x RAID0).
All you need to do with the 970 Evo is go RAID0 2x 970 Evo to achieve performance that no SATA RAID array will ever touch.
I am aware of the distinctions, I thought it would be obvious from the context.
I meant to compare a 2x m.2 NVMe RAID0 with dedicated NVMe add-in cards, e.g. a kingston dcp1000. The latter can outperform the former per unit but seem more expensive even when you adjust for the higher stats.
M.2 NVMe drives are electrically PCIe 3.0 x4 lanes. Since laptops are such a popular form factor, it seems like all the best technology and mass-production is favoring M.2 drives. Its clear to me that older physical PCIe drives are just going obsolete in terms of price/performance now.
PCIe drives (the ones that physically went into a x4, x8, or x16 slot) are a dinosaur at this point. It seems like the "serious" datacenter technology is converging upon U.2 drives (which are also PCIe 3.0 x4 slots, except over a cable).
Its been a bit rocky these past few years: Sata-Express (2x PCIe), U.2, M.2 SATA, M.2 NVMe, and "physical PCIe" SSDs. But the industry is finally converging into something of a standard.
M.2 NVMe is the high-performance part for consumers, especially the laptop market. While U.2 for servers who need large capacity and benefit from the physical presence of a wire connection.
Took me a bit to understand what you are saying. The 3700 mb read is what I am intrested in exactly.
I really think we are going to have some foundamental change in chip design to make 5K video and 8K (For commercial video it will be 15-20 years until 8K will be common in personal use.
I really wish there was a little more effort put into this "article", the 970 PRO and EVO spec tables aren't very useful. They would be a lot more helpful if they included the 960 versions for direct comparison or even if they were side by side so the EVO and PRO could be directly compared.
The Anandtech review says it's nickel plated. The sticker is also a copper heat spreader:
"The Samsung Phoenix controller introduces a nickel-coated heatspreader, and the 970 EVO retains the copper foil layer in the label on the back of the drive that was introduced with the 960 generation, but there are no more serious cooling measures on the drive."
I have no idea whether Samsung uses it, but the NVMe spec allows a device to request use of host memory for caching. It’s considered a low-end feature, since it’s slow and inherently volatile. It’s called “host memory buffer” for those who are curious.
I think the bigger issues are bandwidth and power consumption. If software is doing heavy IO, it doesn’t really want to have to contend with the HMB for PCIe and memory bandwidth.
Also, a DRAM chip is a DRAM chip. I’d rather pay a couple dollars for a local DRAM chip in the NVMe device than a couple dollars for extra host RAM that will be permanently reserved for the HMB.
The heavy IO case is addressed by write-back characteristic of block devices. In the end, the cache is in host RAM regardless of the underlying device type.
I think you may be misunderstanding the issue. A flash controller that tries to look like a block device needs to manage a mapping between logical and physical blocks along with various other pieces of metadata. The on-flash representation needs to be structured in a flash-friendly way, which often means that it’s not efficient to find the metadata needed to process an IO request unless that metadata is cached in memory.
On an HMB device, the metadata will be cached in host memory, which will likely adversely affect performance and power efficiency.
Do these drives feature power-loss capacitors? I'm still wondering why most manufacturers think it's okay to offer SSDs that lose data on power loss (!!)
I really wonder why a $10 capacitor add-on (a capacitor, a diode, two connectors) plugged in between main board power supply and a disk power receptacle is not a common item.
A common minimum voltage requirement for the nominal +5V supply is 4.5 V. Let's assume a voltage below that won't damage the drive, but it won't operate.
The diode is going to drop 0.6V, leaving you with only 4.4 V max for the drive. Then the capacitor is going to immediately start dropping in voltage as soon as you start pulling the stored energy out of it.
So, in practice, to do a quality job of this it will probably need a DC-DC converter. These aren't necessarily expensive, but definitely more complicated than the old diode trick.
This makes sense! OTOH low-drop diodes do exist [1], and the drive likely needs just a (small) fraction of a second to flush the caches; it's SSD, not need to wait for the disk to rotate to the right position or move heads. I suppose the power loss signal from the controller still propagates, even if the computer's PSU plug is just yanked out of socket.
The caches on some SSD's can be multiple gigabytes.
They also frequently cache data which can be difficult (slow) to write, for example a single modified 4kb page which is part of a large unmodified area. Completing that write would involve reading the original data, erasing the entire erase-block, and rewriting the new data.
SSD's with built in power loss prevention typically reserve an area on the SSD which is pre-erased ready to dump the contents of the cache into. Then on powerup, they reload the cache and properly flush the data to the actual place it's supposed to be.
I worked on SSD power loss implementation in the past. You also need a signal into the controller indicating power failed. At this point the controller will minimally stop all less critical tasks, prioritize the buffered user data to be written and make sure the FFS is in consistent state for recovery.
Desktop power supplies already have that, they can keep the power on for 50-100 ms or so, and they do notify the OS about the imminent power loss. I'm not sure what OSes do with that.
ATX power supplies have a PWR_OK pin, which goes low when power is lost.
Most motherboards don't report that to the OS though, instead they simply reset all the hardware.
To be fair, it's probably preferable to reset stuff than to operate when the power supply isn't healthy, since that will lead to a lot of weird undefined behaviour.
> Right now, there is only one reliable SSD manufacturer: Intel.
Indeed I find it very hard to figure out for other vendors whether they have power loss protection or not.
Intel makes this easy to check: Each drive has a YES/NO for "Enhanced Power Loss Data Protection" which is described as
> ... prepares the SSD for unexpected system power loss by minimizing data in transition in temporary buffers, and uses on-board power-loss protection capacitance to provide enough energy for the SSD firmware to move data from the transfer buffer and other temporary buffers to the NAND, thus protecting system and user data.
They also have a list showing all Intel SSDs that have this feature:
So what happens when you have "power-loss capacitors"? Since these things are limited the drive races to empty its buffers onto the SSD and then shuts down. It does not ask the host "are you done writing", so now instead you lose whatever the host had in its buffers. The host is gone anyway when the drive loses power.
No. Data loss protection needs to be built into the software itself, fixing that on the SSD level doesn't make a lot of sense. If anything, you install a UPS, and then of course you don't need to pay extra for SSD capacitors because the whole system keeps running through power loss and shuts down gracefully.
Power-loss capacitors are needed because without them, flush commands issued by the OS return bogus values. Write confirmations are meaningless if the data isn't actually written to disk.
Doesn't software like databases that care about this already assume the OS flush return values are bogus?
And it still doesn't solve the problem of the host buffers disappearing. What's the scenario, the host experiences a power-loss, but was somehow anticipating it and managed to stop writing to the SSD?
> Doesn't software like databases that care about this already assume the OS flush return values are bogus?
Unsure of this (I would assume "it depends" and "probably not" because how else could it possibly know that anything is written to durable storage ever ever) but the idea is that if it didn't have to assume that life would be a lot easier.
> What's the scenario, the host experiences a power-loss, but was somehow anticipating it and managed to stop writing to the SSD?
If I understood your question correctly, databases and similar stuff write data in a way to try to solve exactly this problem, with write-ahead logs and such where you first write quickly and inexpensively to the log and then write to the database.
>Doesn't software like databases that care about this already assume the OS flush return values are bogus?
The best a database can do is prevent corruption. It cannot magically prevent data loss of writes that have never reached the platter or NAND.
>And it still doesn't solve the problem of the host buffers disappearing. What's the scenario, the host experiences a power-loss, but was somehow anticipating it and managed to stop writing to the SSD?
You solve the problem of host buffers disappearing by using fsync. The scenario is that fsync works correctly on powerloss.
Imagine you build an app consisting of 3 microservices. They are called Human, CPU and Disk.
The human sends a request via a website to the CPU. The CPU wants to save the host buffer in a database and sends a fsync request to the Disk. The Disk sends an "OK" response immediately but actually saves the data in the background. The CPU sends an "OK" response to the human. Everything is fine. Suddenly powerloss happens and the disk cannot save the data in time. The database is smart, it knows how to reconstruct some of the data until the point where the transaction log has been cut off. Beyond that though the data is gone and the "OK" sent to the Human is no longer valid.
Now imagine the same scenario with correct fsync. The CPU waits for the Disk and during a powerloss not only is the disk dead but the CPU is dead too and it therefore cannot send an "OK" response to the Human.
What if you don't use fsync? What if you pipe your data to /dev/null? Well, here is the tough news: Nobody can help you. If you don't write data to disk then it's gone.
It's actually even worse than this, in that long-ago written data could be in the process of being refreshed/remapped when power is lost. The drive's software should be designed to work atomically to prevent this, but that's a whole lot of edge testing we're hoping a company will do on its closed software.
Which is why things like cheap SD cards are notoriously unreliable, whereas Samsung SSDs are seen as decently reliable. What we really want is to get rid of these controller layers and let the OS directly manage the flash. But top of the line manufacturers are incentivized to decommodify their products to increase margins, and price-competitive manufacturers are inclined to stick to the same interface.
The buffers maintained by the OS and drive are totally different, the entire point of having huge buffers in the device is so that it can agglomerate and reorder otherwise totally unrelated writes into flash banks it is presently convenient to write to.
When the OS flushes stuff to the device, it is done such that metadata writes reach the disk in an order that ensures a recoverable filesystem image on power failure. If the device does not preserve that ordering all bets are off. The mapping that goes on inside a SSD is of sufficient complexity that it's much easier to simply guarantee the device has enough independent power to ensure all acknowledged writes are persisted after acknowledgement, and that means capacitors, or best case, data (e.g. committed, acked DB transactions) that magically disappear during a power loss event.
You cannot have a device that temporarily writes to RAM and tells the host computer "OK that's on disk now" (i.e. every SSD in existence with a throughput exceeding a few MB/sec) be reliable without an independent source of power to ensure that RAM reaches flash in every situation
SD cards are the same. Many cards you can unplug from the host, only to find something that successfully fsync()'ed actually wasn't persisted to the underlying storage.
I've worked on PLP implementations in the past. Mostly it was the added cost of capacitors. Also things like laptops don't really need them since they have batteries and will shut down gracefully when battery is running low.
The capacitors needs to be reliable, small form factor and hold enough charge to keep the controller, DRAM and NAND powered for a minimum of 15-30ms. 10 years ago what was available was not so great but now the options are much better.
I personally use the Samsung PRO SSDs myself these days. I don't go with the latest models because the older NAND technology tends to be more reliable. Also you want a company with many product cycles so that the firmware has time to mature. Just too many edge cases in SSD firmware to catch them in one go.
Well, speaking of firmware, the current state of Samsung's SSD firmware is incredibly poor.
I jumped ship from SATAs to M.2 a month ago with a new computer and to quickly sum up the situation with Samsung 960 Pro from own experience and hundred page long threads on official product forum:
- last published firmware on website is 2 (don't know the long number now, writing from phone)
- a version 3 was released, system freezing started occurring in some cases and some people even ended up with bricked drives (in relation to eDrive IIRC)
- bricked drives could be reportedly used again after PSID revert, but Samsung consistently refuses to release the tool (other manufacturers do and the tool is also useful for recovering drive with lost OPAL password)
- firmware 4 reportedly exists, which can be obtained through Magician (Samsung's tool for SSD) and should solve problems from version 3. Conflicting reports on performance.
The craziest stuff is that:
- Magician will now tell you there is a new firmware for your drive, but it won't tell you with which version is it going to "enrich" your shiny new drive. Will I get 3? Or 4? Especially when only 2 is posted on the Samsung's page!
- firmware changelogs are kept secred, just install this for no reason
- no downgrades are possible
Worse than X25-M password bug. You have to be scavenging official forums for information that should be posted with the firmware and be cursing at/begging moderators to reveal some more. Ah and reportedly there is some mysterious incompatibility with major BIOS vendors in regard to eDrive. No, they won't tell what the bug is, nor on what boards.
Also, custom OPAL PBAs (image flashed to special unlocked area on disk for booting with disk locked down) don't boot in current desktop boards. Might be non-Samsung issue, maybe the one mentioned above.
I guess Samsung is just not at their top of their game in terms of pushing differentiated product lines for their M.2 SSDs. Perhaps (or perhaps not) they should learn from Taiwanese companies. They would jump on this opportunity to sell a premium edition for lots of extra margin profit.
Have a look at this wonderful marketing page for a Gigabyte Z370 motherboard:
No, and for numerous reasons. Capacitors are relatively large and bulky. The specifications for SSD size doesn't leave a lot of room, and the type of surface mount electrostatic capacitors which would be needed are both expensive and take up a lot of space.
Even in the enterprise market, M2 form factor SSDs rarely have these capacitors, because they don't really help. They are more common on PCIE-card devices.
The on-disk/flash format that these drives use has a journaling system much like modern filesystems do, so they know if blocks were not fully written. This feature alone almost completely negates any need for
I have committed patches and code to UBIFS and I am very familiar with how modern flash filesystems work at the hardware level. Backup caps are just not really needed.
PS: The double exclamation point and whiney-blamey statement really added to your immature hyperbolicity.
On an only sort-of related note, has anyone found a USB (or anything else external) adapter that can read these yet?
I know why it's hard, and I know about the ones that read that form factor but not NVMe drives, and why that is. Just curious if my searches are coming up dry because they don't exist or because they're getting flooded by the results that match the search but don't work.
I enjoy the performance of the drive I have but it makes me nervous that the only thing in my house that can read it is the laptop it is in. If push came to shove I could create some options, but the best would be a stand-alone reader, like you can get for basically every other kind of storage tech.
I've used the one made by startech, $30 on Amazon. Speed is always going to be limited, but they do work. I've used it only for general IT work doing data transfer, backups or upgrades where the host system didn't work or support multiple M.2 connections.
As another user stated Startech makes one and I use it as a technician. It's not fast at all... it's mainly for recovery when you don't have a motherboard with an available M.2 slot you can still pull the data off it.
For that purpose it does the trick. The drive is capable of speeds 100x above USB 3.0 so there really isn't good to use that bus for anything other than emergency.
Does anyone have a link? I'm still only pulling up results that either the description says they don't work with this type of drive, or the answered questions say they don't.
AFAIK, a decent proxy is "Does it work with the Samsung 950 pro?", which has been out long enough to be in the answers section for most of these things. These new drives won't be. (And I've got a Toshiba, but it's the same basic tech.)
There are Thunderbolt 3 external SSDs that have an M.2 NVME SSD inside. You could probably open them up and swap your own SSD in. Bare enclosures without an included SSD appear to be less common.
67 comments
[ 3.2 ms ] story [ 135 ms ] threadThe issue is after you have done a few processes on the video for color balance and grade things can just grind to a halt.
They're still faster than all of the competition (aside from super-expensive Intel Optane). So its not a big deal. But there are some reviews that show the 960 Evo winning some performance tests out there.
If you mean RAID0 SATA drives (in the M.2 form factor), well the processor's south-bridge has a lower limit compared to the direct-to-CPU connections most NVMe drives get.
SATA is great for bulk storage: either cheaper SSDs (~$250 for 1TB for MX500) or big hard drives (~5TB Toshiba Hard Drives for $150). But for maximum performance, you have to go NVMe.
After all, RAID0 NVMe drives will simply perform better than RAID0 SATA.
---------------------
Case in point: the Samsung 970 Evo has a specified read bandwidth of 3700 MB/s.
The SATA3 connector has a maximum speed of 600MB/s theoretical (and in practice, SSDs only achieve ~550 MB/s). So you'll need SIX RAID0 SATA drives to keep up with this single Samsung 970 Evo. Assuming your southbridge can even sustain 6x RAID0 (probably not. In my experience, south-bridges seem to slow down dramatically by 3x RAID0).
All you need to do with the 970 Evo is go RAID0 2x 970 Evo to achieve performance that no SATA RAID array will ever touch.
I meant to compare a 2x m.2 NVMe RAID0 with dedicated NVMe add-in cards, e.g. a kingston dcp1000. The latter can outperform the former per unit but seem more expensive even when you adjust for the higher stats.
M.2 NVMe drives are electrically PCIe 3.0 x4 lanes. Since laptops are such a popular form factor, it seems like all the best technology and mass-production is favoring M.2 drives. Its clear to me that older physical PCIe drives are just going obsolete in terms of price/performance now.
PCIe drives (the ones that physically went into a x4, x8, or x16 slot) are a dinosaur at this point. It seems like the "serious" datacenter technology is converging upon U.2 drives (which are also PCIe 3.0 x4 slots, except over a cable).
Its been a bit rocky these past few years: Sata-Express (2x PCIe), U.2, M.2 SATA, M.2 NVMe, and "physical PCIe" SSDs. But the industry is finally converging into something of a standard.
M.2 NVMe is the high-performance part for consumers, especially the laptop market. While U.2 for servers who need large capacity and benefit from the physical presence of a wire connection.
I really think we are going to have some foundamental change in chip design to make 5K video and 8K (For commercial video it will be 15-20 years until 8K will be common in personal use.
A new trend it seems?
"The Samsung Phoenix controller introduces a nickel-coated heatspreader, and the 970 EVO retains the copper foil layer in the label on the back of the drive that was introduced with the 960 generation, but there are no more serious cooling measures on the drive."
Also, a DRAM chip is a DRAM chip. I’d rather pay a couple dollars for a local DRAM chip in the NVMe device than a couple dollars for extra host RAM that will be permanently reserved for the HMB.
On an HMB device, the metadata will be cached in host memory, which will likely adversely affect performance and power efficiency.
@dang maybe change the link as the review is a superset of the announcement.
[0] https://www.anandtech.com/show/12670/the-samsung-970-evo-ssd...
(It's best to email hn@ycombinator.com to tell us things, though — I only saw this by accident.)
Or maybe it is, but I have no idea?
The diode is going to drop 0.6V, leaving you with only 4.4 V max for the drive. Then the capacitor is going to immediately start dropping in voltage as soon as you start pulling the stored energy out of it.
So, in practice, to do a quality job of this it will probably need a DC-DC converter. These aren't necessarily expensive, but definitely more complicated than the old diode trick.
[1]: https://electronics.stackexchange.com/a/282471/9909
[1]https://www.maximintegrated.com/en/products/analog/amplifier...
They also frequently cache data which can be difficult (slow) to write, for example a single modified 4kb page which is part of a large unmodified area. Completing that write would involve reading the original data, erasing the entire erase-block, and rewriting the new data.
SSD's with built in power loss prevention typically reserve an area on the SSD which is pre-erased ready to dump the contents of the cache into. Then on powerup, they reload the cache and properly flush the data to the actual place it's supposed to be.
Most motherboards don't report that to the OS though, instead they simply reset all the hardware.
To be fair, it's probably preferable to reset stuff than to operate when the power supply isn't healthy, since that will lead to a lot of weird undefined behaviour.
http://lkcl.net/reports/ssd_analysis.html
> Right now, there is only one reliable SSD manufacturer: Intel.
Indeed I find it very hard to figure out for other vendors whether they have power loss protection or not.
Intel makes this easy to check: Each drive has a YES/NO for "Enhanced Power Loss Data Protection" which is described as
> ... prepares the SSD for unexpected system power loss by minimizing data in transition in temporary buffers, and uses on-board power-loss protection capacitance to provide enough energy for the SSD firmware to move data from the transfer buffer and other temporary buffers to the NAND, thus protecting system and user data.
They also have a list showing all Intel SSDs that have this feature:
https://ark.intel.com/Search/FeatureFilter?productType=solid...
Would be nice if other vendors had that too.
No. Data loss protection needs to be built into the software itself, fixing that on the SSD level doesn't make a lot of sense. If anything, you install a UPS, and then of course you don't need to pay extra for SSD capacitors because the whole system keeps running through power loss and shuts down gracefully.
And it still doesn't solve the problem of the host buffers disappearing. What's the scenario, the host experiences a power-loss, but was somehow anticipating it and managed to stop writing to the SSD?
Unsure of this (I would assume "it depends" and "probably not" because how else could it possibly know that anything is written to durable storage ever ever) but the idea is that if it didn't have to assume that life would be a lot easier.
> What's the scenario, the host experiences a power-loss, but was somehow anticipating it and managed to stop writing to the SSD?
If I understood your question correctly, databases and similar stuff write data in a way to try to solve exactly this problem, with write-ahead logs and such where you first write quickly and inexpensively to the log and then write to the database.
The best a database can do is prevent corruption. It cannot magically prevent data loss of writes that have never reached the platter or NAND.
>And it still doesn't solve the problem of the host buffers disappearing. What's the scenario, the host experiences a power-loss, but was somehow anticipating it and managed to stop writing to the SSD?
You solve the problem of host buffers disappearing by using fsync. The scenario is that fsync works correctly on powerloss.
Imagine you build an app consisting of 3 microservices. They are called Human, CPU and Disk.
The human sends a request via a website to the CPU. The CPU wants to save the host buffer in a database and sends a fsync request to the Disk. The Disk sends an "OK" response immediately but actually saves the data in the background. The CPU sends an "OK" response to the human. Everything is fine. Suddenly powerloss happens and the disk cannot save the data in time. The database is smart, it knows how to reconstruct some of the data until the point where the transaction log has been cut off. Beyond that though the data is gone and the "OK" sent to the Human is no longer valid.
Now imagine the same scenario with correct fsync. The CPU waits for the Disk and during a powerloss not only is the disk dead but the CPU is dead too and it therefore cannot send an "OK" response to the Human.
What if you don't use fsync? What if you pipe your data to /dev/null? Well, here is the tough news: Nobody can help you. If you don't write data to disk then it's gone.
Which is why things like cheap SD cards are notoriously unreliable, whereas Samsung SSDs are seen as decently reliable. What we really want is to get rid of these controller layers and let the OS directly manage the flash. But top of the line manufacturers are incentivized to decommodify their products to increase margins, and price-competitive manufacturers are inclined to stick to the same interface.
When the OS flushes stuff to the device, it is done such that metadata writes reach the disk in an order that ensures a recoverable filesystem image on power failure. If the device does not preserve that ordering all bets are off. The mapping that goes on inside a SSD is of sufficient complexity that it's much easier to simply guarantee the device has enough independent power to ensure all acknowledged writes are persisted after acknowledgement, and that means capacitors, or best case, data (e.g. committed, acked DB transactions) that magically disappear during a power loss event.
You cannot have a device that temporarily writes to RAM and tells the host computer "OK that's on disk now" (i.e. every SSD in existence with a throughput exceeding a few MB/sec) be reliable without an independent source of power to ensure that RAM reaches flash in every situation
The capacitors needs to be reliable, small form factor and hold enough charge to keep the controller, DRAM and NAND powered for a minimum of 15-30ms. 10 years ago what was available was not so great but now the options are much better.
I jumped ship from SATAs to M.2 a month ago with a new computer and to quickly sum up the situation with Samsung 960 Pro from own experience and hundred page long threads on official product forum:
- last published firmware on website is 2 (don't know the long number now, writing from phone)
- a version 3 was released, system freezing started occurring in some cases and some people even ended up with bricked drives (in relation to eDrive IIRC)
- bricked drives could be reportedly used again after PSID revert, but Samsung consistently refuses to release the tool (other manufacturers do and the tool is also useful for recovering drive with lost OPAL password)
- firmware 4 reportedly exists, which can be obtained through Magician (Samsung's tool for SSD) and should solve problems from version 3. Conflicting reports on performance.
The craziest stuff is that:
- Magician will now tell you there is a new firmware for your drive, but it won't tell you with which version is it going to "enrich" your shiny new drive. Will I get 3? Or 4? Especially when only 2 is posted on the Samsung's page!
- firmware changelogs are kept secred, just install this for no reason
- no downgrades are possible
Worse than X25-M password bug. You have to be scavenging official forums for information that should be posted with the firmware and be cursing at/begging moderators to reveal some more. Ah and reportedly there is some mysterious incompatibility with major BIOS vendors in regard to eDrive. No, they won't tell what the bug is, nor on what boards.
Also, custom OPAL PBAs (image flashed to special unlocked area on disk for booting with disk locked down) don't boot in current desktop boards. Might be non-Samsung issue, maybe the one mentioned above.
How does this stuff work together at all?
Have a look at this wonderful marketing page for a Gigabyte Z370 motherboard:
https://www.gigabyte.com/us/Motherboard/Z370-AORUS-Gaming-7-...
It's the most over-the-top glorious thing I've ever seen. Make sure you expand a couple of the sections.
Even in the enterprise market, M2 form factor SSDs rarely have these capacitors, because they don't really help. They are more common on PCIE-card devices.
The on-disk/flash format that these drives use has a journaling system much like modern filesystems do, so they know if blocks were not fully written. This feature alone almost completely negates any need for
I have committed patches and code to UBIFS and I am very familiar with how modern flash filesystems work at the hardware level. Backup caps are just not really needed.
PS: The double exclamation point and whiney-blamey statement really added to your immature hyperbolicity.
I know why it's hard, and I know about the ones that read that form factor but not NVMe drives, and why that is. Just curious if my searches are coming up dry because they don't exist or because they're getting flooded by the results that match the search but don't work.
I enjoy the performance of the drive I have but it makes me nervous that the only thing in my house that can read it is the laptop it is in. If push came to shove I could create some options, but the best would be a stand-alone reader, like you can get for basically every other kind of storage tech.
For that purpose it does the trick. The drive is capable of speeds 100x above USB 3.0 so there really isn't good to use that bus for anything other than emergency.
- Here is an image of the circuit it uses (ASM1163E Controller) https://i.imgur.com/ZmwppR4.jpg
- I can't find that IC anywhere but here's the closest thing: http://images.100y.com.tw/pdf_file/35-Asmedia-ASM1042A.pdf
PCI-E to USB 3.0 host bridge. Hopefully that helps.
AFAIK, a decent proxy is "Does it work with the Samsung 950 pro?", which has been out long enough to be in the answers section for most of these things. These new drives won't be. (And I've got a Toshiba, but it's the same basic tech.)
> PCI-E to USB 3.0 host bridge
Close, but this is the other direction, from PCI to USB.
- Netstor enclosure with 2xM.2 NVME slots and Thunderbolt 3 daisy chaining, no SSD included ($360): https://www.tomshardware.com/reviews/netstor-na611tb3-thunde...
- LaCie Bolt^3, similar features as above but with 2x1TB SSDs ($2000): https://www.anandtech.com/show/10801/lacie-announces-bolt3-2...
- Plugable 480GB Thunderbolt 3 SSD ($400): https://www.tweaktown.com/reviews/8514/plugable-thunderbolt-...
- Patriot EVLVR Thunderbolt 3 SSD, 256GB ($200): https://www.anandtech.com/show/12257/patriot-announces-evlvr...