4 ms·

Name the offenders please. I am sure it might be easy to see visually - a lack of substantial capacitor on the board would indicate a high likelihood of data l

Name the offenders please. I am sure it might be easy to see visually - a lack of substantial capacitor on the board would indicate a high likelihood of data loss.

whitepoplar 3y ago
SK Hynix and Sabrent: https://x.com/xenadu02/status/1496290369184874497?s=20 https://x.com/xenadu02/status/1496290369184874497?s=20
- java-man 3y ago
  Which did "pass" the test?
  - whitepoplar 3y ago
    https://x.com/xenadu02/status/1496765378592083968?s=20 https://x.com/xenadu02/status/1496765378592083968?s=20 https://x.com/xenadu02/status/1496770278612819968?s=20 https://x.com/xenadu02/status/1496770278612819968?s=20 https://x.com/xenadu02/status/1495875479475298324?s=20 https://x.com/xenadu02/status/1495875479475298324?s=20
    - java-man 3y ago
      ありがとう
potatopatch 3y ago
I'd be curious how well it actually correlates. It would be hard to make the most performant system that's always consistent with flushed data but there are probably a lot of firmwares out there with untested performance ideas, etc.
wmf 3y ago
None of the tested drives use power loss protection capacitors.
- 15457345234 3y ago
  We're talking about scenarios where the drives report (untruthfully) that the data has been committed to non-volatile storage _before_ the power is removed Not scenarios where the data is in the cache when the power drops and the drive is expected to write out the cache with internal power alone.
  - wmf 3y ago
    Aren't those the same scenario?
    - nomel 3y ago
      No. One is a lie. The other is an attempt at fault tolerance. The later will not claim something that isn’t true, but it will try to do what you want, as a user, as a nice gesture.
    - 15457345234 3y ago
      The second scenario is what's standard in enterprise class drives used with RAID controllers, the controller reports 'committed' to the OS and _then_ commits the data, it can do this because the path to nonvoltatile storage downstream of the controller has redundant power (the raid controller has a battery backup and the disks have their own battery backups, as well as control logic that guarantees data in the cache makes it to nonvolatile if the power drops out) The first scenario is for consumer disks, they don't report 'committed' until the data is actually committed. That makes them a whole assload slower. (Unless they lie.) Looking up the definitions of write-back vs write-thru caching will help you out here
    - mgerdts 3y ago
      From the MVMe 1.3 spec: 6.8 Flush command The Flush command shall commit data and metadata associated with the specified namespace(s) to non-volatile media. The flush applies to all commands completed prior to the submission of the Flush command.

Name the offenders please. I am sure it might be easy to see visually - a lack of substantial capacitor on the board would indicate a high likelihood of data loss.

whitepoplar 3y ago

SK Hynix and Sabrent: https://x.com/xenadu02/status/1496290369184874497?s=20 https://x.com/xenadu02/status/1496290369184874497?s=20

java-man 3y ago
Which did "pass" the test?
- whitepoplar 3y ago
  https://x.com/xenadu02/status/1496765378592083968?s=20 https://x.com/xenadu02/status/1496765378592083968?s=20 https://x.com/xenadu02/status/1496770278612819968?s=20 https://x.com/xenadu02/status/1496770278612819968?s=20 https://x.com/xenadu02/status/1495875479475298324?s=20 https://x.com/xenadu02/status/1495875479475298324?s=20
  - java-man 3y ago
    ありがとう

potatopatch 3y ago

I'd be curious how well it actually correlates. It would be hard to make the most performant system that's always consistent with flushed data but there are probably a lot of firmwares out there with untested performance ideas, etc.

wmf 3y ago

None of the tested drives use power loss protection capacitors.

15457345234 3y ago
We're talking about scenarios where the drives report (untruthfully) that the data has been committed to non-volatile storage _before_ the power is removed Not scenarios where the data is in the cache when the power drops and the drive is expected to write out the cache with internal power alone.
- wmf 3y ago
  Aren't those the same scenario?
  - nomel 3y ago
    No. One is a lie. The other is an attempt at fault tolerance. The later will not claim something that isn’t true, but it will try to do what you want, as a user, as a nice gesture.
  - 15457345234 3y ago
    The second scenario is what's standard in enterprise class drives used with RAID controllers, the controller reports 'committed' to the OS and _then_ commits the data, it can do this because the path to nonvoltatile storage downstream of the controller has redundant power (the raid controller has a battery backup and the disks have their own battery backups, as well as control logic that guarantees data in the cache makes it to nonvolatile if the power drops out) The first scenario is for consumer disks, they don't report 'committed' until the data is actually committed. That makes them a whole assload slower. (Unless they lie.) Looking up the definitions of write-back vs write-thru caching will help you out here
  - mgerdts 3y ago
    From the MVMe 1.3 spec: 6.8 Flush command The Flush command shall commit data and metadata associated with the specified namespace(s) to non-volatile media. The flush applies to all commands completed prior to the submission of the Flush command.