- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Alapértelmezett konfiguráción sok Core CPU-nak lehet stabilitási gondja
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Épített vízhűtés (nem kompakt) topic
- E-Book Off topic
- Bambu Lab X1/X1C, P1P-P1S és A1 mini tulajok
- OLED TV topic
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- Fujifilm X
- ThinkPad (NEM IdeaPad)
Hirdetés
-
Képeken az egyik kameráját elvesztő Sony Xperia 10 VI
ma Részletes anyag került fel az internetre a Sony idei középkategóriás telefonjáról, három helyett két hátlapi kamera várható.
-
Mebírságolták a Razert a Zephyr maszkok miatt
ph A cég elég olcsón megússza az ügyfelei félrevezetését, de az üdvözlendő, hogy az Egyesült Államok hatóságai nem siklottak el az ügy felett.
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
Új hozzászólás Aktív témák
-
-
#64791808
törölt tag
A világért sem szeretnék személyeskedni, de a raid-del kapcsolatos leírásodban annyi a csúsztatás, hogy meg lehet vele verni a jamaikai bobcsapatot.
1., Amatőr RAID-vezérlőknél tehát - az Adaptec 80 ezres SATA RAID5/6 vezérlőket leszámítva - minden ATA alapú RAID-vezérlőnél eleve nem beszélünk sebességtöbbszörözésről, mivel egy mocskosul nem erre kifejlesztett technológiára húzzuk rá a RAID-et.
2., Mi a RAID első betűje? Redundant. Innentől kezdve a RAID0-t ne vegyük a raidek közé, mert nem az, striping, és mint ilyen, teljesítménynövelő.
3., Két merevlemez RAID-be kötésével duplázódik a meghibásodási esély. Ami 0,01% 3 éven belül. Duplázzuk meg, tehát akkor 0,02%. Hát azért ezen elmélkedjünk.
4., RAID1 esetében az írási sebesség kicsit alacsonyabb a single módénál, ellenben párhuzamosan olvas két vinyóról, tehát olvasásnál 1,6-1,8x sebesség érhető el.
5., RAID0 - rakjunk össze két kisvinyót, de ezt a windows nem szereti. Mi az, hogy nem szereti? Ő lát egy olyan eszközt, hogy XY Raid0 SCSI Disk, és tojik rá, hogy az konkrete mi.
6., Amennyiben a RAID0 esetében az olvasás nálad processzorlimites kolléga, akkor cseréld le a 333-as celeront. Ehhez mást nem tudok hozzáfűzni. Alattam egy 3600-as P4 döcög, RAID0, és nem kimutatható a processzorhasználat full írás közben.
7., Két 20-as vinyót RAID0-ba kötni marhaság? Hát szerintem gyorsabb, mint ketten szólóban. De mért kötnék két 20-as vinyót raid0-ba, ha megtehetem, hogy mást kötök abba? Két 120-as vinyó, és az elejére egy 8 gigás partíció. Ez azt jelenti, hogy mindkét vinyó elején használok 4 gigát. Az azutáni területet meg felosztom további részekre. EZ mért nem kivitelzhető?
8., Egy dolog nem tiszta: a windows dinamikus lemezkezelőjével létrehozott raidről beszélünk, tehát softraidről, vagy raid kártyáról? A dolgok az utóbbira vonatkoztak. Előbbinél: Windows XP eleve nem tud tükrözni (RAID1). A rendszerpartíciódat meg hiába konvertálod dinamikus kötetté, nem tudsz RAID0-t létrehozni.
Szóval két kérdés van: egyik, hogy mi a cél, másik, hogy mennyi a ráfordítható összeg.
Ha a lóvé sok, akkor venni kell egy Adaptec U320 SCSI RAID vezérlőt, és 8 lemezzel RAID6-ot csinálni, jó kvázi mindenre. GOndolom nem ez a helyzet. Namost ha van NÉGY egyforma vinyó, akkor kell egy RAID5 képes kártya, az a legjobb. Ha van három, akkor is eljátszható, csak nem lesz bitanggyors. Ha meg össze-vissza vannak vinyók, akkor meg a RAID szóba sem jön, csak bonyolítja a helyzetet.
Várom a kérdéseket. -
#64791808
törölt tag
válasz lazydog #1423 üzenetére
Szia,
megtisztelsz, hogy a véleményemet kéred.
Nos hát van itt pár dolog.
1., Az ATA szabvány nem optimális komoly raidre. Ezt a következőképpen értem: meg lehet rajta csinálni, és az esetek többségében semmi gond nincsen, de az ATA vezérlést nem erre találták ki. Ugyanis egy RAID5 vagy RAID6 nem egyszerűen irogat, olvasgat, hanem számolja a paritásbiteket, leválasztgat, stb. RAID1 és Striping esetén nem lehet gond, egyébként nem zárható ki. Érsd: nincs vele gond, de nem optimális megoldás.
2., Ugye mitől kezdett el panaszkodni, hogy hibás az egyik drive? A melegedéstől nem hiszem, mert egy hdd optimális hőmérséklete 40 fok környékén van, 50 fok sem akkora gond. Itt arról van szó, hogy pl TARTÓSAN 60 fok és afelett már nem jó neki, gyorsan kifekszik. De ilyen hőmérsékletet csak egyfolytában dolgozva ér el, márpedig ha nem fájlszerver a kicsike, akkor SOHA. Tehát elvi esélye van, én gyakorlatban nem hinném, hogy a meleg miatt szállt el.
3., Akkor mitől? A RAID5 vezérlés igen kis időközönként nyúlkál a merevlemezekhez, paritásbiteket írkál, ellenőríz például, tehát akkor is keresi a lemezt, ha te éppen nem dolgozol a géppel. Ehhez hozzá kell venni a ''miért nem optimális RAID5-ra az ATA'' című fejezetet: az ATA felület a következőképpek kommunikál. Kimegy a lekérdezés/parancs a vinyó felé, és várunk, hogy jöjjön rá válasz, és addig figyeljük a buszt. Van egy timeout időtartam, amin beül ha nem jön válasz, akkor hiba van. Addig a busz foglalt. Ezzel szemben a SCSI kiküldi a parancsot és utána szarik rá, majd megjön az. Meg utánaküld még egy rakással, hadd szóljon. Aztán összegez, hogy honnan mi nem jött meg. A lényeg: a SCSI a késést nem értékeli hibaként, ha utána megjön a válasz, persze megjegyzi, hogy gond volt, és utána ''figyel'' rá. (Statisztikák szigorítása, lekéri a lemezadatokat, stb). Tehát a SCSI többlépcsős hibaérzékeléssel dolgozik, míg az ATA nem! Tehát ATA esetében vagy jó , vagy nem jó. Namost mivan, ha egy icipici érintkezési hiba vagy feszültségingadozás lépett fel? Bármelyik előfordulhat, és bármelyik ahhoz vezethet, hogy a kiküldött ATA parancsra a válasz KÉSIK. Ezt meg a vezérlőd azonnal hibaként értékeli, és nem használja azt a lemezt.
4., Folyomány: RAID5 esetében 1 lemez eshet ki. Egy kiesik, marad három, és a kötet onnan kezdve nem hibatűrő. Tehát ha mondjuk a fent említett feszültségingadozás miatt még egy ilyen pici hibácska van, akkor a kötet AZONNAL leáll.
5., Javaslatok: az a vezérlő tudomásom szerint tud RAID1+0 -t, érdemesebb azt használni, a sebesség nőni fog olvasás terén, viszont egy lemeznyivel kevesebb helyed lesz. További javaslatom: szerezz be egy szünetmentes tápot, és havonta ellnőrízd a kábelek csatlakozását a gépben. Hülyeség? Nem az, mert a hőingadozástól szép lassan mozoghatnak a műanyag alkatrészek, előfordulhat baj. Ha ezt megteszed, sztem használhatsz RAID5-ot.
6., Fontos: RAID2-től egyforma lemezeket kell használni. A kolléga igen figyelemreméltó okosságot mondott, hogy hát hoppá, ha beteszel pár kB-tal kisebb lemezt a régi helyére, azzal a vezérlő nem fog tudni mit kezdeni. Neki n kB-os képet kell kiírnia a lemezre, de azon csak n-64kB hely van.
7., Biztonsági tudnivaló. Ha szerencséd van, akkor egy 10 lemezes RAID0 tömbbel sem lesz gondod 4 évig. Ha meg peches vagy, akkor egy profi RAID6+1 rendszer is megdöglik alattad. Szóval a szerencsédet nem te vezérled
8., Én a te helyedben... Szóval a te helyedben én (ha anyagi lehetőségeim engedik) vennék egy 500 gigás szörnyeteget és egy külső USB házat, majd a durván 480 gigás RAID5 tömbömet hetente egyszer éjjel átmenteném rá. Nem kell semmi backup hókuszpókusz, csak copy. Majd elraknám jó mélyre.
Remélem tudtam segíteni, ha kérdés van, várom. -
#64791808
törölt tag
válasz liksoft #1424 üzenetére
Okés, köszi, már látom a konkrét kérdést, mely valahogy úgy szól, hogy érdemes-e RAID0-ba kötni két 160-as hdd-t.
1., Először is mit csinál a RAID0. Feloszt MINDEN adatot fix méretű csíkokra, és a csíkokat párhuzamosan írja a lemezre, illetve olvasssa onnan. Az előnye gondolom érthető, a hátránya pedig az, hogy ha bármelyik vinyó hal, akko az összes adat menthetetlenül elvész. Épp ezért iratlan szabály, hogy pl egy kétéves 120 gigás maxtort nem kötünk raid0-ba egy zsír új, szintén 120-as seagate-tel.
2., Kell-e RAID0? Mert ahogy liksoft kolléga precízen rávilágított: egyáltalán nem kell mindenkinek RAID0. Mire használod a tömböt? Ha sok a nagyméretű fájlod, amivel gyorsan kell dolgozni (pl photoshop többszáz megás képek, videószerkesztés) vagy pl nagy fájlokat kell betölteni a játékoz (pl Counter-Strike Source giga feletti gcf fájljai), akkor nagyon jól jön a RAID0. Ha viszont szinte csak kis fájlok vannak, vagy másolsz tömbön belül, vagy nagyon sok adatot mozgatsz ami miatt töredezett lesz a lemez, és előtérbe kerülnek a seek idők, akkor pl kifejezetten öngólt rúgsz raid0-val.
3., Marhára nem mindegy, milyen csíkokra osztassz. Egyszerűbb vezérlőknél 16 és 128k között oszthatsz, intelligensebbeknél 4-512k. Mért érdekes ez? Clustermérettől függetlenül a RAID vezérlő csak csíkot tud olvasni. Tehát ha neked 128k-s csíkozásod van, és két lemezes a tömb, és te egy 12kb-os fájlt akarsz beolvastatni, akkor hiába csak 12k a fájl, a rendszer2*128k-t be fog olvasni, feleslegesen. Tehát ha a nagy fájlok elérésén akarsz gyorsítani, akkor nagyobb csíkok kellenek, ha inkább a kisebbeken, akkor kisebbek.
4., A cache. Először is három féle cache-ről beszélhetünk. Első a merevlemez gyorsítótára. A második a RAID vezérlő memóriája, harmadik pedig az operációs rendszer által írási gyorsítótárnak használt memória. Sorjában. Az első ugyebár vinyószinten álíltható, és alapértelmezésben megy, nem is kell kikapcsolni, de ügyeskedés nélkül nem is nagyon lehet. A második, a RAID RAM az felsőbb RAID szinteknél fontos, egy kétlemezes RAID0 tömbnek kvázi mindegy, hogy van-e a vezérlőn ram. A harmadik az OS által használt RAM, ami arra való, hogy nem egyből a lemezre ír, hanem a memóriába erre a területre, és majd később írja a lemezre a cuccokat. Mára ez elég profi szintre fejlődött, alapértelmezetten be van kapcsolva és ez így jó is. Tehát a konkrét válasz: egy RAID0 tömb sebessége független a cache-ektől.
5., Hát akkor mitől függ? Először is attól, hogy a RAID-et mi vezérli. Szoftveresen meg lehet oldani windows alól. Nem javasolt, csak ha muszáj, mert lomha, és emellett használja a processzort. Lehet úgy, hogy RAID vezérlő van, de az csak az irányítást végzi, a darabolást és az ezzel kapcsolatos munkát a processzor csinálja. Napjainkban ez már amatőr szinten elégséges, jó, nem egy 500-as P3-mal kell RAID-et csinálni. Aztán van olyan, hogy a RAID vezérlő külön processzorral dolgozik, és saját ramja is van. Ez lesz a leggyorsabb. Aztán írtam, hogy függ a csíkmérettől. És végül nagyon, de nagyon függ a vinyóktól, pontosabban azok keresési időitől, melyek majd'minden esetben összeadódnak.
Ezek alapján végig kell gondolni, hogy kell az a RAID0 tömb nekem, vagy nem. MOndok mást. Le kell menteni az adatokat, és húzni egy tiszta rendszert RAID nélkül, majd RAID0 tömbre, és érezni, melyik gyorsabb telepítés, használat közben. Ugyanis mindegy hogy mért, de ha nem érzi az ember, hogy hú tebazzeg így mennyivel gyorsabb, akkor nem érdemes raid0-val kinlódni.
AZ én laptopomba két vinyó megy. Notivinyók lassúak, ezért csináltam raid vezérlővel RAID0-t. Ég és föld. Nekem megéri pl. Aki nem érzi a különbséget, az inkáb ne kinlódjon vele.
Ha kérdés van... -
#64791808
törölt tag
Most latom, hogy van ez a Topic.
Kulon koszonom, hogy mindenfele engedely nelkul a visszavont RAID-es irasaim vannak a Topic elejen. Kulon koszonom, hogy szoltatok errol, meg hogy megkoszontetek.
-
#64791808
törölt tag
válasz DrojDtroll #10059 üzenetére
Vezérlőtől függ. Szoftveresen mindenképp megoldható, és az Intel RST is tudja, beteszed az új vinyót, átállítod a vezérlőt RAID módra, és Windows alól az RST segédprogrammal megcsinálod a RAID1 tömböt. Fel fogja kínálni, hogy úgy hozza létre, hogy megtartsa a HDD adatait.
-
#64791808
törölt tag
válasz DrojDtroll #10061 üzenetére
-
#64791808
törölt tag
válasz kelna91 #10065 üzenetére
Ha 256 es 512 GB, akkor 960 Pro-ról beszélünk, mert az Evo az 250 és 500 GB.
Csakhogy 960Pro-ból nincs 256GB-os, 512 a legkisebb.
Rakható RAID-be, de értelme akkor és csak akkor lesz, ha olyan deszka van alatta, ami tud PCIe NVMe RAID-et. Mert ha nem, akkor szoftveresen vagy kénytelen megcsinálni, az a megoldás pedig ilyen sebességet nem tud lekezelni.
De: a RAID0 nagyon nem erre lett tervezve, könnyen elképzelhető, hogy tömbbe rakva alacsonyabb IOPS-t kapsz a tömbre, mint egyre szólóban. Lineáris átvitelre lehet értelme, de pl. az 512-es 960Pro-nak kb 2GBps az átvitele szekvenciális írásnál. Ezt nem nagyon akasztja meg semmi. Ha mondjuk 10Gbps etherneted lenne és másik SSD-ről másolsz rá, vagy van valami szörnyeteg RAID 6 tömböd ami olvas 800MBps-t, akkor ott eléred a végét.
Még egy dolog: lényegében az 1TB-os 960Pro az nagy vonalakban 2db 512-es belül. Ha megnézed a részletes speckókat, akkor a nagyobb másfélszer akkora IOPS-t tud, kétszer akkora a belső cache és a belső csatorna.
Tehát összességében nem teljesen elvetélt ötlet, de ahhoz, hogy valóban profitálj belőle, sok részletnek klappolnia kell.
Én a helyedben inkább vennék egy 250-es EVO-t rendszernek (szarásig elég), és egy 512/1TB-os Pro-t a többire, attól függően, hogy mennyi hely kell/mennyi az anyagi keret. És nem foglalkoznék a RAID-del.
-
#64791808
törölt tag
válasz kelna91 #10067 üzenetére
Namost ha evo-rol van szó, és nem pro-ról, akkor egy kicsit más a helyzet. Az Evo ugyanis alapverően 600MBps átvitelt tud, csak van benne egy SLC cache, ami marha gyors.
Én amúgy hasonló cipőben járok, a sok VM miatt vannak NVMe SSD-im, de a tapasztalat az, hogy 6-8 Windows Server közös munkája sem fog meg még egy evo-t sem.
Lehet olyat is csinálni, hogy két SSD van, de megosztod a VM-eket, egyiket ide, egyiket oda, így párhuzamosítasz.
Ezekkel együtt sem javasolnám a RAID0-t, nem fogod azt a teljesítményt megkapni, amit elvársz.
Itt egy részletes cikk, megpróbáltak két 950Pro-t összreakni RAID0-ba, elég felemás eredmény lett.
És van még egy dolog: driver. Ma a Samsung NVMe drivere sokkal gyorsabb, mint a Microsoft sajátja. Viszont ha hardveresen berakod ezeket RAID0-ba, akkor onnantól kezdve nem fogod tudni használni a Samsung drivert, csak a Microsoftot! Amit nyersz elvben teljesítményben, elbukod a driveren.
Az én személyes véleményem, hogy felejtsd el a RAID0-t ebben az esetben. Persze ilyenkor piszkálja az ember fantáziáját, hogy mi lett volna, ha... Ha ki is próbálod, készülj fel, hogy nem azt fogod kapni, mint amire számítasz.
Más dolog: én nem tennék VM-eket rendszerlemezre. Tapasztalatom szerint fürgébb, ha külön SSD-n vannak.
-
#64791808
törölt tag
"ezek storage spacesben vannak paritás módban, ami egy szoftveres raid5"
Nem. Valamiben hasonlít, de NEM az. Soft RAID5-öt a Windows 10 nem tud, ez a Windows Server privilégiuma. A Storage Spaces ettől sebességben jóval elmarad.
Amit írtál, azt sajnos ebben a formában nem tudja a Windows 10 Storage Spaces.
-
#64791808
törölt tag
válasz Roachy #10075 üzenetére
99% hogy nem fog menni.
Ahogy a kollega irta, a HDD-ket a vezerlo egyedileg azonositja. Ha vissza is rakod eredeti tartalommal a masik HDD-t, a vezerlo szamara azok ismeretlenek lesznek. Ha a RAID-fejlecben at tudnad irni a sorozatszamokat es egyeb eszkozazonositokat, akkor elvben mehetne a dolog. Erre gyakorlatban 0 eselyed van.
Amit tehetsz, hogy vannak kulonbozo, kifejezetten RAID5-re irt adatmento programok, azokat nem erdekli a sorozatszam, jo esellyel adatvesztes nelkul osszerakjak neked a tombon tarolt dolgokat. En ebbe az iranyba mennek el.
Amugy a RAID5 2*4-et nem vagom, ez 2db RAID5 tomb egymastol fuggetlenul? Mert akkor az egyik tomb mentheto, hisz onnan csak 1 lemez szallt el.
Mas tema: a RAID5 lemezmeghibasodas ellen lett kitalalva, es a celja, hogy a folytonossagot garantalja. A RAID5 alkalmatlan a backup kivaltasara, raadasul ekkora meretben nem veszelytelen. Ilyen esetben kellene, hogy legyen mentesetek, megvonni a vallat, recreate RAID5-Array, mentesbol visszaallit, es csokolom.
-
#64791808
törölt tag
válasz viktor1001 #10076 üzenetére
Csak JBOD lehetseges az esetedre Windows alatt. Itt hivnam fel a figyelmet, hogy ha a 4x1TB-bol csinalsz egy JBOD tombot, es egy lemez elszall, akkor minden adatod megy a levesbe.
En eladnam az 1TB-os vinyokat es az USB hazat is, az arabol ki kell, hogy jojjon egy uj 4TB-os lemez.
-
#64791808
törölt tag
válasz Roachy #10083 üzenetére
8 HDD-t siman RAID5-be fuzni velemenyem szerint komoly szakmai hiba.
Nem oszt, nem szoroz, hogy radugod-e a klont, egy probat meger, ha eleg buta a vezerlo, vagy epp eleg okos, akar be is johet. RAID5 eseten, ha egy lemeznel tobb esett ki, akkor az adataidnak mar amugy is kakukk, tehat veszteni nem nagyon veszthetsz vele. BTW mindenkepp vedd fel a supporttal a kapcsolatot, lehet, hogy mondanak hasznalhato otletet.
Hogy melyik szoftvert? Ebben nagy tapasztalatom nincs, egyszer Volt ilyen esetem, akkor a Runtime Software RAID Reconstructort hasznaltam, az gond nelkul visszahozott mindent.
[ Szerkesztve ]
-
#64791808
törölt tag
válasz Proci85 #10085 üzenetére
Tulajdonkeppen igazad van, de a legrosszabb, ami tortenhet, hogy a RAID vezerlo nem ismeri fel az uj lemezeket, es rakerdez, hogy akkor most rebuild RAID5? Ekkor mondod, hogy nem, es ennyi Volt a proba.
De valoban, fonoknek meg kell mondani, hogy van 10-12 TB adat, amit tarolni kell. Valasszon, hogy olcson, vagy biztonsagosan szeretne ezt. A 8 lemezt berakunk RAID5 tombbe, az a legolcsobb. Hatranya, hogy egy lemez kieseset viseli el, es atlag HDD-knel ennel a meretnel eleg nagy a valoszinusege annak, hogy rebuild kozben fog kiesni a masik, es akkor szabhatjuk...
Ha biztonsagosan kell megoldani, akkor az 8x6TB-tal lehetseges, 2db 4 lemezes RAID10 tombbel, es akkor nem beszeltem olyanokrol, hogy redundans tap, kulon helyseg, stb... Ha komoly adatvedelmet akartok, az draga.
[ Szerkesztve ]
-
#64791808
törölt tag
válasz Proci85 #10089 üzenetére
De igen, a RAID5-tel nagyon komoly gondok vannak ilyen meretek eseten.
Itt egy jo angol cikk, roviden tomoren annyi, hogy a merevlemezek rendelkeznek egy bizonyos UBE ertekkel, ami a javithatatlan irasi hibak aranyat mutatja. X byte-onkent ez felmerul, HDD-tol fuggoen. Ilyen hiba eseten az iras sikereskent van visszaigazolva, de a visszaolvasas sikertelen. Hozzavetolegesen 50-100 TB-onkent 1 ilyen hiba elojon.
Ez az adatmennyiseg regen elkepesztoen sok Volt, ma mar, a 8-10 TB-os HDD-k koraban nem is oly ritka. Ha egy ilyen hiba a RAID5 tombon elojon, akkor kozbelep a redundancia, es a paritasadatokbol a vezerlo ujrairja az adott szektort. Az okos vezerlok ezt siman abszolvaljak, a buta vezerlok, meg mondjuk a Windows Server szoftveres RAID5 megoldasa ilyenkor az egesz tombot ujraszinkronizalja. Ha mondjuk egy Intel Rapid Storage alatt levo tomb egyszer csak minden elozetes esemeny nelkul elkezd ujraszinkronizalni, az EMIATT van.
Es most jon a problema: mivan, ha akkor jon elo ez a hiba, mikor a tomb eppen serult, es egy lemez hianyzik? Elmondom: leterdel az egesz RAID5 tomb. RAID6 eseten, a 2 lemezes redundancia miatt jobb az esely.
Van meg egy problema. A RAID5 tombok altalaban ugy letesulnek, hogy egy idoben veszunk x db lemezt, egyszerre uzemeljuk be oket, ugyanolyan korulmenyek kozott ugyanannyit irnak es olvasnak, ugyanannyiszor vannak inditva, stb. Azonos korulmenyek kozott nagyon kis idoelteressel mennek tonkre a lemezek. Csak a gyartas minimalis finomsagu elteresei hatarozzak ezt meg, vagy minimalis homersekleti elteresek. Kovetkezeskeppen ha mondjuk van 3-4 HDD, amit teljesen azonos korulmenyek kozott hasznaltal egy RAID5 tombben, es az egyik elpukkan, akkor KOMOLY eselye van, hogy a masikak is el fognak rovid idon belul.
Ugyhogy igen, a RAID5 biztonsagos, kerdes, hogy mennyire. Milyen esemenyekre kell felkeszulni, mennyire akarok ellenallo adattarolast? Ha mondjuk ket kulon szerverben van 4-4 lemez RAID5-be rakva, de mondjuk beb@sz a villam, akkor a 8 lemezt gepestol teheted a kukaba. Extrem pelda? Pedig megtortent. Fontos, hogy a kulonbozo technologiakat arra hasznaljuk, amire valok.
-
#64791808
törölt tag
válasz Proci85 #10096 üzenetére
Az intel emlékeim szerint igen, ICH8R-en és most X99-en volt RAID1, ha visszaállítottam AHCI-re, simán ott volt mindkét HDD-n a partíció, írt/olvasott, szerintem a 10R-nél sem lehetne gond.
És igen, működni fog a TRIM, de csak akkor, ha az SSD nem része egyetlen tömbnek sem.
[ Szerkesztve ]
-
#64791808
törölt tag
válasz BadWolfCorp #10117 üzenetére
Valami nagyon nem stimmel, ennek 200MB/sec körül kellene írnia.
Az RST vezérlőpultban nézd meg a Write cache/Írási gyorsítótár beálíltásokat. Ha van szünetmentesed, akkor Write back/Visszaíró, ha nincs, akkor Write through/Átíró cache módot állíts be, illetve, ha még nem tetted, inicializáld a kötetet. Ettől meg kellene érkeznie az írási sebességnek. A 20-30MB/sec az lepkefing.
-
#64791808
törölt tag
A Windows eszkozkezelojeben a lemez beallitasainal a write Cache kiirasanak letiltasa be van pipalva? Ha igen, akkor szedd ki a pipat mindket lemeznel, hagyd, hogy lefusson a resync, es nem lesz vele tobbet gondod.
-
#64791808
törölt tag
Maradjunk annyiban, hogy te még nem láttál olyat, ahol ez gondot okozott volna.
Ha az be van pipálva, akkor a Windows akár 8GB puffert is használ az írásnál, amit nem feltétlenül ürít a lemezre, ennek ellenére sikeresnek és befejezettnek jelzi vissza az írási folyamatot.
Tehát te azt látod, hogy fúú, így gyorsabban ír a lemez! Pedig nem, mert amit te befejezett másolásnak látsz mondjuk, az még NINCS a lemezen. Csak a pufferban. Szóval a lemezre nem ír gyorsabban ettől.
Viszont klasszikus probléma, hogy ilyen esetben, mikor még az adat nincs a lemezen, csak a pufferban, és érkezik egy forced shutdown/reboot, akkor Windows a leállítással/újraindulással NEM fog várni a puffer kiürüléséig, csak a registryben ilyen esetre meghatározott timeoutig, ez az XP-nél még 20s volt, a Windows 10-nél már csak 5s. Eredmény: a sikeresen kiírtnak visszajelzett adat mégsem kerül fel a lemezre. Ezt az inkonzisztenciát a Windows a következő indításkor azonnal észreveszi, és - most jön a lényeg - ha saját szoftveres RAID1 vagy RAID5 van konfigurálva, akkor az inkonzisztencia miatt azonnal újraszinkronizálásba kezd.
No így okoz az az egy kis pipa ilyen gondot. És ha azt gondolod, hogy forced reboot sosem fordul elő, akkor elmondom, hogy jónéhány telepítő, amely újraindítást kér, ha igenre böksz, akkor forced reboot parancsot ad ki.
RAID1 / RAID5 esetében SOHA nem pipáljuk be ezt az opciót a raidelt lemezeknél, mert egy másolás után rosszkor elindított nyomorult telepítő is okozhat ilyen galibát, a user meg nem érti, miért kezd a rendszer egy fél napig tartó resyncbe.
-
#64791808
törölt tag
válasz Kam1kaze #10138 üzenetére
Amit írsz, sima ügy. Az Intel RST is tudja, de a helyedben az egyszerűség kedvéért Windowson belül csinálnám.
1., Mondjuk rámásolod az adatokat az 1TB-os lemezre. Egy partíció legyen rajta, ami elfoglalja a teljes méretet. A 3TB-os egyelőre üres.
2., Mindkét lemezt dinamikus lemezzé konvertálod az eszközkezelőben, így az 1TB-os lemezen a partíció dinamikus kötetté válik. Ez kell a RAID-hez.
3., Jobb klikk az 1TB-os dinamikus kötetre a lemezkezelőben, és tükör hozzáadása. Kijelölöd a 3TB-os lemezt, az elejére oda fogja tenni az 1TB-os tükröt, és elkezd szinkronizálni.
4., A fennmaradó 2TB-ra meg simán teszel egy normál kötetet és kész.
Amit tudni kell, hogy a RAID tömb teljesítményét a leglassabb láncszem fogja meghatározni. Ha az 1TB-os HDD lassabb, akkor a 3TB-os várni fog mindig egy picit. Viszont - és ez a kellemetlen - ha egyszerre indítasz lemezfolyamatot a RAID tömbön, és a maradék helyen, akkor a 3TB-os lemeznek állandóan egyszerre két dolgot kell csinálnia, és atomlassú lesz. Ezt a dolgot tartsd szem előtt.
Amúgy az elgondolásod teljesen logikus és bevett szokás. Sőt, én anno olyan rendszereket is csináltam, hogy 2x3TB lemez, de csak 1+1TB RAID1, ezen voltak a dokumentumok és a képek, a maradék 2+2TB RAID0-on voltak a pótolható dolgok, plusz az gyors volt, ha kellett. Vagy 4x2TB volt a másik, 4x1TB RAID5-tel, és 4x1TB RAID1-gyel. Szóval lehet ezt variálni, csak szem előtt kell tartani, hogy az ilyen megoldás mire képes, és mire nem. Ha egy lemezre egynél több parancsot küldetsz ki, az bizony borzalmasan lassú lesz.
Szerk: most olvasom, hogy kihagyod, mert a szoftveres a gép erőforrásait jobban használja. Ez igaz volt régen, és alapvetően a RAID5-re, ahol paritásbiteket kell számolni. Egy RAID1-nél semmiféle többlet-erőforrás nem kerül felhasználásra, egyszerűen nem egy, hanem két lemezírási folyamat indul, de nincs mit számolni.
Szerk: enginev3.0 igen, meg a hibalehetőség is a 3. hatványra nő.
[ Szerkesztve ]
-
#64791808
törölt tag
válasz Kam1kaze #10147 üzenetére
Hogy mikor konvertalsz dinamikus lemezre, az mindegy. Ezen konverzio nem erint adatot a lemezen, tehat nyugodtan lehet adatokkal teli particioval, nincs veszelyfaktora.
Ahogy leirtad, nem fog ebbol az elrendezesbol ilyen hasznalat mellett sebessegi hatranyod szarmazni.
A "jobb/rosszabb" kifejezesek mindig a kornyezettel egyutt ertelmezendoek. Altalaban jobban megfelel a HW RAID, Jelen esetben viszont jobban jarsz a szoftveressel. Ha RAID5-rol beszelnenk, akkor mas lenne a helyzet.
Windows ujratelepitesnel a lemezkezeloben majd importalnod kell a kotetet. Ez 3 kattintas es kesz, nincs adatvesztes. Viszon HW raidnel, ha lehal mondjuk a lap, akkor ugrott a raid...
"a RAID használata rövidíti a merevlemez élettartalmát" -> nem
A fontos, hogy a ket lemez hutve legyen, ha minimalisan is, de ne alljon korulottuk a meleg.
-
#64791808
törölt tag
válasz Boborjan76 #10161 üzenetére
Ez teljesen normális lehet, hogy csak az egyikről olvas. Ha nincs a vezérlő felkészítve arra, hogy párhuzamosan olvasson, márpedig nincs, mert azt csak a drágább SAS vezérlők tudják, akkor csak egy lemezről fog olvasni.
-
#64791808
törölt tag
válasz Cyberboy42 #10166 üzenetére
Nem valoszinu. Ami sanszos, hogy amikor az iras az egyik lemez rossz szektoraihoz er, akkor mar iraskor szet fog ugrani a RAID, mert az egyik lemezen irasi hiba lesz.
En olyan lemezt, amirol konkretan tudom, hogy hibas, nem tennek RAID-be. A RAID1 kifejezetten a lemezhiba ellen ved. Na de ha TUDOD, hogy az egyik lemez hibas, akkor minek?
-
#64791808
törölt tag
válasz gondor53 #10170 üzenetére
Ott a gond, hogy szinte minden NAS valami sajat egyedi hulye fajlrendszert hasznal. Egy RAID5 adatmento pedig erre altalaban nincs felkészítve. Tehat magat a RAID5 strukturat lathatja is, de a fajlrendszert nem fogja ismerni.
De minden eltunt rola, vagy csak 1 konyvtar?
-
#64791808
törölt tag
válasz skiner2222 #10173 üzenetére
Szia, importalni kellene a kotetet, nincs ilyen opciod valahol?
-
#64791808
törölt tag
válasz skiner2222 #10177 üzenetére
Igen, a Windows felismerte, hogy ez egy RAID tomb, 2 lemezzel. Leokezod es importalta.
-
#64791808
törölt tag
válasz mike710 #10182 üzenetére
Szia, igen, ejjel dolgozom.
1., Az eszkozkezeloben megkeresed a merevlemezt, es a tulajdonsagainal megnezed, hogy az irasi gyorsitotarazas be van-e kapcsolva. Azon belul van meg egy pipa, hogy a gyorsitotar tartalmanak kiirasanak tiltasa, vagy valami ilyesmi, azt is pipald be.
2., Ha a torrent 40 megat ir, de a feladatkezelo meg 110-et, akkor lodd le a torrentet, hogy a feladatkezeloben is visszamegy-e nullara az iras. Ha nem, akkor valami meg matat a hatterben. Ha igen, akkor celszeru toredezettsegmentesiteni - Windows 7 elott gepen, hatha gyorsabb lesz.
A feladatkezelo altal jelzett irasi sebessegek NEM mért, HANEM szamitott ertekek, bizonyos esetekben nagyon elternek a valosagtol. Milyen torrent klienst hasznalsz?
-
#64791808
törölt tag
válasz SirRasor #10227 üzenetére
Nem tennem. A Windows szoftveres RAID vezerloje nem rossz, celnak megfelel.
Ket dologra figyelni:
1., Eszkozkezeloben az SSD beallitasainal az irasi gyorsitotar kiirasanak tiltasa lehetoseg NE legyen bepipalva.
2., A gep lehetoleg szunetmentesen legyen, es NE legyen szabalytalanul leallitva.
Ezek egyike sem gond, de a hianyuk irasi hibat okoz, ami miatt a Windows azonnal ujraszinkronizalja a lemezeket, amit nem kellene.
-
#64791808
törölt tag
-
#64791808
törölt tag
-
#64791808
törölt tag
válasz sutszi #10276 üzenetére
Ha már ESXi, akkor nem adok halat, inkább tanulj meg horgászni:
https://www.vmware.com/resources/compatibility/search.php?deviceCategory=io
-
#64791808
törölt tag
válasz sutszi #10280 üzenetére
Szia,
oké, nos az ESXi nem szereti a nagyon kommersz noname RAID-vezérlőket. HP-val nem nagyon tudsz lukra futni, a P410 jó tipp.
Itt egy német oldal, náluk nagyonsok szervercucc olcsón van, ha kell, tudok beszerzésben is segíteni.
ServerShop24.de -
#64791808
törölt tag
válasz Dilikutya #10281 üzenetére
A HDD-k célszerint legyenek egyformák. Nem tragédia, ha nem, szépen működni fog, csak a két HDD különbözőségéből adódó apróságok pici sebességcsökkenést okozhatnak. Jelentős különbség ne legyen azért köztük, szóval ha az egyik egy 5 éves, 4 tányéros 1TB-os, a másik meg egy zsírúj 1 tányéros, akkor az minden lesz, csak jó nem.
Ha az alaplapi RAID-vezérlővel csinálod a tömböt, akkor az öregisten sem mondja meg neked, hogy másik gépbe átrakva mi lesz, de az én tapasztalatom szerint még másik, ugyanilyen alaplap sem mindig kezeli jól.
A javaslatom, hogy szoftveresen csináld a tükrözést, ha Windows alatt vagy, akkor a lemezkezelőben konvertáld mindkét lemezt dinamikussá, és ott csináld meg a tükröt. Ezt bármilyen másik Windows-alapú gép alá beteszed, akkor hardvertől függetlenül fog neked menni. Lassabbnak pedig nem lassabb így.
-
#64791808
törölt tag
válasz havri1 #10283 üzenetére
Igen, ez abszolút működik.
A RAID0-hoz (amin szintén ne tarts semmit, ami fontos és nincs másik mentés róla, mert bármikor elszállhat) inkább az alaplapi RAID vezérlőt használnám, az azért gyorsabb a Windows szoftveres megoldásánál, továbbá tudsz csíkszélességet állítani.
A RAID0 lelke a csíkszélesség és a rajta lévő partíció szektorméretének összehangolása.
1., Ha inkább kis fájlokat tartanál a lemezen, akkor nagyon kis csíkszélességet kell választani. Helytakarékos, és gyorsabb lesz. (Ha van egy 8kB-os fájlod, de 16kB a csíkszélesség, akkor a fájl eleve csak az egyik lemezen lesz meg a fájl - nincs gyorsítás -, ráadásul, mivel az olvasás blokkokban történik, a fájlodhoz a lemeznek a teljes 16kB-os blokkot be kell olvasnia. Ha a csíkszélesség viszont 4kB, akkor a fájl 2 blokkot igényel, tehát lehet külön lemezre írni őket, és ezt a 2 blokkot kell beolvasni, nincs felesleges olvasás.)
2., Ha nagy fájlokat tartanál a lemezen (4MB és fölötte), akkor a lehető legnagyobb csíkszélesség kell. (Ha van egy 64MB-os fájl, 4kB-os csíkszélességgel, az 16384 blokk, az lemezenként 8192 olvasás. De ha 128kB a csíkszélesség, akkor 512 blokk, lemezenként csak 256 olvasás. Ugyanannyi adatra. A HDD-knek ezen I/O műveletek száma a szűk keresztmetszete, tehát nagy fájloknál a nagy csíkszélesség sokat dob)
3., Szektorméret. Ha megcsinálsz egy RAID0 tömböt, bármekkora csíkszélességgel, akkor az adott tömböt formázni kell, teszel rá egy partíciót. Windows alatt vélhetően NTFS (ritkábban ReFS) lesz a partíció, ahol szépen állítható a szektorméret. Ennek igazodnia kell a csíkszélességhez. Miért?
Ha a csíkszélességed mondjuk 4kB, de a szektorméret 64kB, az nem jó. Ugyanis a Windows a fájlrendszert szektoronként kezeli, és ezért egy 4kB-os fájlnál is a TELJES szektort fogja írni/olvasni. Nagy fájloknál sincs értelme, mert a szektor szintű fájlrendszerkezelést a HDD felé blokkokra kell osztani. Így egy szektor írása a Windows által valójában 16 blokkírás a HDD-ken.
Fordítva pont úgy nemjó, ha van 64kB-os csíkszélességed, akkor ne állíts be 4kB-os szektorméretet. Ha egy kis fájlt olvasol, akkor is be kell olvasni az egész blokkot. Ha egy nagy fájlt olvasol, akkor meg ugyan kevés blokkot kell beolvasni, de nagyon sok szektort. Ha ezek nem pont egymás mellett vannak, akkor SOROZATBAN fog a rendszer egy-egy 4kB-os szektor beolvasásáért egy 64kB-os blokkot olvasni, te meg nem tudod, hogy a zsír új RAID0 tömböd mért ír/olvas 250 MB/s helyett csak gyenge 70-nel.
Két iskola van: az egyik azt mondja, hogy a szektorméret pontosan egyezzen meg a csíkmérettel, a másik pedig, hogy legyen annak kétszerese. Az első előnye az, hogy egy szektor - egy blokk. Hátránya az, hogy gyakorta előfordulhat - mivel az NTFS töredezik -, hogy sok szektor csak egy lemezre kerül kiírásra, így a csíkozás előnye nem jön ki. A második esetben, mikor egy szektort kiírsz, az MINDIG két blokk, tehát mindig két lemezre kerül kiírásra. Hátránya a relatív helypazarlás: egy fájlnak lehet, hogy elég lenne egy blokk, de a Windows egy teljes szektort foglal le neki.
Konkrét számokkal:
Kis fájloknál a lehető legkisebb csíkszélesség és azzal meggegyező szektorméret, így lesz a leggyorsabb.
Nagy fájloknál a lehető legnagyobb csíkszélesség és duplaakkora szektorméret.No dióhéjban ennyi
-
#64791808
törölt tag
válasz J3LLyF!sH #10284 üzenetére
1., Ha AHCI-n hagyod, akkor az alaplap független lemezekként kezeli a HDD-ket, a RAID-et pedig a Windows hozza létre. Univerzálisabb, nem hardverfüggő, viszont egy picit lassabb - RAID0 és RAID5 esetében sokkal lassabb.
2., Ha RAID módra rakod a lapot, akkor a tömböt az alaplapi vezérlő hozza létre és kezeli, a Windows csak a kész tömböt látja, a lemezeket nem. Hátránya, hogy hardverfüggő, ha az alaplapi RAID vezérlő meghal, akkor általában bukta van. Előnye a sebesség, és hogy precízebben állíthatóak a tömb paraméterei.
Az első eset egyik további hátránya, hogy a Windows minden apró probléma esetén automatikusan és megállíthatatlanul elkezdi újraszinkronizálni a tömböt. A tömb ettől használható, csak botrányosan lassú lesz.
-
Új hozzászólás Aktív témák
- Kerékpárosok, bringások ide!
- A fociról könnyedén, egy baráti társaságban
- Kínai, és egyéb olcsó órák topikja
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Alapértelmezett konfiguráción sok Core CPU-nak lehet stabilitási gondja
- Futás, futópályák
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Épített vízhűtés (nem kompakt) topic
- E-Book Off topic
- Luck Dragon: Asszociációs játék. :)
- További aktív témák...