Puncte:1

Paritate accelerată în oglindă / NVMe / ReFs / Probleme de nivel rapid

drapel ar

În prezent, construiesc un server de laborator cu niște hardware ieftin. 2 SSD-uri NVMe, o mulțime de HDD-uri de 3,5. După crearea unei stocări pe niveluri (NVMe-Mirror & HDD-parity), formatarea acesteia cu ReFS, totul se comportă așa cum ar trebui:

  • Folosind contoare de performanță, pot vedea că nivelul rapid se umple, apoi începe să treacă la nivelul de paritate, odată ce atinge 85%.
  • Pot verifica noile scrieri care lovesc mereu nivelul rapid.
  • Citirile sunt emise la nivelul rapid sau lent, în funcție de date.

Doar dimensionarea nivelului rapid pare ciudat: Am folosit SSd-uri NVMe de 2 * 220 GB și am creat un nivel rapid de 215 GB din el. HDD-urile însumează aproximativ 6 TB. Powershell raportează aceste dimensiuni așa cum ar trebui să fie:

FriendlyName TierClass MediaType ResiliencySettingName FaultDomainRedundancy Size FootprintOnPool StorageEfficiency
------------ --------- --------- -------------------- - --------------------- ---- --------------- --------- --------
M. Acc. Paritate-NVMe-Tier Performance SSD Mirror 1 215 GB 430 GB 50,00 %
NVMe-Tier Unknown SSD Mirror 1 0 B 0 B
HDD-Tier Paritate HDD necunoscută 1 0 B 0 B
M. Acc. Paritate-HDD-Tier Capacitate HDD Paritate 1 6 TB 9 TB 66,67 %

Dar problema cu care mă confrunt acum: când trec datele în acel spațiu de stocare pe niveluri, pot vedea din contorul de performanță că nivelul rapid raportează o utilizare de 85% și începe să distrugă fișierele la nivelul lent. după ce am mutat ceva de genul 40-50GB pe discul virtual.

M-am gândit la posibilele motive pentru asta de câteva zile, poate are cineva o idee despre asta?

Gândul meu actual: SSD-urile NVMe sunt - după cum am menționat - destul de ieftine, deci sunt TLC-SSd-uri. Ele pot oferi o performanță destul de bună, atâta timp cât funcționează în modul pSLC. Cu toate acestea, asta ar irosi 67% din capacitatea discului (1 bit per celulă în loc de 3) - și asta s-ar potrivi cu observația mea (33% din 220 GB ar fi ~ 71 GB, așa că atingem 85% din utilizarea totală destul de repede)

Ei bine, nu m-ar deranja dacă nivelul rapid este atât de mic, dar pe de altă parte nu trebuie să se ocupe de performanța TLC lentă - dar de ce este raportată dimensiunea nivelului ca 220 GB atunci? Și există o modalitate de a seta modul pSLC, sau este controlat de ReFS / făcut prin tăiere etc?

M-ar interesa în special ce cauzează blocarea discului în modul pSLC, după cum am înțeles, discul ar trebui să treacă automat în modul TLC, odată ce rămâne fără spațiu disponibil pe disc.(Dar am citit și că MS a dezactivat tăierea cu ReFS, poate legat de asta?)

Pare să fie intenționat sau de ce ReFS-PerformanceCounter știe despre nivelul actual de umplere rapidă, dacă ReFS ar presupune și un disc de 215 GB?

Exemplu-captură de ecran: scrierea a 8 GB la nivelul rapid, având 8 GB de alte date destabilizate, înainte ca cei 8 GB să fie șterse din nou din nivelul rapid. arată ca 8GB = 10%, așa că ReFS vede nivelul ca ~ 80GB aș spune.

introduceți descrierea imaginii aici

  • Windows Server 2019 Standard
  • Construind acest laborator pe două noduri, puteți vedea exact același comportament pe ambele noduri. (hardware identic)

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.