Hirdetés
- Luck Dragon: Asszociációs játék. :)
- Luck Dragon: Alza kuponok – aktuális kedvezmények, tippek és tapasztalatok (külön igényre)
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- eBay-es kütyük kis pénzért
- sziku69: Szólánc.
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Klaus Duran: Minden drágul. Vajon a fizetések 2026-ban követi minimálisan?
- Lalikiraly: Asus Gaming V16 - RTX5050
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- sziku69: Fűzzük össze a szavakat :)
Új hozzászólás Aktív témák
-
-
Jester01
veterán
-
Jester01
veterán
Ha csak az egyik lemez hibásodik meg, akkor nem kell semmit sehová dugdosni mivel a raidnek éppen az az értelme, hogy ettől még használható marad a tömb.
Igen, ugyanaz lesz írva, viszont elképzelhető, hogy a lemez elején vagy végén van metaadat. Ha az elején akkor csak a megfelelő eltolás ismeretében lehet nem raid vezérlővel olvasni, vagy olyan programmal ami megkeresi a partíciót.
-
Jester01
veterán
Ha fontos adatok voltak rajta, akkor szinkronizálás meg bármi egyéb manipuláció előtt célszerű lett volna egy nem-raid vezérlővel blokk szintű másolatot készíteni, mert mi van ha most éppen a rosszat ráírja a jóra ...
Azt meg állandóan szajkózzuk, hogy a raid nem helyettesíti a biztonsági mentést...
-
Jester01
veterán
A 10 giga nagy, de a torrent magától nem másolgatja ide-oda, hanem darabokban letölti.
Azért terhelheti le mert a sok kis darabot nem összefüggő helyekre kell írnia, hanem össze-vissza de ezen a raid0 pont semennyit nem segít.Ötlet szinten azt érdemes szerintem kipróbálni, hogy az SSD-n elkerítesz egy részt az éppen futó torrenteknek (ami gondolom nem túl sok) és az elkészülteket meg átmásolod a merevlemezre (ez ugyanis már szekvenciális művelet lesz és viszonylag gyors).
-
Jester01
veterán
1. Akármennyivel lehet raid0.
2. Szerintem semmivel.
3. Kis fájloknál általában nem az átviteli idő a lassú, hanem a seek azon meg a raid0 nem segít. De amúgy legalább annyifelé kellene szétoszlania amennyi lemez van. Tehát 3 lemez, 512k blokkméret és 1MB-os fájl az nem jó mert csak 2 lemezre oszlik szét. -
Jester01
veterán
válasz
metrichye
#8879
üzenetére
sajna 32 bites a háló és ezek 64 bites rendszer adatai, így levágja a hosszú file-neveket.
Itt valamit nagyon összekevertél, a fájlnevek hosszát ez nem befolyásolja. Főleg ha a mentésed mondjuk tar-ban van.
Szoftveres raidnél simán működik az, hogy egy régi és egy új vinyó van benn, megcsinálod az újra a raid1 tömböt 1 hiányzó lemezzel, átmásolod rá a dolgokat, majd kicseréled a régi lemezt a másik újra és szinkronizálsz. Hardveres raidnél nem tudom hogy megy.
-
Jester01
veterán
válasz
#90933760
#8505
üzenetére
Itt valamit keversz. A raid0 fogja duplázni a szekvenciális sebességet, és mivel az nem tükröz ott semmi újraszinkronizálás nem lesz. Cserébe persze semmi hibatűrés sem.
Más kérdés, hogy ezt (mármint a szekvenciális sebességet) mennyire tudod majd kihasználni. Elvileg tisztességes raid1 viszont az elérési késleltetést csökkenti, ami lehet, hogy hasznosabb. Legjobb persze egy SSD lenne, de feltételezem az nem opció.
Az újraszinkronizálási időt megkapod ha az átlagos sebességgel leosztod a lemezméretet, pl. 74GiB/100MiB/s ~ 758s ~ 13 perc. Ha a szinkronizációra mesterséges sebességkorlátozás van akkor természetesen azzal kell számolni.
-
Jester01
veterán
Attól függ mennyi van használatban belőle illetve az üres helyet kinulláztad-e (vagy a mentő program ismeri a fájlrendszert és nem menti a nem használt területet.) Meg persze attól is mennyire tömöríthető cuccok vannak rajta. Átlagos esetben operációs rendszer esetén szerintem felével lehet számolni, szóval ha egy kis üres hely is van akkor rá is férhet.
De manapság 40 gigás vinyó ingyen van, tényleg nincs kéznél egy?
-
Jester01
veterán
Nem vagyok windowsos de régebben (mondjuk XP idejében) lehetett másik gépen olyan telepítőt csinálni amibe beleintegráltad a drivert. Miután megtaláltad a megfelelőt, persze. MOD: ami valószínűleg a "SiI3x12 32-bit Windows SATARAID Driver" vagy a 64 bites.
Illetve mintha az újabb windows telepítők már usb meghajtóról is tudnának drivert betölteni.
Szerintem kérdezz rá windowsos topikban. -
Jester01
veterán
Például melyik? Mert az összes ami számít, az leginkább nulla. Tulajdonképpen csak a ki-be kapcsolások száma, az üzemidő, a felpörgési idő és a hőmérséklet nem.
Sserintem ezek teljesen egészséges lemezek. A problémát én máshol keresném, például a leállítási folyamatnál (ha jól értem azután esik szét a tömb).
-
Jester01
veterán
Mind a kettő
SATA2 elvileg 300MB/s portonként, PCIE 2.0 x1 pedig 500MB/s (igaz, full duplex).
Egy mai SSD simán hoz 400MB/s-et egymaga, tehát a SATA2-n eleve nem fér át, a 2x400 meg a PCIE linken nem.Ugye nem szekvenciális elérésnél már alacsonyabbak az értékek tehát ott várhatóan nem lesz szűk keresztmetszet.
SSD-nél továbbá fontos kérdés, hogy a TRIM működik-e rendesen.
-
Jester01
veterán
Ha raid0-át használsz akkor valószínűleg a szekvenciális átvitelre van kihegyezve a rendszered (hogy ennek van-e értelme abba ne menjünk bele, feltételezem te biztos megvizsgáltad a kérdést).
Ez a kártya eleve SATA2-es portokat ad, és x1-es PCIE csatolóval van. Ez gyakorlatilag azt jelenti, hiába kötsz rá 2 tipikus SSD-t, kb. egynek a teljesítményét sem fogja hozni.
Bár van rajta puffer memória, de sehol nem írják és nem is látszik, hogy saját áramforrása lenne tehát ettől nem nő a biztonság. "NVRAM for RAID event & transaction log" - ez valamit segíthet, bár gondolom csak eseménynaplózás.
-
Jester01
veterán
válasz
djculture
#8262
üzenetére
Ez nem a merevlemez hibája. Ő nem tudja, hogy raidben van-e, csak ATA parancsokat teljesít. Ha lekérdezed a smartot meg fogja mondani akár raidben van akár nem. Bizonyos raid vezérlők/driverek rejtik el az egyes lemezek állapotát. Nem tudok róla, hogy e tekintetben a "raid edition" bármiben más lenne. Nekem volt RE és több fajta nem RE is, smartot mindig le lehetett kérdezni (linuxos szoftraid esetén).
Sőt, ha valamelyik lemez konkrét olvasási műveletnél hibát jelez adott szektorra, akkor a raid rendszer másik lemezről felülírja a szektort, így az a tartalélterületre kerül és a továbbiakban olvasható lesz (már amíg van tartalék és redundancia, ugye).
-
Jester01
veterán
Hogy a windows mit csinál és mit nem az más kérdés.
Ettől még a "Miért vártad, hogy gyorsabb lesz?" kicsit erős volt - igenis jogosan várta volna el, ha egyszer szerinted is lehetséges.Az olvasást a Raid 1 nem gyorsítja. - ebben meg eleve nem volt szó windowsról, olybá tűnik mintha általános érvényű kinyilatkoztatás lenne.
-
Jester01
veterán
Megfelelő implementáció és feltételek esetén gyorsítja, mivel a lemezekről lehet párhuzamosan olvasni. Például ha 2 szálon különböző helyről olvasol szekvenciálisan, de adott esetben akár 1 szál esetén is. Ezen felül az átlagos elérési időt is csökkentheti.
Az írást nem gyorsítja, mivel azt mindegyik lemezre végre kell hajtani.
Pista0001:
-
-
#8142
Jester01
veterán
eladohardver
#8141
Jester01
veterán
válasz
eladohardver
#8141
üzenetére
-
Jester01
veterán
És azt melyikőtök olvasta el amit vastagon kiemeltem?
Gy.k. azt nem feszegettem, hogy van-e értelme, csak arra az állításra reagáltam, hogy nem gyorsulna.Egyébként attól mert sokat olvasol még egyáltalán nem biztos, hogy sokat is írsz. Továbbá ez az elhasználódás pontosan ugyanolyan lesz egy nagyobb vagy két fele akkora ssd esetén is, tehát jelen vitában nem tényező.
-
Jester01
veterán
válasz
fogtunder
#8124
üzenetére
Kivéve, ha már a SATA a szűk keresztmetszet. Mai SSD-k azért már tudnak 400-500MB/s szekvenciális átvitelt, aminek a duplája már nem fér át SATA3 kapcsolaton sem. Tehát ha ez fontos akkor a raid biztos gyorsabb lesz.
Ammenyire én tudom egyébként a 64 gigásak szoktak kevesebb csatornát használni, 128 és fölötte emiatt tipikusan nem fog már tovább gyorsulni. Például a vertex4 128GB-os már 500 ill. 400MB/s-ot tud írni/olvasni, és a 256-os bár kicsit gyorsabb de közel sem duplája.
-
Jester01
veterán
válasz
Cooley18
#8002
üzenetére
Ha a 640-esről bootolsz, akkor csinálj a másik kettőből szoftveres raid-et az oprendszer segítségével.
P-SZ-S: egy ide csatornán max. 133MB/s megy át. Ha két eszköz van rajta, akkor ezen osztoznak. RAID sem fog csodát tenni. Vegyél inkább ide-sata átalakítót (ha sata portod van) vagy pci vezérlőkártyát.
-
Jester01
veterán
válasz
djculture
#7795
üzenetére
A macerásabb, de teljes mentést nem igénylő módszer pedig: kinyomozod melyik az a két szektor és melyik fájl(ok)hoz tartozik majd célirányosan csak az érintett szektorokat írod felül illetve a fájlokat a biztonsági mentésből visszaállítod.
Ja még egyszerűbb (csak lassabb), mivel raid10 van és csak az egyik vinyó hibázik: kiveszed a diszket majd visszarakod. A szinkronizálás majd felülírja az olvashatatlan szektorokat.
-
Jester01
veterán
Ez igaz, de ahhoz már igen durva diszkeknek (vagy nagyon soknak) kellene lennie, hogy ez korlátozzon valamit (mondjuk SSD-kkel már elképzelhető). A te resynced is biztos más okból volt lassú, nem azért mert szoftveres. Esetleg mert vacak a driver vagy van benne gyári limit. Mint például a linuxos szoftraidben, persze ez állítható:
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction. -
Jester01
veterán
-
Jester01
veterán
Ha az sdc1 még megvan akkor inkább azt tedd vissza a tömbbe ne az sdb-re próbálj partíciós táblát varázsolni - ha az eltűnt, ki tudja mi lett a többi adattal. Az alapvető probléma viszont az, hogy ha el is indul a tömb, nem lehetsz biztos benne, hogy jó az adat.
Egyébként ha teljes mentést nem is csinál az ember, ilyen esetek miatt érdemes legalább valami ellenőrző összeget tárolni a fájlokról.
-
Jester01
veterán
Elvileg ilyennek nem lett volna szabad történnie. Egyrészt ugye a raid5 elvisel egy diszk hiányt, másrészt ha szétesik a tömb akkor nem lesz md0 eszköz. Gyanús, hogy az ismerős elhallgat valamit
Mindenesetre első körben meg kellene nézni mi van a /proc/mdstat-ban illetve az mdadm --detail /dev/md0 mit mond.
-
Jester01
veterán
az APC nél dolgoztam ...
a szünetmentes tápegység ott kezdődik hogy, 120E ft ...Mert az olcsóbb modellek helyett vackokat gyártottatok?
Biztos van rá konkrét okod, de az én gagyi tizenpárezres szünetmentesem is pont elég arra, hogy az oprendszer leálljon ha áramkimaradás van.A szoftveres raiddel szemben milyen ellenérzéseid vannak? Már feltételezve, hogy a szünetmentes megvan.
Az SSD-nek meg nem a szekvenciális átvitel a lényege hanem az elérési idő az meg sata2-vel is szépen kijön. Persze hogy ki tudod-e használni értelmesen az az adott feladattól függ.
-
#7641
Jester01
veterán
szelesjanos
#7640
Jester01
veterán
válasz
szelesjanos
#7640
üzenetére
Akkor szerintem kész.
Egy ilyen képet gugliztam:
Tehát a státusznál írná, hol tart.
-
#7639
Jester01
veterán
szelesjanos
#7637
Jester01
veterán
válasz
szelesjanos
#7637
üzenetére
De a tömb státusza csak ott van
-
Jester01
veterán
válasz
fsb1000
#7631
üzenetére
Ha magától nem ismerte fel, akkor kézzel kell összerakni:
mdadm --assemble --scan
Ha ez sem megy, akkor még jobban kézzel:
mdadm --assemble /dev/md0 /dev/sdX /dev/sdY
Ahol X és Y értelemszerűen a megfelelő eszköz betűje.
A fentiek után már csak csatolni kell valahová, például:
mount /dev/md0 /mnt
-
Jester01
veterán
válasz
djculture
#7620
üzenetére
egy raptor 10ms lett nekem 3-nál 7ms tehát csak csökken.
Mágia
Vagy van értelmes magyarázatod rá? (Már ha teljes tömbre nézted)érezhetően hamarabb a boot is.
Ez nyilván hihető, mert nőtt a szekvenciális sebesség illetve az adatmennyiségre vetített elérés csökken (kevesebb fejmozgással érhető el ugyanannyi adat).
Máshogy mondom. Ha csinálsz egy adott méretű partíciót egy lemezen illetve egy raid0 tömbön, akkor az elérési idő csökken. Ha viszont az egész lemezt/tömböt kihasználod akkor az elérési idő nem változik (viszont több adatot fogsz át).
Ugye a raptor 10000RPM, vagyis az átlagos rotational latency 3ms. Ez aztán tényleg nem változik akármennyi lemezt is teszel a tömbbe, tehát ennél jobb sose lesz, SSD-t nem tudod megközelíteni (azok 1ms alatt vannak). A seek időt tudod adatmennyiségre nézve amortizálni.
-
Jester01
veterán
válasz
djculture
#7618
üzenetére
Ezt nem tekintem hiteles mérésnek
Ha belegondolsz, az egész tömböt átfogó seek az értelemszerűen az egyes lemezeket is teljesen átfogja, tehát pont ugyanannyi mint egy lemeznél. A track-to-track seek sem változik (csak a logikai track méret nő) és a rotational latency is ugyanannyi.
Hogy a windows mit mér azt nem tudom.
-
Jester01
veterán
válasz
djculture
#7616
üzenetére
Attól függ hogy méred. Ha a kapacitásra arányosan és a tömböt alkotó lemezek közül egyetlen darabhoz képest, akkor igen. Csak nem így szokás.
Legyen egy lemez x GB, és legyen 4 lemezes tömb. Adott elérési idővel így nyilván 4*x GB adatot tudsz átfogni, így ez csökkenésnek vehető. Ha viszont egy darab, de 4*x GB kapacitású lemezhez képest nézed (ami egyébként technológiailag azonos paraméterekkel bír, csak például több tányér van benne) akkor pont ugyanannyi marad az elérési idő.
A hagyományosan számított elérési idők sem változnak.
-
#7613
Jester01
veterán
teglasatesz
#7610
Jester01
veterán
válasz
teglasatesz
#7610
üzenetére
A sebességérzetet (bizonyos minimális szekvenciális sebesség megléte mellett) elsősorban az elérési idő befolyásolja, azt pedig nem könnyű RAID bűvészkedéssel csökkenteni. Tükrözés használatával az olvasási műveletek elméletileg a tükrök számának megfelelően gyorsulnak. Hátránya, hogy az írás nem gyorsul és az olvasást is akadályozza, illetve természetesen a tárolókapacitás.
4 lemezzel esetleg érdemes lehet RAID10-et megpróbálni.
-
Jester01
veterán
A raid nem helyettesíti a biztonsági mentést. Elsősorban a rendelkezésre állást növeli, mivel hot swap esetén menet közben lehet cserélni a halott diszkeket.
Biztonsági mentés mindig kell, ilyen az élet. Például egy táp hiba kinyírhatja az összes diszket egyszerre, vagy leéghet/ellophatják a gépet, vagy egy diszk kiesése után belefuthatsz a hírhedt URE jelenségbe.
Ja és persze emberi hülyeség és/vagy programhiba hibátlan hardveren is törölheti az adatokat véletlenül.
Ha meg a raid kártyád megy tönkre és nem tudsz ugyanolyat szerezni, az se kellemes. Legyen abból is tartalék.
-
Jester01
veterán
válasz
Geller72
#7593
üzenetére
Azokat a szerző direkt törölte.
Szerencsére a web.archive.org lementette az utókornak:
Első rész
Második rész
Harmadik rész -
Jester01
veterán
válasz
Enigma^
#7559
üzenetére
A raid-z többek között azért jobb a hagyományos raid megvalósításoknál mert:
1) dinamikus stripe méretet használ így nem probléma a részleges stripe írás
2) van ellenőrző összeg így észreveszi a hibákat, illetve tudja javítani azokat
3) egyben van a fájlrendszerrel, így tudja mi használt és mi üres (például szinkronizációnál jól jöhet)Természetesen bármelyik linux tud neked raid-z-t csinálni, ha felpakolod a zfs támogatást.
HUfantom: Csak elvileg jobb - Miért is? Ezek kőkemény gyakorlati hasznok.
-
-
Jester01
veterán
Megmondhatod közvetlenül az eszköz nevet is, jelen esetben /dev/md0 ami nem millió karakter. Ez normál esetben viszont függhet attól, hová van dugva. Pl. ha felcserélsz 2 lemezt akkor gond lehet. Ha a fájlrendszer azonosítót adod meg, akkor mindenképp megtalálja. Ez egyébként nem olyasvalami amit percenként szerkeszt az ember, továbbá egyáltalán nem is kell begépelni mert a konfiguráció frissítő kiolvassa magától. Persze parancssorból is le lehet kérdezni, például:
# blkid /dev/md0
/dev/md0: LABEL="root" UUID="4a88c5b8-6faf-4fbd-99e3-558736fd6970" TYPE="ext3"Innen már triviális konfig fájlba másolni.
A legegyszerűbb megoldás egyébként megcímkézni a fájlrendszert, ez rögtön egyesíti a két megoldás előnyeit. Nem kell sokat írni, beszédes és nem változik. Nekem ugye root-nak hívják tehát ezzel a kicsit fura szintaxissal lehet is rá hivatkozni: root=LABEL=root
-
Jester01
veterán
Elhiszem. Érteni mondjuk nem értem, de ez van.
* Bár sql szerverrel még érthetem is, mert az konzisztencia miatt lehet, hogy gyakran kikényszeríti a lemezre írást ezért az oprendszer nem tudja hatékonyan használni a saját cache-ét. Az adatok első körben viszont csak a vezérlőig mennek, ami rögtön azt hazudja, hogy kikerültek a lemezre így a rajta lévő cache kihasználható. -
#7502
Jester01
veterán
sellerbuyer
#7501
Jester01
veterán
válasz
sellerbuyer
#7501
üzenetére
/boot/grub/grub.cfg lett módosítva
Lehet, hogy ott rontottad el. Nálam ugyanis az a file így kezdődik:
# DO NOT EDIT THIS FILE
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grubAz update-grub újragenerálja ezt a fájlt, és minden bizonnyal felülírja bármit is módosítottál benne. Nézd meg még mindig a jó beállítások vannak-e benne. Ha nem, akkor valószínűleg ez történt. Két választásod van, vagy átírod megint de nem futtatod az update-grub parancsot vagy bootoláskor grub konzolba beírod a helyes verziót. Mindkét esetben ha sikerül beindítatni a rendszert akkor futtasd az update-grub-ot és ellenőrizd, hogy az már a jó root eszközt írja bele a konfigba.
-
#7499
Jester01
veterán
sellerbuyer
#7497
Jester01
veterán
válasz
sellerbuyer
#7497
üzenetére
Szerintem egyszerűen az a baj, hogy a két bejegyzésnek ugyanaz a neve. Írd bele az elsőbe, hogy raid vagy akármi.
Krix: nem igazán látom mire kell annyi memória bár tény hogy ilyen tapasztalatom nincs. Látatlanban viszont azt állítom, hogy az oprendszer cache a rendszermemóriában sokkal gyorsabb, nagyobb és "közelebb van". A kártyán lévő csak addig kell amíg a vezérlő kimókolja, hogy mit is csináljon az adatokkal. Az meg normálisan méretezett célprocesszorral csak nem lehet szűk keresztmetszet.
-
#7493
Jester01
veterán
sellerbuyer
#7492
Jester01
veterán
válasz
sellerbuyer
#7492
üzenetére
BIOSban átállítottad a bootot a másik vinyóra? Mert addig az sda-n lévő grub fog indulni, ami gondolom továbbra is az sda1-re mutat (persze semmi akadálya, hogy akár azzal indítsd a md0-ról)
-
#7491
Jester01
veterán
sellerbuyer
#7490
Jester01
veterán
válasz
sellerbuyer
#7490
üzenetére
Igen. dd-vel csak akkor lesz jó ha a partíció(k) mérete egyezik, ráadásul az a nem használt részeket is fölöslegesen másolja, továbbá nem is defragol. Mindenesetre akár dd akár fájl másolás, csak read-only mountolt partícióról lesz jó. Miután a rendszer már felállt az új md0-ról, akkor a másik diszk (sda) már nincs használatban tehát hozzá lehet adni a tömbhöz.
-
#7488
Jester01
veterán
sellerbuyer
#7487
Jester01
veterán
válasz
sellerbuyer
#7487
üzenetére
Működő rendszert továbbra is csak úgy lehet áttenni, hogy átmásolod a cuccokat a tömbre és csak utána adod hozzá az eredeti lemezt. Ehhez persze az új tömbnek hiányosnak (degraded) kell lennie.
-
Jester01
veterán
A sebessége már már vetekedni fog az SSD vel
A szekvenciális olvasás az lehet. De a véletlen elérés az még mindig legalább tízszer lassabb lesz egy SSD-nél. Csak a forgásból adódó késleltetés (rotational latency) 4ms fölött van.
A WIn 7 boot, majdnem annyi idő mint SSD-vel.
Ez azért lehet mert a windows ha jól tudom optimalizálja a bootolást.
sellerbuyer: elvileg semmi dolog nem lesz vele, de az ubuntuból persze bármit kinézek
rigo88: amit venni tudnék az egy 30gb-s ssd, ennek az árnak csaknem feléért viszont vásárolok 2db 160as raptort
Kicsit le lehetek maradva, már 120-as SSD-t kapni 30 ezerért, akkor mennyiért osztogatják a raptorokat? -
#7472
Jester01
veterán
sellerbuyer
#7471
Jester01
veterán
válasz
sellerbuyer
#7471
üzenetére
Egyfelől nem függ az alaplapi cucctól, tehát lap csere után sincs semmi gond. Másfelől menet közben tudod kezelni a tömböt, tehát például hot-swap vinyócsere, átméretezés és raid szint konverzió is sima ügy. A diszkeket egyenként látod, így smart is van. Ugyanazokon a lemezeken több tömböt is létre tudsz hozni. Nem függsz az alaplapi cucc ki tudja milyen minőségű driverétől, és egységes eszközkészletet használhatsz. Paritásszámításos raid szinteknél a linuxos szoftverraid igyekszik a leghatékonyabb módot megtalálni, ehhez akár SSE optimalizált kódot is használ ami sima a driverben lehet, hogy nincs.
Hirtelen ezek jutottak az eszembe, lehet, hogy van más is.
-
#7470
Jester01
veterán
sellerbuyer
#7469
Jester01
veterán
válasz
sellerbuyer
#7469
üzenetére
Linuxon legcélszerűbb a saját software raidet használni hacsak nincs nagyon profi hardveres kártyád. Alaplapi raid izék helyett, főleg raid1-ben, mindenképp.
File szintű másolás (live cd vagy read-only mount) és grub telepítés, röviden ennyi kell. Nem tudom hol buktad el.
-
-
#7386
Jester01
veterán
sellerbuyer
#7385
Jester01
veterán
válasz
sellerbuyer
#7385
üzenetére
Azért lássuk be, a normál használat az mentés az aktuális rendszerről és szükség esetén visszaállítás ugyanolyan konfigurációba. Ilyen mentés és konvertálás az nem alapművelet.
Bonyolultnak éppen nem bonyolult, csak időigényes.
Ha már nem működik a régi rendszered, akkor az egyik új lemezre visszaállítod a mentést, különben egyszerűen beteszed az új lemezt (akár hot swap). Megcsinálod a raid tömbö(ke)t és a partíciókat. A read-only mountolt partíciókat fájl szinten átmásolod. Utána bebootolod a rendszered úgy, hogy a hátralévő partíciók is csak olvashatóra legyenek csatolva (live cd is használható). Ezeket is átmásolod, boot managert (grubot) felteszed. Ezután az új lemezről indítod a rendszert, a régit pedig hozzáadod a tömbhöz amire a linux magától szinkronizál.
-
Jester01
veterán
Attól is függ, hogy amíg csak 3 diszk van, szükséges-e a hibatűrés. Mert megcsinálhatod degraded módban (vagyis mintha egy lemez kiesett volna a 4 lemezes tömbből) és akkor a 4. lemez berakása csak egy normál szinkronizálás lesz, nem kell varázsolni.
Vagy igény szerint csinálhatsz 3 lemezes tömböt, majd a 4. csak spare (tartalék) lesz.
-
#7362
Jester01
veterán
szelesjanos
#7360
Jester01
veterán
válasz
szelesjanos
#7360
üzenetére
Ez még mindig elég gyengécske
#7361: mondjuk, hogy a write cache bekapcsolásától miért gyorsult az olvasás azt nem tudom.
-
#7351
Jester01
veterán
szelesjanos
#7350
Jester01
veterán
válasz
szelesjanos
#7350
üzenetére
A -1% CPU és a 0.0ms különösen valósnak tűnik
Valami nagyon nem jó a méréssel ... -
#7317
Jester01
veterán
szelesjanos
#7316
Jester01
veterán
válasz
szelesjanos
#7316
üzenetére
Felejtsd el azt a kártyát. Vegyél olyan lapot amin van 5 SATA csatlakozó és csinálj szoftveres raidet.
-
#7309
Jester01
veterán
szelesjanos
#7308
Jester01
veterán
válasz
szelesjanos
#7308
üzenetére
Ha elég erős vagy
PCI illetve PCI-X kártyát ugyanis nem lehet PCI Expressz slotba dugni. -
Jester01
veterán
válasz
djculture
#7255
üzenetére
A 10% egyébként nem a világvége, azt meg kétlem, hogy emellett még vissza is fogta volna a vinyó sebességét. Minden bizonnyal ment ahogy a csövön kifért. Nekem az nforce2 minden gond nélkül hozta raid0-ban az egy lemezhez képest dupla sebességet, athlon xp 2400+ procival anélkül hogy "horror tempója" lett volna. Nyilván 4 diszk esetén már a busz lehet a szűk keresztmetszet ahogy azt fentebb említették is. Persze attól is függ, alapból milyen gyorsak a diszkek.
brd:
-
Jester01
veterán
válasz
djculture
#7252
üzenetére
Évekig használtam szoftveres raid1-et xp procival nforce2 lappal, nem terhelte le. Miért is tenné? Még csak paritást sem kell számolni, felejtsétek már el ezt a prociterhelős marhaságot.
Amúgy a déli híd által biztosított ide portok nem biztos, hogy ugyanazon a pci buszon vannak (neten fellelhető diagramok alapján), tehát azzal még akár azt a problémát is meg lehet kerülni ide-sata átalakítóval.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Gy.k. azt nem feszegettem, hogy van-e értelme, csak arra az állításra reagáltam, hogy nem gyorsulna.
Új hozzászólás Aktív témák
- Adguard Premium (Android, PC és egyéb rendszerekre, valamint böngészőkhöz)
- Apple Watch Sport - ez is csak egy okosóra
- Youtube Android alkalmazás alternatívák reklámszűréssel / videók letöltése
- Luck Dragon: Asszociációs játék. :)
- Debrecen és környéke adok-veszek-beszélgetek
- AMD FX
- Eddigi legjobb DxOMark helyezésével zárta 2025-öt a Vivo
- Hardcore café
- Picit gazdaságosabb és halkabb lett a PlayStation 5 Pro legfrissebb verziója
- Sorozatok
- További aktív témák...
- BESZÁMÍTÁS! ASUS H510M i5 11400F 16GB DDR4 500GB SSD RTX 2060 6GB Zalman T4 Plus Cooler Master 650W
- GYÖNYÖRŰ iPhone 13 mini 128GB Starlight -1 ÉV GARANCIA - Kártyafüggetlen, MS3133, 95% Akkumulátor
- Dell Latitude 7420 Core i7-1185 G7, 16GB RAM, SSD, jó akku, számla, 6 hó gar, szép állapot
- Felsőkategóriás Gamer PC! Csere-Beszámítás! R9 9800X3D / RTX 5080 16GB / 32GB DDR5 / 2TB SSD!
- GYÖNYÖRŰ iPhone XR 128GB Black-1 ÉV GARANCIA - Kártyafüggetlen, MS3985, 100% Akkumulátor
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest