Új hozzászólás Aktív témák
-
Jester01
veterán
honnan tudjam, h másodszor is jó
A kipróbálást csak arra értettem, hogy egyáltalán megy-e, nem pedig arra, hogy az adatok valóban tükrözve vannak-e.
Nekem egy olyan szoftver kéne, ami külön látja a két winyót... van ilyen?
Nem tudom, majd a wines emberek megmondják. A linux mindenesetre látja (mivel ez nem hw raid, ugye). -
Jester01
veterán
Érdekes. Vajon mihez kell neki szabad hely?

Amúgy én linuxos live cdről bootolnék és jól összehasonlítanám a 2 diszk tartalmát. Ezzel egy füst alatt az adatok olvashatóságát is ellenőrizném.
Ha bátor vagy (illetve ha van mentésed) akkor kipróbálhatod elindul-e a rendszer egy diszkkel is. Amikor a másikat visszateszed arra kutya kötelessége újratükrözni a tartalmat. Ha ezt nem teszi meg, akkor nem is működik a raid1...
Én új rendszer építésekor mindig kipróbálom működik-e a raid, nehogy akkor derüljön ki amikor már késő. -
Jester01
veterán
további 6másodpercig folyamatosan világitott a HDD led
Akkor itt a válasz: ekkor írta ki. Előtte csak berántotta a memóriába.
Szerintetek rakjak másikat helyette, vagy igy is megérhet 1 próbát?
Raid0 eleve gázos adatbiztonságilag, én nem kockáztatnék. De ugye mentésed biztos van, igaz?
-
Jester01
veterán
Nem tudom win alatt mennyire jellemző, de cache-be írni is lehet. A 2 gigába pedig bőven belefér. Mondjuk a 700MB/5sec még olvasásnak is elég impresszív de már hihetőbb. Nem figyelted meg, hogy a másolás befejezése után esetleg még dolgozik a vinyó?
Legalább a memóriánál kétszer nagyobb adatmennyiséggel érdemes próbálkozni, de ha nem lehet a cache-t üríteni, akkor a tízszeres sem túlzás... -
Jester01
veterán
Pont arról volt szó, hogy a háttértároló-vezérlőt én még nem láttam olyan buszra csatlakoztatva, amely nincs kivezetve az alaplapra, bővítősínként is.
Az integrált cuccok szerintem külön buszon lógnak. A déli hídon belül dedikált buszuk van, nem osztoznak a kivezetett pci busszal. Ezt most azt hiszem nem tudom demonstrálni, mert az integrált vezérlőn nincsennek diszkek és le van tiltva. Ilyeneket találtam az ich5 leírásban:
I/O cycles involving USB, IDE, SATA, and AC '97. These transactions complete over the hub interface without appearing on the external PCI bus.
...
Note that the ICH5's internal functions (AC '97, IDE, USB, SATA and PCI Bridge) are enumerated like they are on a separate PCI bus (the hub interface) from the external PCI bus.
Nálunk az a probléma, hogy hiába is tudna a pci-x óriási sávszélességet ha hidak közötti kapcsolat csak 266MB/s. Emiatt nem tudjuk kihasználni. -
Jester01
veterán
A sata vezérlõ az pci-x. Bocs, ha nem említettem volna.

Az összefüggés pedig a két híd közötti csatorna.
Manapság nincs jelentõsége, az újabb chipseteknek van elég sávszélessége. Csak minket vert meg a sors 3 ilyen géppel, amiben 15 diszk van és simán ki tudná tölteni a dual gigabitet. Ehelyett kénytelenek vagyunk beérni kevesebbel.
MOD: kellene valami modernebb alaplap. Kompatibilitás miatt socket 478, DDR-1, és 2 PCI-X slot kellene. Nem tudtok véletlenül egy ilyen típust? Hátha meg tudom gyõzni az illetékeseket, hogy érdemes lenne cserélni.
[Szerkesztve] -
Jester01
veterán
# netio -u 192.168.100.61
NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel
UDP connection established.
Packet size 1k bytes: 97705 KByte/s (0%) Tx, 94774 KByte/s (17%) Rx.
Packet size 2k bytes: 106854 KByte/s (0%) Tx, 90197 KByte/s (21%) Rx.
Packet size 4k bytes: 108589 KByte/s (0%) Tx, 100881 KByte/s (13%) Rx.
Packet size 8k bytes: 108844 KByte/s (0%) Tx, 100846 KByte/s (13%) Rx.
Packet size 16k bytes: 108056 KByte/s (0%) Tx, 99788 KByte/s (14%) Rx.
Packet size 32k bytes: 109122 KByte/s (0%) Tx, 94606 KByte/s (19%) Rx.
Done.
Ezzel párhuzamosan:
# dd if=/dev/md0 of=/dev/null bs=1M
10414+0 records in
10414+0 records out
10919870464 bytes transferred in 72.899306 seconds (149793888 bytes/sec)
Két integrált hálókari van, a másik az nem CSA, hanem rendes PCI. Ez átmegy a déli hídhoz. A mérési eredmény pedig:
# netio -u 192.168.101.61
NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel
UDP connection established.
Packet size 1k bytes: 59461 KByte/s (0%) Tx, 48027 KByte/s (58%) Rx.
Packet size 2k bytes: 57543 KByte/s (0%) Tx, 14313 KByte/s (87%) Rx.
Packet size 4k bytes: 61488 KByte/s (0%) Tx, 11195 KByte/s (90%) Rx.
Packet size 8k bytes: 62406 KByte/s (0%) Tx, 5904 KByte/s (94%) Rx.
Packet size 16k bytes: 63562 KByte/s (0%) Tx, 11865 KByte/s (89%) Rx.
Packet size 32k bytes: 65144 KByte/s (0%) Tx, 10334 KByte/s (91%) Rx.
Done.
A diszk olvasás ugyanannyi, feltételezem annak van prioritása.
Önmagában ez a hálókártya is hozza 100+MB/s sebességet. -
Jester01
veterán
-
Jester01
veterán
Van. Ha az ''ilyen'' a CSA-ra vonatkozott.
0000:00:03.0 PCI bridge: Intel Corp. 82875P Processor to PCI to CSA Bridge (rev 02) (prog-if 00 [Normal decode])
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
0000:01:01.0 Ethernet controller: Intel Corp. 82547GI Gigabit Ethernet Controller -
Jester01
veterán
válasz
PapaMaci
#1954
üzenetére
A sima 32bit 33Mhz pci cuccokkal vigyázni kell, ott már 2 diszk esetén is kevés lehet a busz sávszélessége.
Persze proci terhelést ez nem okozhatna.
MOD: és raid0-nál még paritást sem kell számolni.
Azt hiszem nekem is ilyen kártyám van, majd otthon megnézem.
[Szerkesztve] -
Jester01
veterán
válasz
lazydog
#1947
üzenetére
Nincs olyan, hogy független PCI busz
Már hogyne lenne.
Most mindenesetre csak arra találtam bizonyítékot, hogy az intel ich5 chipbe integrált raid az nem a pci buszon lóg:
In addition to the features of ICH5, the ICH5R I/O controller hub includes an integrated RAID controller that utilizes the dual Serial ATA ports for a high-performance RAID Level 0 configuration with a maximum theoretical transfer rate of 300 MB/s. By integrating the Intel RAID controller into the I/O controller hub, there are no PCI bandwidth limitations (133 MB/s) nor any loss of PCI resources (request/grant pair, PCI slot) that would typically occur with discrete PCI RAID solutions.
MOD: mindazonáltal itt meg is van a bottleneck, mégpedig a north és a south bridge közötti összekötés: Intel's interconnect maxes out at 266MB/s.
[Szerkesztve] -
Jester01
veterán
ha esetleg csak PCI busz van az alaplapon (meg esetleg AGP, de az most nem érdekes), akkor ugye nem is kérdés.
De igen, kérdés. Chipseten belül bármi lehet. CSA busz, független PCI buszok, HT, saját busz, stb.
Például: the Intel 82547GI Gigabit Ethernet Controller bypasses the PCI bus, freeing its bandwidth for other I/O operations, and connects to the dedicated CSA bus on the Memory Control Hubs (MCH) of Intel® 865 and 875 chipsets -
Jester01
veterán
válasz
lazydog
#1940
üzenetére
Azért a 4 diszk esetén elvárható valamennyi gyorsulás, legalább kétszeres szerintem.
A chipsetbe integrált vezérlők pedig tudomásom szerint nem a lassú pci buszt használják.
Én azt javasolnám, hogy nem raid módban próbáljon egyszerre több lemezről olvasni és azt megmérni. -
Jester01
veterán
Pci express szabvány szerint kötelezõ lenne mennie legalább x1 módban:
In all cases, up-plugging is physically possible; however, the PCI Express specification only requires slots to negotiate to a x1 link width. While it is possible for a motherboard manufacturer to incorporate up-plugging without bandwidth degradation, it is not required. For example, if you plug an x4 PCI Express board into an x8 PCI Express slot, your board might operate at x1 bandwidth even though it is capable of x4 bandwidth. This behavior depends on the motherboard manufacturer. -
Jester01
veterán
Raid0 nem dobja ki a diszket. Viszont a TLER miatt a diszk abbahagyja a hibajavítási próbálkozást idő előtt. Vagyis bad sector lesz olyankor is, amikor esetleg hosszabb próbálkozással még visszanyerhető lenne az adat. Legalábbis én így értem. Persze logikus lenne, ha ki lehetne kapcsolni.
-
Jester01
veterán
Szerintem úgy, hogy a TLER miatt egyébként javítható hibákat sem fog javítani az idõkorlát miatt, azzal a feltételezéssel élve, hogy majd a controller a redundancia alapján javítja. Raid0 esetén ugye ez nincs, ergo jó lenne, ha a vinyó addig próbálkozna amíg csak tud.
Elvileg arra jó a TLER, hogy egy apró hiba miatt ne essen ki az egész drive azonnal a tömbből.
Nem tudom a hw raid kártyák ezt hogy csinálják, de a linuxos sw raid az elsõ hibánál úgy kivágja az egész diszket a tömbbõl mint a szél. Nem foglalkozik azzal, hogy a hibás szektorokat nyilvántartsa.
A linkelt pdf (amit már én is olvastam) ugyanakkor valóban arról beszél, hogy nem esik ki a diszk a tömbbõl. Viszont ezt is írja: ''It is important to realize TLER-capable hard drives should not be used in non-RAID environments.'' (ahová szerintem a raid0 is beleértendõ, hiszen redundancia szempontjából az nem raid) -
Jester01
veterán
Többségében egyetértek, csak ezt az apróságot nem értem:
RAID5-öt leginkább adattárolásra érdemes használni, mert tényleg számításigényes, ráadásul összeadódnak a HDD-k elérési késleltetései.
Miért is? Szerintem nem adódnak össze. Ja és a számításigény is relatív, manapság egy átlagos desktop gép esetén is észrevehetetlen szerintem.
APC pl. garanciát vállal az adatbiztonságra is
APCt ne emlegesd, most füstölt el a szervereink alól 2 szünetmentes és nem értjük miért... -
Jester01
veterán
válasz
sanyibá
#1000
üzenetére
De egy ilyet bele lehet dugni: [link]

Intel procihoz megabrutál lap (duál): [link]
(one PCI-E x8 slot, one PCI-E x4 (with x8 slot), one PCI-E x1 (with x4 slot) and two PCI-X 100~133MHz slots)
Hasonló dual opteron alá: [link]
(One x16 PCI Express slot with x16 signal, One x16 PCI Express slot with x4 signal, One PCI 2.3 compliant 5V tolerant 32bit/33MHz, Two independent 64-bit PCI-X buses, Two 133/100 MHz PCI-X slots from Bridge A, One 100/66 MHz PCI-X slot from Bridge B) -
Jester01
veterán
válasz
Freddy TNT
#998
üzenetére
Öööö ez azért jó mert pci-x kártyád van? Mert más elõnyét nem látom, én már a pcie-re szavazok. Már az x2 pcie is tud ekkora sávszélességet (full duplexben), és az nem busz hanem pont-pont, vagyis a 2 (vagy több) slot az nem osztozkodik. Magyarul 2 db x1 pcie tudja azt mint a 2db (azonos buszon lévõ) 133MHz/64bit pci-x slot. Feltéve, hogy jól számoltam

-
Jester01
veterán
válasz
Freddy TNT
#970
üzenetére
Viszont úgy tudom vannak olyan RAID vezérlők,amik nem a vincsire rögzítik, hanem maguk tárolják ezeket az adatokat.
Abszolút igazad van. De ezek mondjuk nem az alaplapi szutyok kategória szerintem
Mindenesetre asszem leszögezhetjük, hogy a legapróbb hiba is a RAID 0 vesztét okozhatja.
Az tuti
-
Jester01
veterán
válasz
Freddy TNT
#968
üzenetére
Egyetlen bittel? A lemez szektorait használja, azon nem állít semmit. A stripe méret függvényében ugyanaz lesz. Nemtom a biosok hogy csinálják de valószínûsítem, valahonnan lecsippentenek néhány szektort amibe a metaadatokat rakják. (linux sw raid pl. a diszk/partíció végérõl) A maradékra pedig simán megy a raid0 algoritmus. Nem tudom mi csúszhat el ezen. Ha ugyanazt az algoritmust ugyanolyan diszkekre n-szer lefuttatod mindig pont ugyanazt fogod kapni. A raid a fizikai szint fölött van, ami adatok a lemezen voltak a szektorokban az érintetlen marad (a metaadatok természetesen nem, mert azt a tömb készítés felülírja) Az automatikus hibajavítás a diszk dolga, eközben nem veszhet adat, akkor sem, ha áthelyezi a szektort. A felette levõ rétegek számára ez transzparens. Ha pedig nem, akkor már írási/olvasási hiba van.
-
Jester01
veterán
válasz
Freddy TNT
#965
üzenetére
Nemtom, de mi oka lenne rá? Mi az, hogy ''belövi''? Én mondjuk csak linuxos sw raidet használtam eddig (ezek az alaplapi szutykok is sw raidek ugye, és akkor már inkább a linux mint a bios). Ott semmi véletlenszerűség nincs. Ha megmondom a stripe méretet akkor az pont ugyanolyan lesz akárhányszor is csinálom meg.
-
Jester01
veterán
válasz
Freddy TNT
#959
üzenetére
Ezt mondjuk nem egészen értem. Ha a lemez fizikailag nem sérült (vagyis rajta vannak az adatok) akkor elvileg a tömböt simán újracsinálhatod (ugyanolyan paraméterekkel), hiszen raid0 készítéskor nem töröl semmit a diszkekről.
De mivel sok adatról van szó, ez erősen SZVSZ és csak saját felelősségre.
Persze aki raid0-t csinál mentés nélkül, az valahol meg is érdemli. -
Jester01
veterán
válasz
Freddy TNT
#832
üzenetére
Ne érts félre, ez nem gonoszkodás volt.
Csak felhomályosítottam a kollegát, hogy nem értek a winhez, inkább rád hallgasson
Mi ettõl függetlenül közben jól eldumálgatunk itt
MOD: áhá, sejtem már mit értettél félre
Nem azt mondod meg, hogy nem értek hozzá, hanem azt, hogy kell-e win reinstall. Igy gondoltam:
''Majd Freddy megmondja [hogy kell-e reinstall], én nem értek a winhez''
[Szerkesztve] -
Jester01
veterán
válasz
Freddy TNT
#826
üzenetére
Ez csak példa volt. Valójában 2db 8portos kártya van

-
Jester01
veterán
válasz
Freddy TNT
#822
üzenetére
Az utolsó bekezdésben nekem nem világos akkor a kérdésed
Egyszerû példa: adott 4 diszk és 2db 2 portos vezérlõ.
Kellene csinálni 2db raid1 tömböt.
Hogyan érdemes? Egyik tömb az egyik vezérlõn, másik tömb a másik vezérlõn vagy pedig elosztva. -
Jester01
veterán
válasz
Freddy TNT
#818
üzenetére
A tuszkolás alatt arra gondoltam, hogy szerintem csak akkor ír a másik vezérlő a tükrözött vinyóra, miután az elsőn végbement a módosítás.
Ez biztos nem igaz. Linux alatt tuti nem.
igaz, hogy külön buszon vannak,de az adatok így kétszer is megjárják az alaplapot. +2*2x (n-szer)
Bocs, de ezt tényleg nem értem.
A) eset: 1 vezérlõ. Adat megy 2x ugyanarra a kártyára, de külön diszkre.
B) eset: 2 vezérlõ. Adat megy 1x az egyik 1x a másik kártyára.
Szerintem prociterhelés szempontjából a kettõ ugyanaz.
Mivel plusz egy vezérlőröl beszélünk,ezért kizártnak tartom, hogy ne használna ugyan annyi CPU-t, mintha csak egymagában lenne.
Huhh? Csak azért mert ''van''?
Nekünk egyébként 2 vezérlõnk van a gépekben, mert 1 kevés. Tehát a kérdés nem az volt, hogy 1 vagy 2 vezérlõ, hanem az, hogy a vinyókat szétosszuk-e vagy legyen egy tömb egy kártyán. -
Jester01
veterán
válasz
Freddy TNT
#815
üzenetére
Ja, raid0 esetén valóban kevésbé biztonságos. De aki raid0-t használ, az nem a biztonságra hajt... Raid 1 esetén fenntartom, hogy ha véletlenül a vezérõ hal meg, de úgy, hogy kinyírja a vinyókat akkor jobb a 2 vezérlõ. Ritka eset, de elõfordulhat. A 2 vezérlõ miatt ugyan nagyobb a meghibásodás veszélye, de az adatvesztésé kisebb.
Amúgy meg nem értem milyen adatot tuszkolna egyik vezérlõrõl a másikra. A soft raid ráadásul 2x (n-szer) küldi el az összes adatot és ha az két külön vezérlõ (alkamasint 2 külön buszon!) akkor ezek párhuzamosan is mehetnek. Proci terhelés ebbõl kifolyólag pont ugyanannyi, mivel az adatforgalom a buszon ugyanannyi.
HW raid esetén természetesen teljesen igazad van, mert olyankor egyszer megy az adat a vezérlõhöz és onnan már annak a saját procija számolja a paritást (ha szükséges) és küldi tovább az adatot a vinyóknak.
És még mindig SZVSZ![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Jester01
veterán
válasz
Freddy TNT
#808
üzenetére
Szerintem emberünk azonos gyártójú (és akár még azonos mechanikájú) vinyókat akar raidbe tenni. És ha raid1-rõl van szó, akkor még több értelme is van a külön vezérlõnek adatbiztonság szempontjából. Az interface sebességkülönbség pedig nem hiszem hogy nagyon meglátszana a tömb teljesítményében. Szigorúan SZVSZ.
-
Jester01
veterán
válasz
Freddy TNT
#798
üzenetére
Mert mi a teljesértékû raid definíciója?
-
Jester01
veterán
válasz
Freddy TNT
#681
üzenetére
Pl. aszerint, hogy hányszor írható: R: 1x RW: ~1000x RAM: ~1000000x
Az R,RW az dvd kompatibilis, a RAM az nem. Elõbbiek spirálisan rögzítik az adatokat, utóbbi sávos-szektoros mint egy HDD. stb. -
Jester01
veterán
válasz
Freddy TNT
#679
üzenetére
Szerintem DVD-RAM-ra akar backupolni és ezért nem kell neki redundancia.
Szvsz. -
Jester01
veterán
válasz
Freddy TNT
#676
üzenetére
Jah. Én is arra írtam, hogy akárhány, 2 vagy több lemezzel megy a raid 0 és az 1 is.
És persze 2SATA+1IDE kombóban is, ha szoftveres.
[Szerkesztve] -
Jester01
veterán
válasz
Freddy TNT
#669
üzenetére
Software raid 0 vagy 1 akárhány (egynél több
) lemezzel mûködik.
Raid 3, 4 vagy 5 esetén min. 3 lemez; raid 6 vagy 10 min. 4 lemez (raid 10 esetén további megkötések vannak). -
Jester01
veterán
Akkor menjen el kávézni amíg swappel a gépe

Nemtom, nekem akárhányszor elkezdett úgy istenigazábol swappelni, a használhatatlanságig belassult bármilyen oprendszer. Ha neki elfogadható a sebesség swappelés esetén is, akkor örüljön neki.
Ez egy drága hobbi ha ilyet csinál ilyen minõségben. Az amatõrcsillagász se panaszkodjon, ha drága távcsövet kell vennie. (Gondolom megvette az felsorolt programokat is, igaz?)
De már nagyon off vagyok, bocs.
-
Jester01
veterán
Nemtom hol élek, de ha ennyit swappel a géped, akkor nyugodtan elmehetsz közben kávézni ... Profi feladatokhoz profi gépek kellenek. Miért is sok 16GB egy profi gépbe?
A streamelés az speciális eset, a swappelés az rendszerint véletlenszerû és így sokszor a seek time a jelentõsebb szûk keresztmetszet.
A 2 alkalmazás az pont arra volt példa amit írtál, úgy kell érteni, hogy egynél több. Azt próbáltam mondani, hogy ha egy alkalmazás magában swappel, akkor az már vszg bukta, mert állat lassú lesz. De ha alkalmazás váltáskor swappel akkor nem gáz. -
Jester01
veterán
nem szerver lap, ha jól látom
Hát azért amin PCI-X van az szerverbe való. (ez mondjuk az integrált 8mb vgaból is látszik.)
Szerinted működne egy ilyen lapban az én RAID kártyám PCI 66 módban , a PCI 33 helyett
Szerintem igen. Hirtelen nem tudom milyen kareszod is van, de ha alaplapot cserélsz, akkor mindenképp PCI expresst ajánlom.
Létezik ilyen A64-ben ?
Azt a mindenit, ezt dobta ki a google
Abit SV-1 [link] Brutál 
[Szerkesztve]
Új hozzászólás Aktív témák
- HIBÁTLAN iPhone 13 256GB Pink -1 ÉV GARANCIA - Kártyafüggetlen, MS3732
- Thermal Grizzly Aeronaut paszta 3,9g /BONTATLAN/Több darab/Számlával/
- LG 55QNED823RE / QNED / 55" - 140 cm / 4K UHD / 120Hz & 4ms / HDR Dolby Vision / FreeSync + HDMI 2.1
- Apple MacBook Air 13 (2020) M1 8GB/256GB használt, szép állapot 87% akku (317 ciklus)
- Lenovo L14 Ryzen 5 4500U Refurbished - Garancia!
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest



A raid5 egy diszk kiesését tudja elviselni.





![;]](http://cdn.rios.hu/dl/s/v1.gif)
) lemezzel mûködik.

