Areca to Areca RAID 5 array snelheid dropt naar 0

[Operations]

Ik heb hier twee verschillende machines met een Areca 1882i (8 ports), de machines zijn direct verbonden met een Mellanox Connectx-3. Beide hebben een RAID5 Array, de ene met 8x2TB en de andere met 8x3TB. De kaarten (Areca en Mellanox) zitten op een PCI-E 3.0 x8 slot.

Het probleem is wanneer ik veel data kopieer van de ene naar de andere server de snelheid steeds dropt naar 0. De snelheid loopt op naar ongeveer 900 MB/s, en dan na een paar seconden loopt de snelheid terug naar 0. Vervolgens loopt de snelheid na een paar seconden weer op naar ongeveer 900MB/s.

Maar niet uit of ik vanaf 1 naar 2 of 2 naar 1 kopieer.

Write Back of Write Through maakt geen verschil. Aan beide kaarten hangt geen BBU, de machines hangen wel aan een UPS. HDD Cache en Disk Write Cache mode staan beide aan.

De machines zijn vrij rustig geen 100% cpu of memory ofzo. Machines zijn beide Xeon machines (8c 16t en 10c 20t)met ruim voldoende geheugen.

Crystal disk Benchmark (1GB) toont ergens tussen de 800-900 MB/s (SEQ Q32T1).

Het zou iets met de cache te maken kunnen hebben, maar dan zou ik verwachten dat Write Through het probleem zou oplossen. Althans dan zou de snelheid misschien wel iets omlaag gaan, maar zou het wel constanter moeten zijn....toch?

Iemand een idee?

[rookie no. 1]

Eerste wat ik denk is dat de cache dan vol zit, alhoewel een drop naar 0 dan ook niet logisch is eigenlijk.

Heb je op geen van de hdd's bad - of pending sectors?

Geen mix van 4kb en 512b sector disks?

Zijn de arrays leeg (te maken) en om te zetten naar RAID10 als test? Overigens zou ik zelf nooit RAID5 doen op deze schijf grootte en zoveel in een array...

Wat is het OS wat er op draait?

[Operations]

Windows server 2016.

Voor zover ik weet is wanneer je "Write Trhough" gebruikt de cache niet relevant meer. Gaat direct naar de array. Daarom is het ook langzamer dan "Write Back". Maar zoals ik zei beide opties maakt geen verschil. Maar is wel waar ik ook aan dacht....

Het is raid5 (scheelt 1 schijf, anders past het net niet) omdat het de backup van de backup is (draait ook niet 24/7, wordt alleen aangezet voor de backup en daarna afgesloten).

Primaire array draait op een 1882ix kaart met 10x4TB in RAID6. Nee allemaal dezelfde schijven, en voor zover de controller kan uitlezen zijn er geen problemen met de schijven.

Leeg maken... je wil beide arrays leegmaken en dan kijken of er met RAID10 hetzelfde gebeurt? Maar wat zegt dat dan? Op zich kan alles maar is wel wat lastig te realiseren. Maar de lokale benchmark van Crystal disk benchmark laat toxh al zien dat het lokaal goed gaat?

Ik heb nog de primaire machine, ik kan met wat kleine aanpassingen wel proberen of ik kan uitsluiten of het aan server 1 of 2 ligt. Bedenk ik mij net.

[ Voor 50% gewijzigd door Operations op 30-04-2019 21:40 ]

[belrpr]

Klinkt als cache die vol is en dan pas schijven opstart.

Zet cache eens af en wordt het dan slechter of beter?

Probeer ook eens een schijf als passthrough.

[Operations]

belrpr schreef op dinsdag 30 april 2019 @ 21:42:
Klinkt als cache die vol is en dan pas schijven opstart.

Zet cache eens af en wordt het dan slechter of beter?

Probeer ook eens een schijf als passthrough.

Write Back of write Through maakt geen verschil... schijf als passthrough ? Hoe bedoel je dat? Draait geen ESXi ofzo tussen.

[johnkeates]

Je zal eerst wat meer moeten meten. Dat er Areca RAID kaarten en Mellanox interfaces in zitten zegt niet zo veel, alleen de theoretische maximale throughput. RAID5 betekent dat je afhankelijk van je workload een performance penalty hebt die groter wordt tijdens lezen.

Je kan ook eerst elementen uitsluiten voor dat je een deep dive doet, bijv. door lokaal naar een RAMdisk te schrijven en kijken of dat wel sustained speeds heeft. Hetzelfde kan je met je interfaces doen. Daarna kan je kijken of het aan je SAN of NAS protocol ligt (weet niet wat je precies doet, staat niet in je post), en wat je CPU en RAM doen.

[Operations]

johnkeates schreef op dinsdag 30 april 2019 @ 21:45:
Je zal eerst wat meer moeten meten. Dat er Areca RAID kaarten en Mellanox interfaces in zitten zegt niet zo veel, alleen de theoretische maximale throughput. RAID5 betekent dat je afhankelijk van je workload een performance penalty hebt die groter wordt tijdens lezen.

Je kan ook eerst elementen uitsluiten voor dat je een deep dive doet, bijv. door lokaal naar een RAMdisk te schrijven en kijken of dat wel sustained speeds heeft. Hetzelfde kan je met je interfaces doen. Daarna kan je kijken of het aan je SAN of NAS protocol ligt (weet niet wat je precies doet, staat niet in je post), en wat je CPU en RAM doen.

Ramdisk kan ik maken en testen. En dan Array => Ramdisk kopiëren of andersom? CPU en RAM komen niet boven 50% niks tijdens het kopiëren.

Hoe bedoel je SAN of NAS protocol?

[belrpr]

Operations schreef op dinsdag 30 april 2019 @ 21:44:
[...]


Write Back of write Through maakt geen verschil... schijf als passthrough ? Hoe bedoel je dat? Draait geen ESXi ofzo tussen.

Passthrough is de disk rechtstreeks beschikbaar te maken in het os. Dus als sata / sas

[Operations]

belrpr schreef op dinsdag 30 april 2019 @ 21:50:
[...]

Passthrough is de disk rechtstreeks beschikbaar te maken in het os. Dus als sata / sas

Een losse disk aan de controller hangen geeft uiteraard minder snelheid, maar wel constant.

[Operations]

Ben nu hier naar aan het kijken, tip van @Vorkie :
https://community.mellano...o-for-windows-2012-server

Kijken of dit verschil maakt.

[_JGC_]

In welke PCI-e slots heb je die insteekkaarten zitten? Zitten die rechtstreeks aan de CPU, of via de chipset?

[Operations]

_JGC_ schreef op dinsdag 30 april 2019 @ 22:14:
In welke PCI-e slots heb je die insteekkaarten zitten? Zitten die rechtstreeks aan de CPU, of via de chipset?

Dat zou ik niet weten, hoe kom ik daar achter anders dan via de manual?

[Wim-Bart]

Je weet dat maximale schrijfsnelheid bij raid 5 gelijk is aan het aantal disks van je raid set minus de parity disks. Dus 8 disks van 115MB/s is maximale performance van 7x115MB/s. Dus dat je pieken hebt naar 900 MB/s wil alleen maar zeggen dat er naar 8 disks worden beschreven. Het gedrag wat je ziet heeft te maken met je stripe size. De parity wordt namelijk over de stripe size berekend. In het meest slechte geval, is de data zo weinig dat alle disks ook nog eens gelezen moeten worden om nieuwe parity te berekenen. Het gevolg is dat je de schrijf acties kan wegzetten als een soort zaagtand grafiek en in windows lijkt het alsof het maar langzaam op gang komt.

Ideaal = Stripe size = Cluster size/(disks-parity disk). maar nooit groter dan ideale waarde.

Voorbeeld voor bijvoorbeeld SQL server of Exchange op RAID 5. Ideale Cluster size is 64KB, zonder enige discussie. In een Raid 5 kan ne in dit geval altijd het beste oneven aantal disks hebben, bijvoorbeeld 5,7 of 9. Bij 9 disks is dan de ideale stripe size 64/8=8KB (bij write-thru, dus zo der cache) bij cache kan dit meer zijn, mits de cache voldoende groot is om (aantal disks * stripe size) * 2 in cache te houden.

[Operations]

Nou het probleem is opgelost. Ik heb de Areca kaarten nogmaals uit de machine gehaald en weer terug gestoken. Ik heb de kabel nogmaals vervangen voor een andere nieuwe kabel. En nu is het prpbleem weg, ik begrijp er weinig van. Ik heb deze handelingen namelijk al veel eerder gedaan.., Maar goed ben blij dat het weer werkt. Dank allemaal!

De snelheid is nu constant vanaf het eerste moment mits het bestand uiteraard groot genoeg. Anders is het bestand natuurlijk al gekopieerd voordat de maximale snelheid bereikt wordt

@Wim-Bart ,
De snelheid is overigens nu het contant is tussen de 700-800 MB/s, zeg maar conform het eerste stuk van jouw verhaal.

Maar wat zou de ideale setup dan zijn voor mijn primaire array?
Het is een RAID6 Array met 10x4TB op een Areca 1882ix met 4GB (Write Back, zonder BBU met UPS). Stripe Size staat nu op 64KBytes, cluster op 4096 bytes (gewoon bij windows format is dat toch?) Maar volgens de formule zou mijn stripe size dan toch 512KBytes moeten zijn? Ja of cluster size staat helemaal verkeerd op dit moment...

Maar nu past het allemaal toch netjes binnen de 4GB cache? Is het dan niet beter om het zo uit te rekenen dat ik meer van de cache kan gebruiken? Dus dichter tegen de 4GB aan zou moeten willen zitten?

Huidige situatie:
512 (stripe) = 4096(cluster) /8(10 disk - 2 parity disks)
(8 * 64) * 2 = 1024

Het is een Array die voor van alles en nog wat wordt gebruikt qua data. Van grote films tot VeeAM backups tot Word documenten. Geen virtual machines, die staan op een RAID10 array bestaande uit SSD's. (Wat zouden dan trouwens meeste geschikte instellingen voor die Array zijn?)

Nogmaals dank allemaal, ben blij dat het probleem verdwenen is

[ Voor 22% gewijzigd door Operations op 01-05-2019 17:04 ]

[Wim-Bart]

Operations schreef op woensdag 1 mei 2019 @ 16:47:
Nou het probleem is opgelost. Ik heb de Areca kaarten nogmaals uit de machine gehaald en weer terug gestoken. Ik heb de kabel nogmaals vervangen voor een andere nieuwe kabel. En nu is het prpbleem weg, ik begrijp er weinig van. Ik heb deze handelingen namelijk al veel eerder gedaan.., Maar goed ben blij dat het weer werkt. Dank allemaal!

De snelheid is nu constant vanaf het eerste moment mits het bestand uiteraard groot genoeg. Anders is het bestand natuurlijk al gekopieerd voordat de maximale snelheid bereikt wordt

@Wim-Bart ,
De snelheid is overigens nu het contant is tussen de 700-800 MB/s, zeg maar conform het eerste stuk van jouw verhaal.

Maar wat zou de ideale setup dan zijn voor mijn primaire array?
Het is een RAID6 Array met 10x4TB op een Areca 1882ix met 4GB (Write Back, zonder BBU met UPS). Stripe Size staat nu op 64KBytes, cluster op 4096 bytes (gewoon bij windows format is dat toch?) Maar volgens de formule zou mijn stripe size dan toch 512KBytes moeten zijn? Ja of cluster size staat helemaal verkeerd op dit moment...

Maar nu past het allemaal toch netjes binnen de 4GB cache? Is het dan niet beter om het zo uit te rekenen dat ik meer van de cache kan gebruiken? Dus dichter tegen de 4GB aan zou moeten willen zitten?

Huidige situatie:
512 (stripe) = 4096(cluster) /8(10 disk - 2 parity disks)
(8 * 64) * 2 = 1024

Het is een Array die voor van alles en nog wat wordt gebruikt qua data. Van grote films tot VeeAM backups tot Word documenten. Geen virtual machines, die staan op een RAID10 array bestaande uit SSD's. (Wat zouden dan trouwens meeste geschikte instellingen voor die Array zijn?)

Nogmaals dank allemaal, ben blij dat het probleem verdwenen is

Alles staat goed. Het is een Raid 6. Dus een even aantal disks. Ideaal. Je hebt cache en dat is al goed. 10x64K past makkelijk in je cache van je controller dus vandaar dat je geen dips hebt. Ideaal dus. Had je geen cache was het een ander issue.

[Operations]

Wim-Bart schreef op woensdag 1 mei 2019 @ 19:28:
[...]


Alles staat goed. Het is een Raid 6. Dus een even aantal disks. Ideaal. Je hebt cache en dat is al goed. 10x64K past makkelijk in je cache van je controller dus vandaar dat je geen dips hebt. Ideaal dus. Had je geen cache was het een ander issue.

Maar volgens de formule kom ik toch op Stripe Size van 512KB uit? Maar "(8*512) * 2 = is 8192" dus dat zou dan weer niet in de cache (4GB) passen toch....?

En die RAID5 Arrays (zijn nu dan nog 8 schijven, maar dat zou ik kunnen aanpassen) bevatten dezelfde data. De kaarten (1882i-8g) hebben 1GB cache.

Zou daar de beste opstelling zo zijn:

682 (stripe) = 4096(cluster) /6 (7 discs - 1 parity disk)
(6 * 512) * 2 = 6144 (Past dus ook niet in de cache van 1GB)

682KB bestaat niet zou ik dan 512 of 1024 moet kiezen, maar dat past dus ruimschoots niet in de cache. Ik heb het toch nog niet helemaal helder op mijn netvlies denk ik....

[Wim-Bart]

Operations schreef op woensdag 1 mei 2019 @ 21:01:
[...]


Maar volgens de formule kom ik toch op Stripe Size van 512KB uit? Maar "(8*512) * 2 = is 8192" dus dat zou dan weer niet in de cache (4GB) passen toch....?

En die RAID5 Arrays (zijn nu dan nog 8 schijven, maar dat zou ik kunnen aanpassen) bevatten dezelfde data. De kaarten (1882i-8g) hebben 1GB cache.

Zou daar de beste opstelling zo zijn:

682 (stripe) = 4096(cluster) /6 (7 discs - 1 parity disk)
(6 * 512) * 2 = 6144 (Past dus ook niet in de cache van 1GB)

682KB bestaat niet zou ik dan 512 of 1024 moet kiezen, maar dat past dus ruimschoots niet in de cache. Ik heb het toch nog niet helemaal helder op mijn netvlies denk ik....

Sorry, ik was uit gegaan van RAID6 met 10 disks = 8 data disks + 2 parity en een stripe van 64KB en een cache van 4GB.

Ik heb even een vegissing gemaakt met betreffing tot een Stripe, onder RAID 5 en RAID 6 is het ietsje anders dan RAID 1.

Een Stripe van 512 past eenvoudig in je cache. Het meest optimale is dat je een even aantal data disks hebt in je array, dus met RAID 5 oneven aantal disks en RAID 6 even aantal disks.

Bij een cluster van 4KB passen er dus in een 512KB stripe dus 128 clusters, bij een cluster size van 64KB 8 clusters in een stripe. Parity wordt berekend over een stripe, Dus de winst zit in het aantal malen dat parity berekend moet worden. Hoe groter het clustersize, hoe minder berekeningen en rereads nodig zijn bij een cache mis.

Ik weet niet of de Arcea het kan, maar een Stripe van 64KB of 128KB bij een cluster size van 4KB is veel effectiever.

[Operations]

Wim-Bart schreef op donderdag 2 mei 2019 @ 13:30:
[...]


Sorry, ik was uit gegaan van RAID6 met 10 disks = 8 data disks + 2 parity en een stripe van 64KB en een cache van 4GB.

Ik heb even een vegissing gemaakt met betreffing tot een Stripe, onder RAID 5 en RAID 6 is het ietsje anders dan RAID 1.

Een Stripe van 512 past eenvoudig in je cache. Het meest optimale is dat je een even aantal data disks hebt in je array, dus met RAID 5 oneven aantal disks en RAID 6 even aantal disks.

Bij een cluster van 4KB passen er dus in een 512KB stripe dus 128 clusters, bij een cluster size van 64KB 8 clusters in een stripe. Parity wordt berekend over een stripe, Dus de winst zit in het aantal malen dat parity berekend moet worden. Hoe groter het clustersize, hoe minder berekeningen en rereads nodig zijn bij een cache mis.

Ik weet niet of de Arcea het kan, maar een Stripe van 64KB of 128KB bij een cluster size van 4KB is veel effectiever.

@Wim-Bart ,

En even voor de zekerheid, met cluster size bedoel je toch gewoon de NTFS cluster size die je aangeeft als je de schijf formatteert? (4096 is het dan toch?)

[Wim-Bart]

Operations schreef op donderdag 2 mei 2019 @ 14:13:
[...]


@Wim-Bart ,

En even voor de zekerheid, met cluster size bedoel je toch gewoon de NTFS cluster size die je aangeeft als je de schijf formatteert? (4096 is het dan toch?)

Yep.

[Operations]

Wim-Bart schreef op donderdag 2 mei 2019 @ 14:14:
[...]


Yep.

Okee dan stond mijn RAID6 Array inderdaad al wel goed (10 disks/Stripe 64/Cluster 4096)

[Operations]

Wim-Bart schreef op donderdag 2 mei 2019 @ 13:30:
[...]


Sorry, ik was uit gegaan van RAID6 met 10 disks = 8 data disks + 2 parity en een stripe van 64KB en een cache van 4GB.

Ik heb even een vegissing gemaakt met betreffing tot een Stripe, onder RAID 5 en RAID 6 is het ietsje anders dan RAID 1.

Een Stripe van 512 past eenvoudig in je cache. Het meest optimale is dat je een even aantal data disks hebt in je array, dus met RAID 5 oneven aantal disks en RAID 6 even aantal disks.

Bij een cluster van 4KB passen er dus in een 512KB stripe dus 128 clusters, bij een cluster size van 64KB 8 clusters in een stripe. Parity wordt berekend over een stripe, Dus de winst zit in het aantal malen dat parity berekend moet worden. Hoe groter het clustersize, hoe minder berekeningen en rereads nodig zijn bij een cache mis.

Ik weet niet of de Arcea het kan, maar een Stripe van 64KB of 128KB bij een cluster size van 4KB is veel effectiever.

@Wim-Bart ,

Wat ik nog even niet begrijp is dat je zegt dat stripe van 512 in mijn cache past.

RAID 5 setup 7x3TB:

682 (stripe) = 4096(cluster) /6 (7 discs - 1 parity disk)
(6 * 512) * 2 = 6144 (Past dus ook niet in de cache van 1GB) stripe 512 gekozen omdat 682 niet mogelijk is.

6144 past toch niet in 1GB cache ?

Net als bij mijn RAID 6
RAID 6 setup 10x4TB:

512 (stripe) = 4096(cluster) /8(10 disk - 2 parity disks)
(8 * 512) * 2 = 8192

8192 past toch niet in 4GB cache?

[ Voor 14% gewijzigd door Operations op 10-05-2019 15:13 ]

[Wim-Bart]

Operations schreef op vrijdag 10 mei 2019 @ 15:07:
[...]


@Wim-Bart ,

Wat ik nog even niet begrijp is dat je zegt dat stripe van 512 in mijn cache past.

RAID 5 setup 7x3TB:

682 (stripe) = 4096(cluster) /6 (7 discs - 1 parity disk)
(6 * 512) * 2 = 6144 (Past dus ook niet in de cache van 1GB) stripe 512 gekozen omdat 682 niet mogelijk is.

6144 past toch niet in 1GB cache ?

Net als bij mijn RAID 6
RAID 6 setup 10x4TB:

512 (stripe) = 4096(cluster) /8(10 disk - 2 parity disks)
(8 * 512) * 2 = 8192

8192 past toch niet in 4GB cache?

Je stipe is 512KB verdeeld over de data disks. Dus niet PER disk.

[Operations]

Wim-Bart schreef op vrijdag 10 mei 2019 @ 16:09:
[...]

Je stipe is 512KB verdeeld over de data disks. Dus niet PER disk.

Maar hoe moet ik dat dan zien ten opzichte van deze formule?

"(aantal disks * stripe size) * 2 in cache te houden."

[Wim-Bart]

Operations schreef op vrijdag 10 mei 2019 @ 16:12:
[...]


Maar hoe moet ik dat dan zien ten opzichte van deze formule?

"(aantal disks * stripe size) * 2 in cache te houden."

Die kan je vergeten, dat was een fout

[Operations]

Wim-Bart schreef op vrijdag 10 mei 2019 @ 16:14:
[...]


Die kan je vergeten, dat was een fout

Hahaha okee dat is de helder.
Maar hoe bereken je dan of je voldoende cache geheugen hebt?

512 (stripe) = 4096(cluster) /8(10 disk - 2 parity disks)

Deze formule is wel correct toch?
Heb nu mijn stripe size nog op 64 staan maar conform bestaande formule moet die dus eigenlijk op 512 staan dan toch?

[ Voor 30% gewijzigd door Operations op 10-05-2019 16:21 ]

[Wim-Bart]

Operations schreef op vrijdag 10 mei 2019 @ 16:18:
[...]


Hahaha okee dat is de helder.
Maar hoe bereken je dan of je voldoende cache geheugen hebt?

512 (stripe) = 4096(cluster) /8(10 disk - 2 parity disks)

Deze formule is wel correct toch?
Heb nu mijn stripe size nog op 64 staan maar conform bestaande formule moet die dus eigenlijk op 512 staan dan toch?

Je stripe is 64KB. Dit is dus bij 8 disks een blokje van 64KB/8. Is dus 4KB per disk. Dus bij RAID 6 heeft je controller dus 10*4KB nodig. Sommige controllers willen dat 2 keer hebben maar dat is niet zo erg.

Je contoller heeft 1GB cache, dat wil zeggen dat hij (1*1024*1024) KB ruimte heeft. Hij heeft per stripe 40KB nodig. Dus meer dan voldoende.

Je moet even rekening houden met KB, MB, GB dus.

[Operations]

Wim-Bart schreef op vrijdag 10 mei 2019 @ 16:35:
[...]


Je stripe is 64KB. Dit is dus bij 8 disks een blokje van 64KB/8. Is dus 4KB per disk. Dus bij RAID 6 heeft je controller dus 10*4KB nodig. Sommige controllers willen dat 2 keer hebben maar dat is niet zo erg.

Je contoller heeft 1GB cache, dat wil zeggen dat hij (1*1024*1024) KB ruimte heeft. Hij heeft per stripe 40KB nodig. Dus meer dan voldoende.

Je moet even rekening houden met KB, MB, GB dus.

Ja dat snap ik maar 512KB stripe size past dus volgens mij ook in de cache (die is 4GB op de RAID6 array)
Als ik jouw logica volg:

512KB/8=64
10*640KB= 640 KB (of 2x zoveel is 1,28MB)

Weet ik alleen even niet hoe deze formule eruit (1*1024*1024) er dan uit komt te zien. 1*1024*4096? Als dit de juiste formule is dan komt je met de bovenstaande formule uitkomst (640KB) toch nooit in de buurt van 1 laat staan 4GB? Veel minder cache zou dan toch al volxoende zijn?

Mijn vraag is dus kort door de bocht is 512KB stripe size dan niet beter dan 64KB? Als je zoals in dit geval 4GB cache hebt.

(Excuus dat het wat lang duurt voordat we bij de juiste uitkomst zijn, zal ongetwijfeld aan mij liggen )

[ Voor 5% gewijzigd door Operations op 10-05-2019 17:43 ]

[Wim-Bart]

Operations schreef op vrijdag 10 mei 2019 @ 17:36:
[...]


Ja dat snap ik maar 512KB stripe size past dus volgens mij ook in de cache (die is 4GB op de RAID6 array)
Als ik jouw logica volg:

512KB/8=64
10*640KB= 640 KB (of 2x zoveel is 1,28MB)

Weet ik alleen even niet hoe deze formule eruit (1*1024*1024) er dan uit komt te zien. 1*1024*4096? Als dit de juiste formule is dan kom ik toch min of meer op 4GB uit?

Mijn vraag is dus kort door de bocht is 512KB stripe size dan niet beter dan 64KB? Als je zoals in dit geval 4GB cache hebt.

(Excuus dat het wat lang duurt voordat we bij de juiste uitkomst zijn, zal ongetwijfeld aan mij liggen )

Ligt aan je Cluster size. Hoe groter je Stripe hoe meer clusters er in passen. Even de volgende situatie:

Stripe is 512KB
Cluster is 4KB
Disks is 10

Je schrijft een bestand weg van 1 of 2 clusters. Bijvoorbeeld een word documentje, Wat gebeurd er:

1. Je controller ontvangt een lees opdracht (bit table van je volume) en moet dus alle 10 disks lezen. Doet een check van de checksums en geeft de data terug aan het OS.
2. Je controller ontvangt een schrijf opdracht van 2 clusters, om deze twee clusters te schrijven moet de controller een complete stripe+parity lezen, dus de complete 512KB+parity disks.
3. Je controller maakt een kopie en vervangt 2 x 4K en berekend de nieuwe parity
4. Je controller schrijft twee 4K blokken + complete parity blokken terug naar de disks.
5. Stap 2 t/m 4 doet hij ook voor de update van de Filetable (die hopenlijk nog in cache zit).

Dus hoe groter de stripe, hoe meer data er gelezen moet worden voordat er een schrijf actie plaats kan vinden.

Grote stripes heeft dus alleen voordeel wanneer het OS grote blokken weg schrijft. Maar bij random I/O gaat een grote stripe je tegen zitten. Daarnaast is de kans dat er al data in je cache zit veel groter bij een kleine stripe dan een grote stripe. Overigens maakt het natuurlijk wel uit wat voor gedrag de Applicatie heeft.

[Operations]

Wim-Bart schreef op vrijdag 10 mei 2019 @ 17:51:
[...]


Ligt aan je Cluster size. Hoe groter je Stripe hoe meer clusters er in passen. Even de volgende situatie:

Stripe is 512KB
Cluster is 4KB
Disks is 10

Je schrijft een bestand weg van 1 of 2 clusters. Bijvoorbeeld een word documentje, Wat gebeurd er:

1. Je controller ontvangt een lees opdracht (bit table van je volume) en moet dus alle 10 disks lezen. Doet een check van de checksums en geeft de data terug aan het OS.
2. Je controller ontvangt een schrijf opdracht van 2 clusters, om deze twee clusters te schrijven moet de controller een complete stripe+parity lezen, dus de complete 512KB+parity disks.
3. Je controller maakt een kopie en vervangt 2 x 4K en berekend de nieuwe parity
4. Je controller schrijft twee 4K blokken + complete parity blokken terug naar de disks.
5. Stap 2 t/m 4 doet hij ook voor de update van de Filetable (die hopenlijk nog in cache zit).

Dus hoe groter de stripe, hoe meer data er gelezen moet worden voordat er een schrijf actie plaats kan vinden.

Grote stripes heeft dus alleen voordeel wanneer het OS grote blokken weg schrijft. Maar bij random I/O gaat een grote stripe je tegen zitten. Daarnaast is de kans dat er al data in je cache zit veel groter bij een kleine stripe dan een grote stripe. Overigens maakt het natuurlijk wel uit wat voor gedrag de Applicatie heeft.

Okee dat is ook een helder verhaal. Maar wat zou dan jouw suggestie zijn voor een array waarop van alles en nog wat staat maar het grootste deel is toch wel paar 100 MB of groter. Toch gewoon 64KB Stripe size en 4KB cluster (volgens jouw verhaal en dan met namelijk de conclusie zou ik zeggen groter stripe size dan 64)? En hebben het steeds over stripe size is in de genoemde situatie niet een andere cluster size aan te bevelen?

[ Voor 5% gewijzigd door Operations op 10-05-2019 18:09 ]

[Wim-Bart]

Operations schreef op vrijdag 10 mei 2019 @ 17:59:
[...]


Okee dat is ook een helder verhaal. Maar wat zou dan jouw suggestie zijn voor een array waarop van alles en nog wat staat maar het grootste deel is toch wel paar 100 MB of groter. Toch gewoon 64KB Stripe size en 4KB cluster? En hebben het steeds over stripe size is in de genoemde situatie niet een andere cluster size aan te bevelen?

Ligt aan je beatanden. Hoe groter je cluster, hoe meer verspilling. Je C: is niet voor niets 4KB clustersize om te voorkomen dat er heel veel diskruimte verspilt wordt.

Een bestand kan uit meerdere clusters bestaan, maar een cluster kan niet meerdere bestanden bevatten.

Een voorbeeld: Windows folder is 20GB, bij een cluster van 64KB zou deze tegen de 100G aanlopen waarbij er heel veel disk ruimte gevuld is met "niks".

Overigens om meer te leren over NTFS is deze site wel aan te raden: http://www.ntfs.com/ntfs_optimization.htm

[Operations]

Wim-Bart schreef op vrijdag 10 mei 2019 @ 18:14:
[...]


Ligt aan je bestanden

Wat is daarbij nog meer van belang anders dan formaat? (Voornamelijk groter dan paar 100 MB)

Ik vraag dat omdat je op mijn vraag als antwoord geeft "ligt aan je bestanden". Op basis van jouw verhaal zou ik namelijk bijna concluderen dat het feit dat het grote bestanden zijn genoeg reden zou zijn om te kiezen voor een groter cluster size.

Die site ga ik is even bekijken.

Ik zal aan de hand hiervan is kijken wat dan ongeveer juiste cluster size zou moeten zijn:

The simplest (but rough) way is to divide number of files on the drive by total disk usage in kilobytes.

[ Voor 16% gewijzigd door Operations op 10-05-2019 18:36 ]