8x 250 GB SSD of NVME?

[C.Hariri]

Hallo,

ik ben voor een server de hardware aan het opstellen. Ik wil een zo groot mogelijke IOPS behalen, en heb daarvoor twee alternatieven:

1. 8x pricewatch: Crucial MX200 2,5" 250GB
En dan RAID10;
Capacity 1000 GB
Speed gain 8x read and 4x write speed gain
Fault tolerance At least 1-drive failure

Dus IOPS:
800.000IOPS Random Read
348.000IOPS Random Write

En er kan minimaal 1 schrijf van kapotgaan voordat ik in de problemen kom.

Prijs: 690 euro

2. 1x pricewatch: Intel 750 SSD 2,5" PCIe 3.0 x4 1,2TB
440.000IOPS Random Read
290.000IOPS Random Write

Prijs: 699 euro

En GEEN redundancy, mocht de schijf uitvallen..

Bovendien:
1. voor 1U kasten heb ik geen hotswappable NVME kunnen vinden
2. Op moederborden met 2011-3 van serverkwaliteit (intel chipset) en 1CPU socket heb ik geen NVME connector op weten te vinden.

Ik leun op dit moment dus erg naar optie 1. Wat denkt de tweakert hier van??

[Onbekend]

Zorg voor redundancy, dus minimaal RAID1. Hierdoor raad ik af om voor optie 2 te gaan.

Kijk ook eens bij de Samsung 840/850 series.
Wij hebben 16x een Samsung 840 EVO 1TB (8x RAID1) in een server zitten en na 3 jaar flink gebruik nog steeds geen problemen.

[Mel33]

Onbekend schreef op zaterdag 15 oktober 2016 @ 13:08:
Zorg voor redundancy, dus minimaal RAID1. Hierdoor raad ik af om voor optie 2 te gaan.

Kijk ook eens bij de Samsung 840/850 series.
Wij hebben 16x een Samsung 840 EVO 1TB (8x RAID1) in een server zitten en na 3 jaar flink gebruik nog steeds geen problemen.

Jinx!!

Nee idd altijd voor redundancy gaan

[dcm360]

Wellicht prijzig, maar SuperMicro heeft wel een 1U-kast met hot-swap nvme: https://www.supermicro.nl...028/SYS-1028U-TN10RT_.cfm

(of blader daar even verder, ze hebben meer opties met nvme in 1U)

[ Voor 19% gewijzigd door dcm360 op 15-10-2016 13:57 ]

[C.Hariri]

Hi, cool! bedankt voor de info. Die server zou kjunnen maar is wel helaas dual socket. Ik ga voor de 8x 250GB dan :)!

[Bjornski]

C.Hariri schreef op zaterdag 15 oktober 2016 @ 15:06:
Hi, cool! bedankt voor de info. Die server zou kjunnen maar is wel helaas dual socket. Ik ga voor de 8x 250GB dan :)!

* Bjornski vind 8 consumenten SSD's in een RAID array niet zo'n goed idee, vergeleken met een deftige NVMe oplossing

Houd er rekening mee dat je die 8x read performance niet gaat halen bij random IO.
De latency van elke SSD blijft even groot, dus als je op één SSD twee random blokken achter elkaar moet lezen, hebben die twee acties opeens maar de performance van één SSD.

Als het je om IOPS gaat kun je dus veel beter gaan voor NVMe.
Waarom niet een server met daarin twee of drie stuks pricewatch: Samsung 950 Pro 512GB?

Deze kun je in een 2.5-inch verloop stoppen zoals deze en die vervolgens in een nette Supermicro server stoppen.

Dan heb je relatief goedkope disken, hele goede performance en een hele nette server.

Er zijn trouwens denk ik genoeg Supermicro integrators die wel een server voor je kunnen samenstellen met een enkele socket en toch een paar 2.5-inch NVMe slots. Dat er geen standaardconfiguratie voor is wil niet zeggen dat het niet built to order gebouwd kan worden.

[ Voor 16% gewijzigd door Bjornski op 15-10-2016 15:19 ]

[Mel33]

*knip* spam

[ Voor 92% gewijzigd door br00ky op 16-10-2016 10:08 ]

[maratropa]

Bjornski schreef op zaterdag 15 oktober 2016 @ 15:16:
[...]
* Bjornski vind 8 consumenten SSD's in een RAID array niet zo'n goed idee, vergeleken met een deftige NVMe oplossing

Houd er rekening mee dat je die 8x read performance niet gaat halen bij random IO.
De latency van elke SSD blijft even groot, dus als je op één SSD twee random blokken achter elkaar moet lezen, hebben die twee acties opeens maar de performance van één SSD.

Als het je om IOPS gaat kun je dus veel beter gaan voor NVMe.

Nvme is natuurlijk de logischere oplossing onderhand, maar als het om toegang met een hoge qeue depth gaat dan kunnen een zooitje sata ssd's wel concurreren; ik heb toevallig 7 stuks 128GB 840 pro's in sofware raid 0 en daar zie je idd dat met een lage qeuedepth de snelheid niet boven die van 1 ssd uitkomt, maar met een hoge qeue depth er wel schaalvoordeel is;

[Wim-Bart]

Ik zou voor een Samsung gaan. Hier zit een MX al na 2 maanden op 99% lifetime terwijl een evo 950 na een jaar met 3 x zo veel data writes nog op 100% zit.

En dan spreken we over server gebruik.

[ Voor 12% gewijzigd door Wim-Bart op 15-10-2016 20:58 ]

[michiel.686]

Wim-Bart schreef op zaterdag 15 oktober 2016 @ 20:57:
Ik zou voor een Samsung gaan. Hier zit een MX al na 2 maanden op 99% lifetime terwijl een evo 950 na een jaar met 3 x zo veel data writes nog op 100% zit.

En dan spreken we over server gebruik.

De 850 evo bedoel je waarschijnlijk?

[Wim-Bart]

michiel.686 schreef op zaterdag 15 oktober 2016 @ 22:40:
[...]


De 850 evo bedoel je waarschijnlijk?

Yep die bedoel ik

[Verwijderd]

Bjornski schreef op zaterdag 15 oktober 2016 @ 15:16:
Houd er rekening mee dat je die 8x read performance niet gaat halen bij random IO.
De latency van elke SSD blijft even groot, dus als je op één SSD twee random blokken achter elkaar moet lezen, hebben die twee acties opeens maar de performance van één SSD.

Je hebt het over queue depth=1 oftewel blocking I/O.

Maar dat geldt ook bij een enkele SSD; wat ook al een RAID0 / RAID5 array is. De 4K prestaties zijn zeker een factor 10 lager dan de multiqueue 4K prestaties. Dat heeft alles met de interne RAID0 of interleaving techniek te maken. Die kan echter prestaties niet vergroten voor blocking random reads.

Voor qd=1 reads is NVMe dé manier om de prestaties te verhogen. Maar voor multiqueue is het simpelweg 'stapelen' van SSDs in een striping RAID set een makkelijke manier om eenvoudig hogere IOps te krijgen.

[Navi]

Let ook wel op dat consumenten SSD's geen volledige power loss protection hebben, bij stroomuitval kun je dus datacorruptie krijgen.

Kijk eens naar de Samsung PM863, een enterprise versie en nog steeds heel betaalbaar!

Let ook op of je raid kaart trim ondersteuning heeft.

[ Voor 11% gewijzigd door Navi op 17-10-2016 09:48 ]

[Verwijderd]

Navi schreef op maandag 17 oktober 2016 @ 09:35:
Let ook wel op dat consumenten SSD's geen volledige power loss protection hebben, bij stroomuitval kun je dus datacorruptie krijgen.

Met 'volledige' power loss protection doel je op het beschermen van de data in de DRAM? Want daar kunnen alle 2e generatie filesystems tegen; alleen als je FAT, Ext2 of UFS1 gebruikt heeft het nut de dirty buffers in DRAM te beschermen.

Consumenten SSDs als Crucial krijgen hardwarematige bescherming tegen corruptie in de vorm van capacitors die de huidige write netjes kunnen afronden.

Samsung kiest voor de goedkopere softwarematige optie, waarbij de SSD middels een journal terug in de tijd wordt gezet bij onverwacht stroomverlies. Samsung schendt hierbij de ATA standaarden; omdat na een FLUSH commando deze data permanent opgeslagen hoort te zijn. Maar dat is niet zo, want als vlak erna zich een stroomstoring voordoet, zal de journal de SSD terug in de tijd gooien vóór het FLUSH-commando. Hierdoor zijn Samsung SSDs eigenlijk totaal ongeschikt voor zaken als RAID of enige complexe opslag. Stel je voor dat SSD1 terug in de tijd gaat maar SSD2 niet, bij een RAID0 set. Ook bij redundante RAID kunnen er allerlei vreemde effecten voordoen die tot corruptie leiden. Filesystems en RAID engines zijn niet gemaakt op een tijdreizigers.

Let ook op of je raid kaart trim ondersteuning heeft.

Hardware RAID is sowieso niet de beste keus voor SSDs. Sommige hardware RAID kaarten kunnen de IOps van één SSD al niet aan. En vrijwel geeneen hardware RAID controller ondersteunt TRIM; enkel UNMAP omdat het SAS/SCSI spul is en geen ATA/AHCI.

[Navi]

Ik bedoel met volledig, dat er ook sommige SSD's zijn die een heel klein setje capacitors hebben wat power loss protection genoemd wordt, maar dat eigenlijk niet is. (zoals bv de Crucials hebben)

Bv Intel S series, (bv S3500, S3600) SSD's hebben een set grote capacitors wat echte power loss protection is.

Zie bv:
http://lkcl.net/reports/ssd_analysis.html

Ook de datacenterlijn van Samsung SSD's hebben dat wel toch? (Dit is het vorige model)
http://www.samsung.com/se...r_loss_protection_PLP.pdf

Ook bij de huidige lijn zoals de PM863 wordt het wel genoemd:
http://www.samsung.com/us...d-state-drives/MZ-7LM120E

"The PM863 is optimized for server and data center environments by offering reinforced endurance, enterprise-grade power-loss protection thanks to tantalum capacitors, low power consumption and a 3-year limited warranty."

[ Voor 11% gewijzigd door Navi op 17-10-2016 10:57 ]

[Bigs]

Ik zou altijd voor optie 2 gaan.. die goedkope consumenten SSD's gaan zich na verloop van tijd onvoorspelbaar gedragen waardoor je de theoretische prestaties die je schetst nooit zult halen. De Intel 750 is afgeleid van Intel's server SSD's, dus ik verwacht daar minder problemen mee.

De ingebouwde RAID van nieuwe Intel chipsets kan ook twee NVMe schijven in RAID1 draaien mocht beschikbaarheid echt van groot belang zijn voor je.

[|sWORDs|]

Ik heb ook meer vertrouwen in een enkele Intel 750 dan 8 consumer SATA SSDs.
De 2.5" Intel 750 kun je via M.2->U.2 of PCIE->M.2->U.2 verbinden. Echter waarom ga je dan niet gewoon direct voor een HHHL model?
Maar de cruciale vraag is: Wat ga je er op draaien?

[ Voor 33% gewijzigd door |sWORDs| op 17-10-2016 11:11 ]

[Verwijderd]

Navi schreef op maandag 17 oktober 2016 @ 10:56:
Ik bedoel met volledig, dat er ook sommige SSD's zijn die een heel klein setje capacitors hebben wat power loss protection genoemd wordt, maar dat eigenlijk niet is. (zoals bv de Crucials hebben)

Vertel! Ik ben benieuwd!

Je bedoelt dat Crucial SSDs net zoals moderne Intel SSDs enkel genoeg capacitors hebben om de huidige write af te ronden en niet genoeg voor alle gegevens in de DRAM?

Kun jij aangeven wat volgens jou het verschil is tussen 'echte' power-loss en 'nep' of hoe je dat zou willen noemen? Voor wat zou je dat nodig hebben?

[Navi]

Volgens mij geef ik boven al aardig wat links, maar hier nog een concreet voorbeeld:

http://www.anandtech.com/...sd-review-nda-placeholder

Scrollen naar: "The Truth About Micron's Power-Loss Protection"

Vergelijk daar de capacitors uit een Datacenter lijn eens met de consumenten!

"In the MX100 review, I was still under the impression that there was full power-loss protection in the drive, but my impression was wrong. The client-level implementation only guarantees that data-at-rest is protected, meaning that any in-flight data will be lost, including the user data in the DRAM buffer. In other words the M500, M550 and MX100 do not have power-loss protection -- what they have is circuitry that protects against corruption of existing data in the case of a power-loss."

Forum thread hierover:
https://forums.servetheho...-protection-read-me.3930/

Met uitspraken van Micron als:
"It was not Micron's or our intention to "fool" anyone into believe that the clients drives have full power-loss protection"

Dat bedoel ik met "echte" (grote capacitors, werken volledig) en "nep" (kleine capacitors, niet volledig)

En ter info, ook de Intel 750 is gewoon een consumenten uitvoering, hier vindt je een mooi overzichtje:
http://ark.intel.com/#@SolidStateDrives

[ Voor 31% gewijzigd door Navi op 17-10-2016 12:38 ]

[Verwijderd]

Dat er verschil is, klopt, alleen de Intel 320 heeft power-safe capacitors die de volledige SRAM write-back kan wegschrijven. Maar dit komt omdat deze SSD interne 256KiB SRAM als write-back gebruikt en niet de DRAM chip. Moderne SSDs gebruiken DRAM voor write-back en dat kost veel meer energie.

Maar mijn vraag ging eigenlijk vooral over: waarom zou het ene minder goed zijn dan het andere. Waarvoor zou je 'volledige' power-safe capacitors nodig hebben.

Het is namelijk Anandtech die hier fout zit. Zij hebben aan de hand van marketingmateriaal van Micron verondersteld dat capacitors genoeg capaciteit hebben voor het legen van de volledige DRAM write-back. Micron/Crucial heeft die claim nooit gemaakt. Wel dat er PLP op de Crucial SSDs zit, wat klopt.

PLP die ook de DRAM write-back beschermd, zoals jij kennelijk graag wilt, is nuttig voor ouderwetse bestandssystemen als FAT16, Ext2 en UFS1. Zeg maar uit het 1990-tijdperk. Vanaf Windows NT4 met NTFS heb je dit niet meer nodig. Als je niet begrijpt waarom het filesystem invloed heeft op PLP, dan mis je de hele essentie van PLP.

Het is niet dat ik je graag betrap op een mythe, maar dit geval van PLP wordt door maar weinig mensen begrepen en er heerst veel onduidelijkheid over. De ondeskundigheid van Anandtech wordt niet onderkend, dat wordt op de fabrikant zelf verhaald. Onterecht, mijns inziens. Anandtech heeft al een slechte track-record als het gaat over SSDs. Zo moest ik Anand Lal Shimpi zelf op de hoogte stellen dat zijn SSD benchmarks/reviews nutteloos zijn omdat hij zero-write of static random data op Sandforce SSDs gebruikte, en daardoor Sandforce onrealistisch hoge scores kreeg in zijn artikelen.

Kortom, wees voorzichtig wat je leest, vooral op grote en bekende reviewsites. Eigen fouten of ondeskundige analyses worden zelden (nooit) erkend. Nu ook weer met uitspraken als:

I'm happy to see that Intel understands how power loss protection can be a critical feature for the high-end client segment as well because especially professional users can't have the risk of losing any data.

Daar wordt verlies van dirty buffers in DRAM gelijk gesteld aan 'verlies van data'. Ja als we zo gaan oordelen, hoeven we filesystems er niet bij te betrekken. Terwijl dat juist de crux is wat zo'n opmerking als hierboven invalide maakt.

[C.Hariri]

Hi!

Bedankt allemaal voor deze gigantisch goede feedbaack.

1. Soort van (write) operaties
Ik heb mede door deze vragen eens specifiek gekeken naar wat de workload is, en deze onderzocht. Hier een kleine log:

http://i.imgur.com/DUolVWh.png

Tot mijn verassing genereert de applicatie gigantisch diepe queue depths (avgqu-sz, queuesize: 130 tot zelfs 500), schrijven, voor soms wel 30minuten lang tot soms wel een uur.

Wat meer onderzoek:

Performance zakt gigantisch in naar mate er voor een lange tijd veel geschreven wordt naar een SSD:

MX200, en 850 EVO, etc.
https://nl.hardware.info/...-steady-state-performance

Zelfs de 850 Pro:
https://nl.hardware.info/...-performance-consistentie

En 950 pro:
https://nl.hardware.info/...-performance-consistentie

De SSD die dat niet heeft is de Intel 750:
https://nl.hardware.info/...-performance-consistentie

Dus voor performance wint een enkele Intel 750 (660MB/s) tegenover 8x MX200 (+- 300MB/s) in het geval van QD32, als er langer dan 10 minuten achtereenvolgend op geschreven wordt.

Stroomverliesbescherming
Cruciale informatie zit in SQL database en zal worden gesynchroniseerd tussen twee servers. Info is vooral data uit sensoren, dus het is niet 100% mission-critical (er kan wat data verloren gaan; het zijn geen bank-transacties oid). Het fijnste zou wel zijn dat het filesysteem niet corrupt raakt, want in zo'n geval kost het downtime en veel extra tijd ivm formatteren en alles opnieuw installeren. Sowieso is EXT2-4 journaled, en zou de basis stroomverliesbescherming van de 750 hier wel voldoende voor zijn, neem ik aan.

Verbinding
Door 1U ben ik gelimiteerd in aansluitmogelijkheden. Een riser met daaraan een PCIe apparaat vind ik eigenlijk maar eng, zonder deze en de SSD goed vast te kunnen schroeven.

Maar ik denk dat deze bijv. wel kan:
http://eshop.dataflex-sec...8643-pcie-4x-adapter.html

Als ik nu 2x Intel 750 400GB pak, heb ik zowel redundancy als voldoende snelheid. Enige nadeel is dat de 1U behuizingen geen hotswap slots hebben voor U2, maar dat zal ik op de koop toe moeten nemen tov alle andere voordelen.

[ Voor 5% gewijzigd door C.Hariri op 19-10-2016 13:50 ]

[Bigs]

Die iostat laat zien dat sdb met 21 IOPS en 10MB/s 100% bezet is. Draai je nu vanaf een USB stick ofzo? Op basis van deze meting kun je eigenlijk geen conclusies trekken. Een gemiddelde laptop harde schijf levert al betere prestaties dan dit.

De sda schijf heeft trouwens een vergelijkbare belasting en is daarmee slechts 7% van de tijd bezet. De sdb schijf is dus duidelijk je bottleneck. Ik zou eens kijken wat daarmee aan de hand is voordat je gaat investeren in dure SSD's.

[ Voor 49% gewijzigd door Bigs op 19-10-2016 13:53 ]

[Kuusj]

Wim-Bart schreef op zaterdag 15 oktober 2016 @ 20:57:
Ik zou voor een Samsung gaan. Hier zit een MX al na 2 maanden op 99% lifetime terwijl een evo 950 na een jaar met 3 x zo veel data writes nog op 100% zit.

En dan spreken we over server gebruik.

Hoeveel is 3x zo veel? Ik zit met 10TB written op een 250GB 840 EVO op 94%, dat ding is dus na een jaar of 2-3 veel gebruiken gaar.

[C.Hariri]

Bigs schreef op woensdag 19 oktober 2016 @ 13:49:
Die iostat laat zien dat sdb met 21 IOPS en 10MB/s 100% bezet is. Draai je nu vanaf een USB stick ofzo? Op basis van deze meting kun je eigenlijk geen conclusies trekken. Een gemiddelde laptop harde schijf levert al betere prestaties dan dit.

De sda schijf heeft trouwens een vergelijkbare belasting en is daarmee slechts 7% van de tijd bezet. De sdb schijf is dus duidelijk je bottleneck. Ik zou eens kijken wat daarmee aan de hand is voordat je gaat investeren in dure SSD's.

Hi,

dit is opgenomen tijdens het uitvoeren van een update. SSD is dit moment is een MX200 (x2). DIt is een oudere server die vervangen gaat worden. Maar ik was juist onder de indruk dat avgqu-sz de gemiddelde queue size opgaf?

The r/s and w/s numbers show the number of read and write requests issued to the device per second. These numbers provide a more detailed breakdown of the tps number we saw earlier, as tps = r/s + w/s.

The avgqu-sz metric is an important value. Its name is rather poorly chosen as it does not in fact show the number of operations queued but not yet serviced. Instead, it shows the number of operations that were either queued or being serviced. Ideally you want to have an idea of the value of this metric during normal operations for use as a reference when trouble occurs. Single digit numbers with the occasional double digit spike are safe(ish) values. Triple digit numbers are generally not.

gr,
cas

[Bigs]

C.Hariri schreef op zaterdag 15 oktober 2016 @ 12:59:

Bovendien:
1. voor 1U kasten heb ik geen hotswappable NVME kunnen vinden
2. Op moederborden met 2011-3 van serverkwaliteit (intel chipset) en 1CPU socket heb ik geen NVME connector op weten te vinden.

Bij servers gebruik je geen M.2 sloten, maar 2,5" NVMe schijven met SFF-8639 connectors. Onder andere Super Micro heeft hier al enige tijd chassis voor op de markt (voorbeeld voorbeeld).

[Bigs]

C.Hariri schreef op woensdag 19 oktober 2016 @ 13:55:
[...]

Hi,

dit is opgenomen tijdens het uitvoeren van een update. SSD is dit moment is een MX200 (x2). DIt is een oudere server die vervangen gaat worden. Maar ik was juist onder de indruk dat avgqu-sz de gemiddelde queue size opgaf?


[...]


gr,
cas

Een SSD koop je in eerste instantie op IOPS en write endurance, queue size is daarin niet echt interssant.

De SSD die je nu gebruikt als sdb is versleten of stuk want die levert max 30 IOPS. Puur naar deze iostat uitvoer kijkend hen je waarschijnlijk geen RAID 10 van SSD's of dure NVMe SSD's nodig hebt, maar gewoon een fatsoenlijke server SSD (b.v. Intel DC serie) met een write endurance die past bij je workload.

De MX200 is na 80TB writes op, daar ben je met jouw schrijftempo in drie maanden doorheen.

[ Voor 10% gewijzigd door Bigs op 19-10-2016 14:16 ]

[Verwijderd]

C.Hariri schreef op woensdag 19 oktober 2016 @ 13:44:
Tot mijn verassing genereert de applicatie gigantisch diepe queue depths (avgqu-sz, queuesize: 130 tot zelfs 500), schrijven, voor soms wel 30minuten lang tot soms wel een uur.

Je SSD kan de IOps niet aan; daarom wordt de queue depth zo hoog. Als je SSD de IOps beter aankan, zal de queue depth ook veel sneller leeg raken. Denk aan een wasbak met afvoerputje, als de afvoer maar beperkte capaciteit heeft, zal de wasbak langzaam vollopen met water. Maar als de afvoer groot genoeg is en niet verstopt zit, kan deze alle water direct afvoeren en zal er dus geen water in de wasbak blijven staan. De hoogte van het water in de wasbak staat hierbij analoog aan queue depth.

De oorzaak is waarschijnlijk te weinig overprovisioning, en mogelijk geen TRIM mogelijkheid. Hoeveel OP heb je in gebruik? Indien geen, dan is dit je oorzaak. Zonder TRIM en voor serverdoeleinden wil je iets van 50% overprovisioning gebruiken. Dus een 500GB SSD partitioneer je dan als 250GB en de rest beschrijf je nooit. Desktopgebruikers hebben dit veelal niet nodig omdat ze veel meer statische data schrijven en minder dynamische data, en daarnaast doet TRIM zijn werk. Met voldoende OP heb je ook helemaal geen TRIM meer nodig. MX200 kan daarnaast beschikken over DWA waardoor je een deel als SLC kunt gebruiken als je minder dan de helft van de schijf gebruikt - dat is nog exclusief overprovisioning.

Kortom, je kunt wel consumenten SSDs gebruiken. Maar beschouw een 500GB SSD dan gewoon als 250GB. Server SSDs doen dit van nature al.

Stroomverliesbescherming
Cruciale informatie zit in SQL database en zal worden gesynchroniseerd tussen twee servers. Info is vooral data uit sensoren, dus het is niet 100% mission-critical (er kan wat data verloren gaan; het zijn geen bank-transacties oid). Het fijnste zou wel zijn dat het filesysteem niet corrupt raakt, want in zo'n geval kost het downtime en veel extra tijd ivm formatteren en alles opnieuw installeren. Sowieso is EXT2-4 journaled, en zou de basis stroomverliesbescherming van de 750 hier wel voldoende voor zijn, neem ik aan.

Ext2 is niet journalled, dus daar krijg je corruptie als je een SSD zonder PLP gebruikt. Vanaf Ext3 is het journalled (net als NTFS, UFS2+SUJ, HFS, JFS, etc) en kun je dus recente writes verliezen zoals hardeschijven ook doen. Basale PLP is dan voldoende. Volledige PLP waarbij ook de DRAM write-back wordt beschermd, zoals Intel 320 doet, is nuttig voor specifieke situaties of oudere filesystems zoals Ext2, FAT16, FAT32 en UFS1. Traditioneel werd voor deze filesystems ook de write cache uitgeschakeld, zodat alle I/O één voor één gaat. Dat betekent wel dat een hardeschijf maar 1MB/s kan schrijven ipv 100MB/s.

Met een filesystem van de 2e generatie met journalling heb je dus voldoende aan Crucial MX100/MX200/MX300 bescherming.

SSDs zonder PLP (dus zowel geen hardwarematige als softwarematige bescherming) kan ook bestaande data die al lange tijd opgeslagen is, corrupt raken. Dit gebeurde aan de lopende band bij veel SSDs enige jaren terug, in het Crucial M4 tijdperk. Dergelijke SSDs zijn inherent onbetrouwbaar. Elke SSD dient over beschermingsmechanismes te beschikken die zogenaamde 'data at rest' beschermt. Dit omvat alle data die is geverificeert met een FLUSH commando. Dan heeft de SSD zijn garantie gegeven dat de data daadwerkelijk is opgeslagen. Als de SSD vervolgens de data toch niet kan aanleveren zoals het filesystem die heeft weggeschreven, is dit corruptie veroorzaakt door de SSD zelf.

Kortom, in jouw situatie heb je genoeg aan 'data at rest protection' en heb je geen volledige PLP nodig die de hele DRAM write-back beschermt. Dat heb je nodig voor specifieke situaties, of voor extra performance zodat je FLUSH commando's kunt uitschakelen - vrij geavanceerd en veelal iets voor grotere enterprises. Zoals Google die zijn eigen GFS filesystem heeft ontwikkeld.

[Wim-Bart]

kuusj98 schreef op woensdag 19 oktober 2016 @ 13:54:
[...]

Hoeveel is 3x zo veel? Ik zit met 10TB written op een 250GB 840 EVO op 94%, dat ding is dus na een jaar of 2-3 veel gebruiken gaar.

De Samsungs:

code:

----------------------------------------------------------------------------
CrystalDiskInfo 6.5.2 Shizuku Edition x64 (C) 2008-2015 hiyohiyo
                                Crystal Dew World : http://crystalmark.info/
----------------------------------------------------------------------------

    OS : Windows 10 Professional [10.0 Build 14393] (x64)
  Date : 2016/10/20 2:05:02

-- Controller Map ----------------------------------------------------------
 + Standaard AHCI 1.0 Serial ATA-controller [ATA]
   - Samsung SSD 850 EVO 500GB
   - SAMSUNG SSD 830 Series
   - hp BDDVDRW CH20L
   - WDC WD15EADS-65P8BX
 - Controlefunctie voor opslagruimten van Microsoft [SCSI]

-- Disk List ---------------------------------------------------------------
 (1) Samsung SSD 850 EVO 500GB : 500,1 GB [0/0/0, pd1] - sg
 (2) SAMSUNG SSD 830 Series : 128,0 GB [1/0/0, pd1] - sg
 (3) WDC WD15EADS-65P8BX : 1500,3 GB [2/0/0, pd1] - wd

----------------------------------------------------------------------------
 (1) Samsung SSD 850 EVO 500GB
----------------------------------------------------------------------------
           Model : Samsung SSD 850 EVO 500GB
        Firmware : EMT02B6Q
   Serial Number : S21JNXAG477219R
       Disk Size : 500,1 GB (8,4/137,4/500,1/500,1)
     Buffer Size : onbekend
     Queue Depth : 32
    # of Sectors : 976773168
   Rotation Rate : ---- (SSD)
       Interface : Serial ATA
   Major Version : ACS-2
   Minor Version : ATA8-ACS version 4c
   Transfer Mode : SATA/600 | SATA/600
  Power On Hours : 4316 uren
  Power On Count : 387 keer
     Host Writes : 8039 GB
Wear Level Count : 15
     Temperature : 29 C (84 F)
   Health Status : Goed (100 %)
        Features : S.M.A.R.T., 48bit LBA, NCQ, TRIM, DevSleep
       APM Level : ----
       AAM Level : ----

-- S.M.A.R.T. --------------------------------------------------------------
ID Cur Wor Thr RawValues(6) Attribute Name
05 100 100 _10 000000000000 Reallocated Sector Count
09 _99 _99 __0 0000000010DC Power-on Hours
0C _99 _99 __0 000000000183 Power-on Count
B1 _99 _99 __0 00000000000F Wear Leveling Count
B3 100 100 _10 000000000000 Used Reserved Block Count (Total)
B5 100 100 _10 000000000000 Program Fail Count (Total)
B6 100 100 _10 000000000000 Erase Fail Count (Total)
B7 100 _99 _10 000000000000 Runtime Bad Block (Total)
BB 100 100 __0 000000000000 Uncorrectable Error Count
BE _71 _58 __0 00000000001D Airflow Temperature
C3 200 200 __0 000000000000 ECC Error Rate
C7 _99 _99 __0 000000000018 CRC Error Count
EB _99 _99 __0 00000000002B POR Recovery Count
F1 _99 _99 __0 0003ECF16C49 Total LBA Written

<<knip>>
----------------------------------------------------------------------------
 (2) SAMSUNG SSD 830 Series
----------------------------------------------------------------------------
           Model : SAMSUNG SSD 830 Series
        Firmware : CXM03B1Q
   Serial Number : S0XYNEAC638795
       Disk Size : 128,0 GB (8,4/128,0/128,0/128,0)
     Buffer Size : onbekend
     Queue Depth : 32
    # of Sectors : 250069680
   Rotation Rate : ---- (SSD)
       Interface : Serial ATA
   Major Version : ACS-2
   Minor Version : ACS-2 Revision 2
   Transfer Mode : SATA/600 | SATA/600
  Power On Hours : 15423 uren
  Power On Count : 1187 keer
     Host Writes : 6736 GB
Wear Level Count : 176
     Temperature : 24 C (75 F)
   Health Status : Goed (100 %)
        Features : S.M.A.R.T., 48bit LBA, NCQ, TRIM
       APM Level : ----
       AAM Level : ----

-- S.M.A.R.T. --------------------------------------------------------------
ID Cur Wor Thr RawValues(6) Attribute Name
05 100 100 _10 000000000000 Reallocated Sector Count
09 _96 _96 __0 000000003C3F Power-on Hours
0C _98 _98 __0 0000000004A3 Power-on Count
B1 _95 _95 __0 0000000000B0 Wear Leveling Count
B3 100 100 _10 000000000000 Used Reserved Block Count (Total)
B5 100 100 _10 000000000000 Program Fail Count (Total)
B6 100 100 _10 000000000000 Erase Fail Count (Total)
B7 100 100 _10 000000000000 Runtime Bad Block (Total)
BB 100 100 __0 000000000000 Uncorrectable Error Count
BE _76 _50 __0 000000000018 Airflow Temperature
C3 200 200 __0 000000000000 ECC Error Rate
C7 253 253 __0 000000000000 CRC Error Count
EB _99 _99 __0 00000000007F POR Recovery Count
F1 _99 _99 __0 00034A039D07 Total LBA Written

En nu de Crucial (aangeschaft 16 augustus 2016)

code:

----------------------------------------------------------------------------
CrystalDiskInfo 7.0.2 (C) 2008-2016 hiyohiyo
                                Crystal Dew World : http://crystalmark.info/
----------------------------------------------------------------------------

    OS : Windows Server 2012 R2 Datacenter (Full installation) [6.3 Build 9600] (x64)
  Date : 2016/10/20 2:06:58

-- Controller Map ----------------------------------------------------------
 + AMD SATA Controller [ATA]
   - Crucial_ CT525MX300SSD1 SATA Disk Device
   - WDC WD20 EADS-00R6B0 SATA Disk Device
   - WDC WD20 02FYPS-02W3B1 SATA Disk Device
   - WDC WD20 EADS-00R6B0 SATA Disk Device
   - WDC WD20 EARS-00MVWB0 SATA Disk Device
   - WDC WD20 EARX-00PASB0 SATA Disk Device
 - Microsoft iSCSI Initiator [SCSI]
 + Microsoft Storage Spaces Controller [SCSI]
   - Microsoft Storage Space Device
 + Microsoft VHD Loopback Controller [SCSI]
   - Microsoft Virtual Disk

-- Disk List ---------------------------------------------------------------
 (1) Crucial_CT525MX300SSD1 : 525,1 GB [0/0/0, pd1] - mi
 (2) WDC WD20EADS-00R6B0 : 2000,3 GB [1/X/X, pd1] - wd
 (3) WDC WD2002FYPS-02W3B1 : 2000,3 GB [2/X/X, pd1] - wd
 (4) WDC WD20EADS-00R6B0 : 2000,3 GB [3/X/X, pd1] - wd
 (5) WDC WD20EARS-00MVWB0 : 2000,3 GB [4/X/X, pd1] - wd
 (6) WDC WD20EARX-00PASB0 : 2000,3 GB [5/X/X, pd1] - wd

----------------------------------------------------------------------------
 (1) Crucial_CT525MX300SSD1
----------------------------------------------------------------------------
           Model : Crucial_CT525MX300SSD1
        Firmware : M0CR021
   Serial Number : 16281345449D
       Disk Size : 525,1 GB (8,4/137,4/525,1/525,1)
     Buffer Size : onbekend
     Queue Depth : 32
    # of Sectors : 1025610768
   Rotation Rate : ---- (SSD)
       Interface : Serial ATA
   Major Version : ACS-3
   Minor Version : ---- [006Dh]
   Transfer Mode : SATA/600 | SATA/600
  Power On Hours : 1627 uren
  Power On Count : 22 keer
     Host Writes : 3738 GB
Wear Level Count : 16
     Temperature : 30 C (86 F)
   Health Status : Goed (99 %)
        Features : S.M.A.R.T., APM, 48bit LBA, NCQ, TRIM, DevSleep
       APM Level : 00FEh [ON]
       AAM Level : ----
    Drive Letter : C: D:

-- S.M.A.R.T. --------------------------------------------------------------
ID Cur Wor Thr RawValues(6) Attribute Name
01 100 100 __0 000000000000 Raw Read Error Rate
05 100 100 _10 000000000000 Reallocated Sectors Count
09 100 100 __0 00000000065B Power-On Hours
0C 100 100 __0 000000000016 Power Cycle Count
AB 100 100 __0 000000000000 Program Fail Count
AC 100 100 __0 000000000000 Erase Fail Count
AD _99 _99 __0 000000000010 Average Block-Erase Count
AE 100 100 __0 000000000010 Unexpected Power Loss Count
B7 100 100 __0 000000000000 SATA Interface Downshift
B8 100 100 __0 000000000000 Error Correction Count
BB 100 100 __0 000000000000 Reported Uncorrectable Errors
C2 _70 _51 __0 00310017001E Temperature
C4 100 100 __0 000000000000 Reallocation Event Count
C5 100 100 __0 000000000000 Current Pending Sector Count
C6 100 100 __0 000000000000 Smart Off-line Scan Uncorrectable Error Count
C7 100 100 __0 000000000000 Ultra DMA CRC Error Rate
CA _99 _99 __1 000000000001 Percent Lifetime Used
CE 100 100 __0 000000000000 Write Error Rate
F6 100 100 __0 0001D340747E Total Host Sector Writes
F7 100 100 __0 00000EB57050 Host Program Page Count
F8 100 100 __0 000006D9B960 FTL Program Page Count
B4 __0 __0 __0 000000000793 Unused Reserve NAND Blocks
D2 100 100 __0 000000000000 Successful RAIN Recovery Count

<<knip>>

Navi schreef op maandag 17 oktober 2016 @ 12:34:
Volgens mij geef ik boven al aardig wat links, maar hier nog een concreet voorbeeld:

http://www.anandtech.com/...sd-review-nda-placeholder

Scrollen naar: "The Truth About Micron's Power-Loss Protection"

Vergelijk daar de capacitors uit een Datacenter lijn eens met de consumenten!

"In the MX100 review, I was still under the impression that there was full power-loss protection in the drive, but my impression was wrong. The client-level implementation only guarantees that data-at-rest is protected, meaning that any in-flight data will be lost, including the user data in the DRAM buffer. In other words the M500, M550 and MX100 do not have power-loss protection -- what they have is circuitry that protects against corruption of existing data in the case of a power-loss."

Forum thread hierover:
https://forums.servetheho...-protection-read-me.3930/

Met uitspraken van Micron als:
"It was not Micron's or our intention to "fool" anyone into believe that the clients drives have full power-loss protection"

Dat bedoel ik met "echte" (grote capacitors, werken volledig) en "nep" (kleine capacitors, niet volledig)

En ter info, ook de Intel 750 is gewoon een consumenten uitvoering, hier vindt je een mooi overzichtje:
http://ark.intel.com/#@SolidStateDrives

Dus de reden dat ik een MX300 heb gekozen boven een Samsung sloeg nergens op. Waar ik tegen beschermd wilde zijn wordt dus uiteindelijk niet geboden. Luister ik een keer naar CIPHER voor de keuze van een SSD (de CAP's) in een Server had ik beter kunnen kiezen voor een Samsung met een langere levensduur.

Fuck Crucial!!!

[ Voor 9% gewijzigd door Wim-Bart op 20-10-2016 02:20 ]

[johnkeates]

Wim-Bart schreef op donderdag 20 oktober 2016 @ 02:08:
[...]
<knip>
[...]


Dus de reden dat ik een MX300 heb gekozen boven een Samsung sloeg nergens op. Waar ik tegen beschermd wilde zijn wordt dus uiteindelijk niet geboden. Luister ik een keer naar CIPHER voor de keuze van een SSD (de CAP's) in een Server had ik beter kunnen kiezen voor een Samsung met een langere levensduur.

Fuck Crucial!!!

Waar wil je dan zo nodig tegen beschermd zijn? De data die je opgeslagen hebt is veilig, en je journal maakt de buffer storage loss verwaarloosbaar voor alle transacties die al gestart waren.

[Wim-Bart]

johnkeates schreef op donderdag 20 oktober 2016 @ 02:25:
[...]


Waar wil je dan zo nodig tegen beschermd zijn? De data die je opgeslagen hebt is veilig, en je journal maakt de buffer storage loss verwaarloosbaar voor alle transacties die al gestart waren.

Ik wilde beschermd zijn voor het correct wegschrijven van alle sectoren in de buffer. Maar daar is het hele capacitor verhaal dus niet voor met consumenten disks. Dat was mijn motief om Crucial boven Samsung voor mijn server te verkiezen wanneer net die "ene" write komt die belangrijk is en mijn UPS net die storing heeft die hij niet zou moeten hebben.

Dus ik zit met een disk waarvan de lifetime de helft is van een Samsung EVO zonder de geadverteerde en aangeraden bescherming. Een kut product dus. Ga morgen eens kijken of ik hem kan ruilen tegen een EVO wegens misleiding.

[ Voor 14% gewijzigd door Wim-Bart op 20-10-2016 02:30 ]

[johnkeates]

Wim-Bart schreef op donderdag 20 oktober 2016 @ 02:29:
[...]


Ik wilde beschermd zijn voor het correct wegschrijven van alle sectoren in de buffer. Maar daar is het hele capacitor verhaal dus niet voor met consumenten disks. Dat was mijn motief om Crucial boven Samsung voor mijn server te verkiezen wanneer net die "ene" write komt die belangrijk is en mijn UPS net die storing heeft die hij niet zou moeten hebben.

Maar dat is dus niet wat dit is, ook niet wat die buffer is, en ook niet wat er in een SSD plaats vindt. De meeste data die je daadwerkelijk kwijt kan raken staat in je RAM en CPU registers, niet in je SSD buffers. De belangrijkste writes zijn de writes die nog niet eens de SATA of NVMe controller binnen zijn gekomen, dat staat dus zelfs buiten je opslagapparaat.

[Wim-Bart]

johnkeates schreef op donderdag 20 oktober 2016 @ 02:31:
[...]


Maar dat is dus niet wat dit is, ook niet wat die buffer is, en ook niet wat er in een SSD plaats vindt. De meeste data die je daadwerkelijk kwijt kan raken staat in je RAM en CPU registers, niet in je SSD buffers. De belangrijkste writes zijn de writes die nog niet eens de SATA of NVMe controller binnen zijn gekomen, dat staat dus zelfs buiten je opslagapparaat.

Stel er wordt een 8 block bit table weggeschreven in een sequentieële write. Dus een totaal nieuwe versie van bijvoorbeeld een NTFS bittable. Beetje lullig wanner de eerste 7 blocks worden geschreven en de 8e niet met totale filesystem corruptie tot gevolg. Zelfde waar je een BBU voor gebruikt op een Raid controller.

Het gaat dus om het kunnen completeren van een transactie die al is gestart binnen de disk. Daar buiten maakt niks uit. Het protocol kan namelijk gewoon tegen de disk zeggen. Schrijf volgende sectoren achter elkaar, en je wil dat die ene transactie in de disk buffer geheel wordt uitgevoerd, of geheel wordt teruggedraaid.

Op de website staat zelfs:

• Power Loss Protection completes write commands even if power is lost

[ Voor 9% gewijzigd door Wim-Bart op 20-10-2016 02:43 ]

[johnkeates]

Wim-Bart schreef op donderdag 20 oktober 2016 @ 02:38:
[...]


Stel er wordt een 8 block bit table weggeschreven in een sequentieële write. Dus een totaal nieuwe versie van bijvoorbeeld een NTFS bittable. Beetje lullig wanner de eerste 7 blocks worden geschreven en de 8e niet met totale filesystem corruptie tot gevolg. Zelfde waar je een BBU voor gebruikt op een Raid controller.

Het gaat dus om het kunnen completeren van een transactie die al is gestart binnen de disk. Daar buiten maakt niks uit. Het protocol kan namelijk gewoon tegen de disk zeggen. Schrijf volgende sectoren achter elkaar, en je wil dat die ene transactie in de disk buffer geheel wordt uitgevoerd, of geheel wordt teruggedraaid.

Op de website staat zelfs:

• Power Loss Protection completes write commands even if power is lost

Ja, maar NTFS heeft ook gewoon een journal. Totdat de transactie afgerond is zal de disk dat niet melden, en daarna wordt het journal pas bijgewerkt. Mocht de stroom dus uitvallen, dan heb je geen corruptie. Dat geldt ook als die bit table nog in RAM opgebouwd wordt, of daar incompleet is en er wat in je CPU registers staat. Pas als alles verwerkt is, en er bijvoorbeeld ook een FLUSH compleet is, dan pas wordt het journal bijgewerkt en is de transactie compleet.

[Verwijderd]

Wim-Bart schreef op zaterdag 15 oktober 2016 @ 20:57:
Hier zit een MX al na 2 maanden op 99% lifetime terwijl een evo 950 na een jaar met 3 x zo veel data writes nog op 100% zit.

Beide SSDs die je post zitten op 99%, de Samsung heeft 6,7 TB geschreven en de Crucial ongeveer de helft: 3,7 TB. Je zult meer writes moeten hebben voordat je het percentage goed zou kunnen vergelijken.

Daarnaast gaat het niet alleen om de hoeveelheid writes, het gaat ook over write amplification. Als je veel schrijft naar een SSD met weinig spare space / overprovisioning, dan zullen die writes veel harder aantikken. Sommige SSDs kun je aan de hand van host writes en physical writes uitrekenen wat de write amplification is.

Maargoed, jouw impliciete conclusie dat Crucial sneller slijt, is door de cijfers die jij aanlevert zeker niet aangetoond.

Wim-Bart schreef op donderdag 20 oktober 2016 @ 02:08:
Dus de reden dat ik een MX300 heb gekozen boven een Samsung sloeg nergens op. Waar ik tegen beschermd wilde zijn wordt dus uiteindelijk niet geboden. Luister ik een keer naar CIPHER voor de keuze van een SSD (de CAP's) in een Server had ik beter kunnen kiezen voor een Samsung met een langere levensduur.

Fuck Crucial!!!

Ik merk dat je er emotioneel door wordt. Maar is dat wel terecht?

Je wilde tegen iets beschermd zijn - waartegen precies? En die bescherming zou je uiteindelijk niet hebben gehad. Ik ben benieuwd! Vertel! Het komt op mij over dat je een aantal dingen gewoon nog niet optimaal begrijpt en dat dit leidt tot bepaalde voorbarige conclusies.

Je zegt dat Samsung een langere levensduur heeft; die claim heb ik nooit gestaafd zien worden. Er zijn wel write endurance tests die Samsung SSDs ver boven hun MWI writes hebben getest, maar daarbij is retentie niet of nauwelijks getest waardoor onduidelijk is of een dergelijke SSD nog een bruikbaar opslagapparaat oplevert. Een goed vergelijkende test met Crucial ken ik niet.

Zelfs als het klopt dat Samsung een langere levensduur zou hebben, is dit niet waarom je de SSD hebt aangeschafd. Je zegt zelf dat je dat deed vanwege PLP. Nu ben je kennelijk in de veronderstelling dat Crucial dat toch niet heeft ("wordt dus uiteindelijk niet geboden"). Maar is dat geen foute conclusie?

Wim-Bart schreef op donderdag 20 oktober 2016 @ 02:29:
Ik wilde beschermd zijn voor het correct wegschrijven van alle sectoren in de buffer.

En waarom wilde je dat? Gebruik je nog Windows 95 met FAT-filesystem, of heb je bijzondere wensen?

Maar daar is het hele capacitor verhaal dus niet voor met consumenten disks. Dat was mijn motief om Crucial boven Samsung voor mijn server te verkiezen wanneer net die "ene" write komt die belangrijk is en mijn UPS net die storing heeft die hij niet zou moeten hebben.

Dan verlies je die write toch gewoon? Daar zijn toch alle filesystems voor ontworpen? Dat is toch hoe het werkt met vrijwel ALLE opslag inclusief alle hardeschijven, voor de afgelopen 30 jaar?

Als net die 'ene write die belangrijk is' bezig is, dan zal het filesystem daarna een FLUSH CACHE commando sturen, want belangrijke metadata writes worden gescheiden van user data. Door het FLUSH commando mag de SSD pas de overige data verwerken als de FLUSH is voltooid, inclusief het wegschrijven van de DRAM buffer.

Als, gedurende deze tijd, een stroomstoring voordoet, dan heeft het filesystem zichzelf beschermd tegen corruptie, want een journalling filesystem kan zich weren tegen verloren dirty buffers door een oudere versie van de metadata van het filesystem te gebruiken. Je filesystem gaat dus enkele seconden terug in de tijd.

Dit mechanisme wat vrijwel elk filesystem heeft, inclusief NTFS, wordt ook door SSDs zoals Samsung toegepast. Het probleem is dat Samsung SSDs kunnen liegen als het om FLUSH commando's gaat; de SSD zegt dat voorgaande writes veilig staan opgeslagen, maar een stroomonderbreking kan zorgen dat die data volgende keer niet meer op de disk zijn terug te lezen. Juist dat is iets wat corruptie kan opleveren indien Samsung SSDs in bijvoorbeeld RAID geplaatst worden. Je kritiek is dus meer van toepassing op Samsung dan op Crucial. Immers, jij wilde je waardevolle writes beschermen. Dat doet Crucial beter dan Samsung, omdat Crucial door de geboden PLP geen journalling hoeft toe te passen en zich netjes aan FLUSH commando's kan houden.

Dus ik zit met een disk waarvan de lifetime de helft is van een Samsung EVO

Waar en hoe maake je deze conclusie? Toch niet op basis van de 99% MWI die je hierboven post? Hoe kun je daaruit concluderen dat Crucial minder levensduur zou hebben?

zonder de geadverteerde en aangeraden bescherming.

Wat is geadverteerd dat je niet krijgt?

Een kut product dus. Ga morgen eens kijken of ik hem kan ruilen tegen een EVO wegens misleiding.

Of rechtzaken beginnen! Maar ik geef je weinig kans omdat je bezwaren tot dusver weinig hout snijden.

[C.Hariri]

Hey allemaal! super coole info, tnmx!!

0. Vind het een beetje jammer dat er in een technische discussie emotionele zaken aan bod komen. En ik denk ook niet dat je zo hoeft te reageren, want er is verder niks aan de hand? Ik zie dat slechts de "percentage lifetime used op 1%" staat.

Desbetreffende SSD die problemen veroorzaakt heeft dit op 144%, dus ongeveer 100TB:

http://i.imgur.com/xzKGl4M.png

Verklaart het een en het ander denk ik wel , maar geeft ook wel aan dat 100% niet absoluut 100% kapot hoeft te betekenen.

1. Ik kan dus aannemen dat door middel van journaled FS'en zoals EXT3 en 4 er geen corruptie van data optreed welke op de SSD opgeslagen zijn, echter wel data 'in transit' verloren kan gaan?

Echter dat er specifieke gevallen zijn (Samsung) waar de veiligheidsfeatures niet netjes geimplementeerd zijn (bijv. om een hogere snelheid te halen), en dus een hogere kans hebben op corruptie in het geval van stroomuitval?

2. Zelf overprovisioning regelen lijkt me handig indien je de SSD helemaal volschrijft (excl. het gedeeldte dat je overprovisiont), maar heeft deze nog nut als je de SSD niet helemaal volschrijft, denk maximaal 50%? Dan kan de SSD toch nog gewoon de lege ruimte(blokken) gebruiken neem ik aan, zelfs al zijn die gepartionerd?

3. Ik heb ergens gelezen dat de 3D-TLC van Crucial/Intel anders/complexer (floating point) is dan die van Samsung. Helaas heb ik niet de write durability per sector weten te vinden; er wordt slechts gesproken van de totale schrijfcapaciteit van de hdd (bijv. 160TB). Wat me opvalt is dat deze hoger is dan de vorige generaties.

Dat is raar, want bij Crucial vinden ze dus dat een MLC minder schrijfvast is dan een 3D-TLC.

360TB MX300 (TLC): pricewatch: Crucial MX300 2,5" 1,05TB
320TB MX200 (MLC): pricewatch: Crucial MX200 2,5" 1TB

Mijn enige verklaring zou kunnen zijn dat dit op een groter procede wordt gemaakt (40nm +- voor de Samsung: https://nl.hardware.info/...udgettopper-3d-v-nand-tlc) ?

Als je ze zou mogen raten, in volgorde van aantal writes, hoe zou die er dan ongeveer uitzien?
1. MX200 (MLC)
2. MX300 (3D-TLC), Samsung 850 / 950 / 960 EVO?

Ik zit nu namelijk erg te kijken naar 960 EVO in RAID1, moederbord support geen boot from NVME, dus dan nog 2x250 MX200 of MX300 als bootschijf.

Groeten,
Cas

[Bigs]

Waarom blijf je zo vast houden aan consumenten schijven? Koop gewoon 2x pricewatch: Intel DC S3610 2,5" 400GB. Je kunt er van booten, je mag er 1,1 Petabyte op schrijven en je haalt 25.000 write IOPS ongeacht of ze nieuw zijn of in een steady state zitten. Hoef je ook niet na te denken over overprovisioning e.d. aangezien ze zijn ontworpen voor jouw gebruiksdoel.

[Wim-Bart]

Verwijderd schreef op donderdag 20 oktober 2016 @ 08:46:
[...]

Beide SSDs die je post zitten op 99%, de Samsung heeft 6,7 TB geschreven en de Crucial ongeveer de helft: 3,7 TB. Je zult meer writes moeten hebben voordat je het percentage goed zou kunnen vergelijken.

Daarnaast gaat het niet alleen om de hoeveelheid writes, het gaat ook over write amplification. Als je veel schrijft naar een SSD met weinig spare space / overprovisioning, dan zullen die writes veel harder aantikken. Sommige SSDs kun je aan de hand van host writes en physical writes uitrekenen wat de write amplification is.

Maargoed, jouw impliciete conclusie dat Crucial sneller slijt, is door de cijfers die jij aanlevert zeker niet aangetoond.


[...]

Ik merk dat je er emotioneel door wordt. Maar is dat wel terecht?

Je wilde tegen iets beschermd zijn - waartegen precies? En die bescherming zou je uiteindelijk niet hebben gehad. Ik ben benieuwd! Vertel! Het komt op mij over dat je een aantal dingen gewoon nog niet optimaal begrijpt en dat dit leidt tot bepaalde voorbarige conclusies.

Je zegt dat Samsung een langere levensduur heeft; die claim heb ik nooit gestaafd zien worden. Er zijn wel write endurance tests die Samsung SSDs ver boven hun MWI writes hebben getest, maar daarbij is retentie niet of nauwelijks getest waardoor onduidelijk is of een dergelijke SSD nog een bruikbaar opslagapparaat oplevert. Een goed vergelijkende test met Crucial ken ik niet.

Zelfs als het klopt dat Samsung een langere levensduur zou hebben, is dit niet waarom je de SSD hebt aangeschafd. Je zegt zelf dat je dat deed vanwege PLP. Nu ben je kennelijk in de veronderstelling dat Crucial dat toch niet heeft ("wordt dus uiteindelijk niet geboden"). Maar is dat geen foute conclusie?


[...]

En waarom wilde je dat? Gebruik je nog Windows 95 met FAT-filesystem, of heb je bijzondere wensen?


[...]

Dan verlies je die write toch gewoon? Daar zijn toch alle filesystems voor ontworpen? Dat is toch hoe het werkt met vrijwel ALLE opslag inclusief alle hardeschijven, voor de afgelopen 30 jaar?

Als net die 'ene write die belangrijk is' bezig is, dan zal het filesystem daarna een FLUSH CACHE commando sturen, want belangrijke metadata writes worden gescheiden van user data. Door het FLUSH commando mag de SSD pas de overige data verwerken als de FLUSH is voltooid, inclusief het wegschrijven van de DRAM buffer.

Als, gedurende deze tijd, een stroomstoring voordoet, dan heeft het filesystem zichzelf beschermd tegen corruptie, want een journalling filesystem kan zich weren tegen verloren dirty buffers door een oudere versie van de metadata van het filesystem te gebruiken. Je filesystem gaat dus enkele seconden terug in de tijd.

Dit mechanisme wat vrijwel elk filesystem heeft, inclusief NTFS, wordt ook door SSDs zoals Samsung toegepast. Het probleem is dat Samsung SSDs kunnen liegen als het om FLUSH commando's gaat; de SSD zegt dat voorgaande writes veilig staan opgeslagen, maar een stroomonderbreking kan zorgen dat die data volgende keer niet meer op de disk zijn terug te lezen. Juist dat is iets wat corruptie kan opleveren indien Samsung SSDs in bijvoorbeeld RAID geplaatst worden. Je kritiek is dus meer van toepassing op Samsung dan op Crucial. Immers, jij wilde je waardevolle writes beschermen. Dat doet Crucial beter dan Samsung, omdat Crucial door de geboden PLP geen journalling hoeft toe te passen en zich netjes aan FLUSH commando's kan houden.


[...]

Waar en hoe maake je deze conclusie? Toch niet op basis van de 99% MWI die je hierboven post? Hoe kun je daaruit concluderen dat Crucial minder levensduur zou hebben?


[...]

Wat is geadverteerd dat je niet krijgt?


[...]

Of rechtzaken beginnen! Maar ik geef je weinig kans omdat je bezwaren tot dusver weinig hout snijden.

Beide Samsugs zitten op de 100%, in zowel Crystal als in Samsung Magician :-)

Overigens ben ik er even verder in gedoken. De MX300 heeft in tegenstelling tot de andere consumenten uitvoeringen wel powercaps. De MX300 schrijft in tegenstelling tot bijvoorbeeld de BX100/BX200/MX200/M500 wel complete transactie weg in de buffer. Dus wat ik ook verwachtte. De artikelen beschrijven de andere types.

[Verwijderd]

Wim-Bart schreef op donderdag 20 oktober 2016 @ 15:21:
[...]


Beide Samsugs zitten op de 100%, in zowel Crystal als in Samsung Magician :-)

Volgens de SMART zit je Samsung op 1% MWI, dus nog 99% resterend. Dat kun je zien aan de Current-waarde van attribuut CA/F1.

Een algehele 'health' wordt vaak berekend met meerdere factoren, en heeft om die reden voor mij weinig waarde. Een hardeschijf kan 100% goed krijgen terwijl hij veel bad sectors heeft, met sommige programma's. Elk programma kan zijn eigen algoritmes loslaten op de SMART-gegevens, maar zelden gaat dit goed naar mijn ervaring.

Overigens ben ik er even verder in gedoken. De MX300 heeft in tegenstelling tot de andere consumenten uitvoeringen wel powercaps. De MX300 schrijft in tegenstelling tot bijvoorbeeld de BX100/BX200/MX200/M500 wel complete transactie weg in de buffer.

Dat lijkt mij niet erg plausibel, aangezien de MX300 juist een budget versie met TLC is, terwijl voorgaande modellen altijd met MLC NAND werkte. In de pricewatch is de MX300 vrijwel dé goedkoopste SSDs per GB.

De MX300 is in feite het antwoord op de EVO van Samsung. Meer opslag, minder endurance, goedkopere prijs. Het is niet erg aannemelijk dat Crucial heeft gekozen voor capacitors met veel hogere capaciteit om de volledige DRAM write-back te beschermen. Dat gezegd, ik heb me nog niet verdiept in de MX300 dus alles is mogelijk, maar ik denk het niet.

Mag ik vragen naar de URL van de artikelen die dit zouden bevestigen?

[Wim-Bart]

Verwijderd schreef op donderdag 20 oktober 2016 @ 17:57:
[...]

Volgens de SMART zit je Samsung op 1% MWI, dus nog 99% resterend. Dat kun je zien aan de Current-waarde van attribuut CA/F1.

Een algehele 'health' wordt vaak berekend met meerdere factoren, en heeft om die reden voor mij weinig waarde. Een hardeschijf kan 100% goed krijgen terwijl hij veel bad sectors heeft, met sommige programma's. Elk programma kan zijn eigen algoritmes loslaten op de SMART-gegevens, maar zelden gaat dit goed naar mijn ervaring.


[...]

Dat lijkt mij niet erg plausibel, aangezien de MX300 juist een budget versie met TLC is, terwijl voorgaande modellen altijd met MLC NAND werkte. In de pricewatch is de MX300 vrijwel dé goedkoopste SSDs per GB.

De MX300 is in feite het antwoord op de EVO van Samsung. Meer opslag, minder endurance, goedkopere prijs. Het is niet erg aannemelijk dat Crucial heeft gekozen voor capacitors met veel hogere capaciteit om de volledige DRAM write-back te beschermen. Dat gezegd, ik heb me nog niet verdiept in de MX300 dus alles is mogelijk, maar ik denk het niet.

Mag ik vragen naar de URL van de artikelen die dit zouden bevestigen?

Ik zie inderdaad dat artikelen elkaar tegen spreken....
http://www.tomshardware.c...mx300-750gb-ssd,4544.html

code:

Note the strips of capacitors between the controller and flash. They're supposed to keep the flash running long enough to save data in lower pages if power is lost. Most of us don't appreciate this until we need it, and we wish more SSD vendors would go to as much trouble to keep your information protected.

http://www.anandtech.com/...w-microns-3d-nand-arrives

code:

partial power loss protection and a three year warranty

https://nl.hardware.info/...x300-275gb--525gb--1050gb

code:

Een ongebruikelijke feature op de MX-serie is de aanwezigheid van condensators, die dataverlies bij stroomuitval moeten voorkomen. 

http://www.thessdreview.c...ron-3d-nand-meets-raid-0/

code:

 and power-loss protection are utilized to maintain reliability and data integrity.

http://www.hardwareluxx.d...-und-3d-nand-im-test.html

code:

Ein Feature, das man sonst praktisch nur bei wesentlich teureren Enterprise-Laufwerken findet, ist eine Power-Loss-Protection. Das Vorhandensein dieses Feature ist meistens leicht an einer größeren Anzahl an Kondensatoren zu erkennen – so auch auf der Crucial MX300. Die Kondensatoren speichern genügend Energie, um das Laufwerk im Falle eines Stromausfalls noch für ungefähr eine Millisekunde weiter versorgen zu können. Einen Unterschied zur Enterprise-Variante gibt es allerdings, denn die Crucial MX300 schützt nur Daten, die sich bereits im Flashspeicher befinden. Nutzerdaten im DRAM-Cache können bei einem Stromausfall weiterhin verlorengehen.

[Verwijderd]

Kortom, hetzelfde als op de MX200 en voorgaande modellen. Een kleine strip aan miniscule capacitors die een aantal microseconden stroom kunnen voorzien om de huidige write af te ronden. Alle gegevens in de DRAM chip gaan daarbij verloren. Precies hetzelfde als bij hardeschijven dus. Daarom dat de huidige filesystems daar prima mee overweg kunnen.

Het zijn juist de consumenten SSDs van Samsung die door hun Power-On-Recovery (POR) incompatibiliteit kunnen worden met moderne opslag zoals RAID engines, ZFS of andere complexe opslag. Wanneer deze onverwacht stroom verliezen, kunnen ze een vorige versie van de mapping tables herstellen (POR) en daarmee reist de SSD terug in de tijd, ver voor het punt dat een laatste FLUSH commando is gegeven. Dat soort geintjes doet Crucial niet voor zover ik weet, en dat is de reden dat ik die technische keuze meer waardeer dan de route die Samsung kiest, waarbij een klein beetje bespaard wordt op de kostprijs.

[Wim-Bart]

Verwijderd schreef op vrijdag 21 oktober 2016 @ 00:46:
Kortom, hetzelfde als op de MX200 en voorgaande modellen. Een kleine strip aan miniscule capacitors die een aantal microseconden stroom kunnen voorzien om de huidige write af te ronden. Alle gegevens in de DRAM chip gaan daarbij verloren. Precies hetzelfde als bij hardeschijven dus. Daarom dat de huidige filesystems daar prima mee overweg kunnen.

Het zijn juist de consumenten SSDs van Samsung die door hun Power-On-Recovery (POR) incompatibiliteit kunnen worden met moderne opslag zoals RAID engines, ZFS of andere complexe opslag. Wanneer deze onverwacht stroom verliezen, kunnen ze een vorige versie van de mapping tables herstellen (POR) en daarmee reist de SSD terug in de tijd, ver voor het punt dat een laatste FLUSH commando is gegeven. Dat soort geintjes doet Crucial niet voor zover ik weet, en dat is de reden dat ik die technische keuze meer waardeer dan de route die Samsung kiest, waarbij een klein beetje bespaard wordt op de kostprijs.

Op het moment ben ik mij aan het oriënteren met Enterprise level array's in combinatie met SSD's. Bijvoorbeeld IBM Flashcache Storage accelerator, Dell VNC Flashdrive en Pure Storage m20/m40. En wat mij op valt is dat ze stuk voor stuk juist Samsung en Intel, maar met name Samsung enterprise SSD's nemen. Daarnaast gaven twee product managers (van 2 verschillende aanbieders) mij aan dat Intel niet de favoriet is omdat daar een firmware aanpassing nogal moeilijk te realiseren is en dat de voorkeur uit gaat naar Samsung. Overigens hebben deze SSD's allemaal custom firmware heb ik begrepen.

[Verwijderd]

Dat zou prima kunnen aangezien Samsung zeer goede NAND heeft, koploper eigenlijk wel, en ook ruime ervaring met controllers. Genoeg ervaring en kennis om een goed enterprise-product te leveren. Mijn punt is dat het voor consumenten ook goed zou zijn bepaalde afwegingen te maken, maar Samsung gaat voor iets wat goed verkoopt; niet noodzakelijk een goed product.

Enterprise-gebruikers kun je niet zo makkelijk bedonderen. Het enige om die gebruikersgroep klem te zetten is middels vendor lock-ins. En dat gaat bij SSDs minder makkelijk; daarvoor hebben we de ATA, AHCI en NVMe standaarden. Kortom, alle reden dat Samsung goede producten kan maken voor de enterprise-markt.

OCZ daarentegen heeft dit ook geprobeerd in het verleden, maar dat is weinig succesvol gebleken. Consumenten kunnen dan wel vatbaar zijn voor holle marketingtermen, enterprisegebruikers zijn minder snel te overtuigen en willen harde specs en meetbare resultaten zien, alsmede een goede track record. Beide kon OCZ niet tonen.

Dat gezegd, slimme fabrikanten gaan vooral voor goedkoop consumentenspul en passen hun software aan om te beschermen tegen de risico's. Zo heeft Google een eigen GFS filesystem geschreven en gebruikte consumenten hardeschijven ipv dure enterpriseschijven. Gevolg is wel bad sectors; maar dat wordt opgevangen door Google's eigen filesystem die daar genoeg tolerantie voor heeft ingebouwd.

Zelf ben ik ook van die filosofie; je software moet slim zijn zodat je de hardware zo goedkoop mogelijk kunt houden. Dan krijg je het meeste waar voor je geld, en daar is het mij allemaal om te doen.

[Verwijderd]

Nu moet ik mezelf ook even corrigeren, want het gaat iets te ver off-topic nu. Wellicht goed om aan de topicstarter te laten welke informatie nog relevant is of welke vragen nog openstaan.

[C.Hariri]

Jup! Super bedankt allemaal. Ik ga voor de volgende setup:

* 2x Crucial MX300 275GB RAID1 (voor O/S, weining writes, O/S en apps gebruiken max 50GB, dus kan ik hem voor de helft overprovisionen)

* 1x Samsung 960 Pro 1TB (voor meeste lees en schrijfwerk)
800TB schrijfcapaciteit is bijna net zo veel als de DC3600 van Intel, tegenover dat de Samsung veel sneller is. Intel 750 is ongeveer net zo snel, echter, (1) duurder en (2) minder write endurance. Verder is de stroombescherming niet cruciaal, gezien het grootste issue corruptisering van de schijf is, en dat door de 2TB storage deels opgelost gaat worden (oudere versie die beschikbaar is), en de andere server.

* 1x 2 TB Harddisk:
- Voor backup vanaf de 960 Pro, ik zal gebruik maken van RSync oid
- Slaat de voorgaande en voorgaande backup op (daarom 2TB), dus zelfs raakt de 960 Pro defect tijdens het backuppen, dan nog is er altijd een (oudere) versie beschikbaar.
--

Verder wordt er nog een tweede server bijgezet, voor load-balance. Mocht de 960 Pro bij een van beiden uitvallen, dan kan de andere het overnemen.

[ Voor 9% gewijzigd door C.Hariri op 27-10-2016 11:58 ]

[Bigs]

Als je database niet op RAID gaat zetten kun je dat voor je OS net zo goed achterwege laten. Het een is nutteloos zonder het ander toch.

Plus een database backuppen met 'rsync oid' is vragen om problemen. Verdiep je even in de correcte backup strategie voor je database en zorg ook voor een externe backup inclusief een goed restore plan.