Hirdetés
Új hozzászólás Aktív témák
-
Valamiért a vártnál lassabb az 5 HDD-ből álló Btrfs RAID-5 olvasási sebességem, mint amit várnék (most itt próbáltam erre segítséget kérni: [link]), sőt azt hiszem pár éve írtam erről a Btrfs mailing list-re is, de ott sem érdekelt senkit.
Most megnéztem, és úgy látom, hogy már jó alternatíva lehet a Windows Storage Spaces Parity móddal és ReFS-el (mikor legutóbb változtattam bármit, akkor még nem működött a "self-healing" Parity módban és még nagyon érzékeny volt a ReFS, pl. simán mountol-hatatlanná vált egy szimulált áramszünettől, de az még Win8 időkben volt).
Ez itt azt is szépen leírja, hogy miként lehet összehozni a Parity móddal azt, hogy elérjük a HDD-k írási sebességét (a filrendszer 'allocation unit size' egyenlő kell legyen az "interleave size" x 'data coulms' értékkel).
Sőt, ahogy olvasgattam, úgy tűnik, hogy manapság hozzá lehet adni SSD-ket is a Storage Space pool-okhoz cache-ként, amit már ~10 éve is ígértek a Btrfs-hez, de még ma sem foglalkoznak vele a programozók (csak akik érdeklődnek felőle).
A másik az RDMA, mert az is 10+ éve "majd lesz, egyszer" a Samba-ban.Kérdések:
- Mi a minimális interleave méret? (Nem akarok "hatalmas" FS allocation unit méretet.) Sehol sem találom dokumentálva, hogy mi a min/max.
- Hozzá lehet adni sima desktop edition Windows 11 Pro-n 1 szál NVMe SSD-t read-only cache-ként (nem WBC-ként! -> ennek szükségességét ki akarom ejteni a fenti trükkel) a parity mód SS pool-hoz, ha read-only módba rakom, vagy ezt csak a Windows Server Edition engedi meg (ha az egyáltalán olyankor, mikor nem cluster-ben van, hanem solo)? Olvasgattam erről a dokumentációt, de nem teljesen egyértelmű (az elején leírja, hogy csak cluster esetén használható az egész, de semmi okát nem látom, hogy miért ne lehetne 1 szál SSD a read-only cache, ha egyszer ott van mögötte a parity mód tár, amiből előkotorhatja azt, ami esetleg elszáll az SSD-vel együtt).
- Tényleg elég stabil már a ReFS? (Nem lesz mountol-hatatlan minden tüsszentéstől?) Vagyis inkább van már annyira stabil, mint a Btrfs?Jó, tudom, talán le tudnám ezt tesztelni (valamennyire), ha összehoznék az asztali gépemen egy virtuális gépet 5 virtuális HDD-vel és egy virtuális NVMe eszközzel, de az nem 2 perc.
[ Szerkesztve ]
-
válasz
janos666
#9107
üzenetére
Hát szerintem ne használjátok a ReFS-t.
Az előbb lefagyott a Windows (RAM-ot cseréltem a gépben és első bootolás után kiderült, hogy ebben az alaplapban/processzorral és/vagy ezek a példányok mégsem bírják azt, ami a matricájukra van írva, úgyhogy most ledobtam a setup-ban választható legkisebb órajelre).
Aztán észrevettem, hogy ez a ReFS filrendszerű meghajtó nem érhető el többé.
Hibát észlelt, nem tudta javítani, úgyhogy elhajította az egészet egyben.
Féltem ilyesmitől, amikor a működéséről olvastam, de próbáltam ezt letesztelni. Mikor szándékosan hibát tettem egy ReFS-el formázott meghajtóra (Linux dd-vel felülírtam véletlenszerű szektorokat), akkor olvasható maradt a file többi része, csak a hibás részeknél dobott hibát (pl. egy videót tudtam tekergetni, csak megállt ha épp oda tekertem, ahol hibás volt). Most viszont egy szimpla rendszerösszeomlás miatt eldobott mindent.
-
Közben eltöltöttem még némi időt az SS és ReFS tesztelésével.
Nagyon úgy tűnik, hogy csak Mirror SS-en és Microsoft féle software RAID-1 köteteten működik a ReFS auto-healing, Parity SS-en (még?) nem (és ahogy sejthető volt, [fake-]hardware RAID-5 esetén sem -> nem is tudom miként működhetne direkt erre írt új API-k és azok kétoldali támogatása nélkül, de volt aki azt állította, hogy szerinte működik
).Viszont ez nem olyan nagy probléma, mint ahogy féltem tőle, mert enélkül sem érvényteleníti az egész file-t a ReFS, ha az integrity stream alapján hibásnak ítéli. Egyszerűen csak dob egy read error-t és bejegyzi az eseményt a rendszernaplóba, de nem törli a filet.
Tehát (fake-)hardware RAID-5 köteten is használható a ReFS, és ha olvasáskor észreveszi a hibát, akkor lehet kézileg javítani a RAID-5 tömböt (már ha lehetséges), aztán újra nekifutni a file kiolvasásának. Szóval ilyen tekintetben hátrányok nélkül élvezhetőek a ReFS előnyei SS nélkül is.
Így az is mindig kiderül, ha nincs hibás szektor a HDD-n (amit felismerhetne a SMART self-test és/vagy egy RAID-5 partol read is, remélhetőleg ebben a sorrendben), hanem valami másért hibás a file, pl. elszállt valamitől a rendszer (áramkimaradás, CPU/RAM tuning/hiba, driver okozta kernel crash, stb).Így tehát a jelentős szekvenciális írási sebességben mutatott előnye miatt maradok az IRST RAID-5 megoldásnál Parity SS helyett, de ReFS-el formázom, méghozzá a gyökérmappából kiindulva engedélyezett integrity stream-el (és így nem fogom bekapcsolni az IRST ütemezett hibaellenőrzését).
Ennek két hátránya van: Nem tudok egyszerűen AMD platformra váltani, ha valamiért épp azt szeretném (az SS-t ez nem érdekelte volna), és nem tudom majd használni a ReFS partíción lévő file-okat Linux alól (ez igaz lenne a Parity SS-re is). Bár előbbi nem túl valószínű (csak addig gondolkodtam a Kaveri-n, míg megláttam az első eredményeken, hogy CPU-nak lassabb, mint a jelenlegi CPU-m, a HSA-t pedig úgysem használja még semmi), utóbbi pedig idővel változhat (idővel az NTFS olvasás, majd írás is megoldott lett Linux-on, ez talán még hamarabb fog - vagy nem, de nagyon valószínűtlen, hogy olvasnom vagy akár írnom kéne erre az adattárolóra Linux alól).
--
Azt viszont nem értem, hogy most miért jár 52%-on ~20 óra után az IRST RAID-5 inicializálás. Nem kértem, hogy tartsa meg bármely HDD adatait, mikor létrehoztam a tömböt, tehát igazából nem is tudom miért fontos neki korrektül végigmenni faltól-falig. Úgysem érdekes, hogy mi van most bármely lemezen, és mikor legelőször ír rá valamit, már úgyis rögtön szinkronban fog. Most csak újraszámolja a paritást a random, használhatatlan adatra, amit épp talál. És még ahhoz képest is szokatlanul lassú most.
-
Sőt, lehet hogy ez a ReFS féle auto javítás csak félrevezető módon lett megfogalmazva és igazából épp parity SS-en nem működik, hanem csak mirror SS-en.
Az egyik SS doksi pont úgy fogalmaz, hogy parity SS-en működik (és az a szövegrész nem is említi a mirror SS-t), de aztán odaszúr egy megjegyzést, hogy mirror SS-en már most is működik, és ezzel azt sugallja, hogy parity SS-en még nem -> de akkor a fő szövegtörzs miért épp a parity SS-t említi?
Hogy tudnám ezt letesztelni magamnak?
Próbáltam átmásolni egy szép nagy filet a parity SS-en lévő ReFS particióra, aztán Xubuntu Live-ból dd-vel belepiszkítani az egyik HDD elejébe, de attól rögtön kidobta az SS a HDD-t, nem tudtam végigolvastatni a filet, hogy filerendszer szinten mi történik ha hiba jön. -
Létrehoztam egy 16Gb-os területet, megformáztam FAT32-vel, és ugyan olyan lassú volt az írás, mint NTFS-el., pedig a FAT nem naplóz...
-
válasz
janos666
#9100
üzenetére
Lemezenként 256Mb tárhely tűnik el, ami nagyon emlékeztet az MSR partíciókra. Valamint olvastam most egy olyat, hogy sokat javít az SS partiy pool írási sebességen, ha hozzáadunk a pool-hoz két (tükrözött) dedikált journyal disk-et. -> Az, hogy ez lehetséges, valami olyasmit sejtet, hogy az SS tulajdonképp partíciókat (gondolom GPT) dobál fel a pool-okhoz tartozó lemezekre és ezeken valamilyen filerendszerben (bizonyára NTFS, netán ReFS?) valamilyen VDH féleségeket (akár konkrétan .vhd file-okat?) dobál fel, és azok tárterületét fűzi aztán egybe a kötethez, és naplóz ezek írása közben.
Szóval, ha a paritásos SS kötetre írok, akkor naplóz a pool feletti lemezen lévő filerendszer és a pool alatti valódi lemezen lévő filerendszer is, amit az SS rendszer használ.
Ha ez így van, akkor sohasem lesz normális írási sebesség szinte semmilyen, de főleg nem paritás módban, de legalább kínozza a HDD fejeket, vagy teleaggatja az ember a gépét még pár HDD-vel dedikált köztes naplónak, amiből már csinálhatna RAID-0 kötetet is.Vagy "megérti" az SS a felette lévő fileerendszert, és annak a naplójár írányítja át más lemezekre? (Szóval ha van egy NTFS filerendszer a pool-on létrehozott virtuális lemezen, akkor annak az NFTS filerendszernek a naplói mennek a dedikált fizikai journal lemezekre???)
Valahogy egyik megoldás sem tetszik több különböző okból sem.
Túl szép volt ez az SS, hogy igaz legyen?
[ Szerkesztve ]
-
Felettébb örülnék én, ha azok a lila ablakok közel lennének a kékekhez (a pirosakat most hagyjuk, mert azok szándékosan hülyén vannak beállítva a teszt kedvéért, a zöld pedig egy olyan "rekord", amit egyébként sem szívlelnék, mert nincs szünet mentes tápom). Akkor nem is gondolkoznék, és el is kezdeném átmásolni az adatokat a régi RAID-5 + NTFS tárolóról ilyen Storage Space parity + ReFS tárhelyre.
Ezzel Intel chipset helyett csak Windows-hoz lennék kötve (bár gondolom előbb-utóbb [vagy már most is?] a Linux is kezeli majd ezeket a Windows-os pool-okat is, hisz nem sokkal bonyolultabb, mint bármely szoftveres RAID) és nem kéne többé tetszőleges időközönként chkdsk /B és/vagy IRST-s tömb ellenőrzést futtatnom (mert ugye szoftver RAID-nál nincs automata partol read, amit a Windows már megcsinál ReFS-el).
Közben legalább annyi jót tudok mondani, hogy a ReFS file data integrity stream-el együtt sem érzékelhetően lassabb (legalább is szekvenciális íráskor) ilyen parity storage space-en, mint simán NTFS-el.
Már így is évelődöm, hogy megelégszem ezzel az írási sebességgel és reménykedem, hogy később ahogy frissül a Windows, már csak gyorsabb lehet, mert amúgy nagyon kényelmesnek hangzik.
-
Eljutottam végre oda, hogy lecserélem a régi hírhedt Samsung winyóim WD Red-ekre, úgyhogy most csináltam pár benchmark-ot is, míg gondolkodtam hogy miként konfiguráljam.
Bár nem szigorúan RAID a Microsoft Storage Spaces féle paritás, de lényegében ez mégis kb. ugyan olyan szoftveres RAID-5, mint az Intel féle, úgyhogy talán jogos az összehasonlítás.
Illetve szívesen használnám a Storage Spaces-t ReFS-el, ha sikerülne rendesen belőni (úgy, hogy a filerendszer ellenőrizgeti olvasáskor, hogy hibás-e a file és ilyenkor tisztában van vele, hogy paritásos lemezen van, így automatikusan javítja is magát online, de nem csak HDD hiba esetén, hanem akkor is, ha pl. áramszünet miatt elszállt írás közben, stb, szóval lénygében mindig biztos lehetek, hogy helyesen lett kiolvasva minden file, és még akkor sem feltétlenül dől össze semmi, ha valamiért véletlenül nem...).
De úgy tűnik, hogy a konfiguráció, ami jól működik az Intel RAID driver-el, az a Storage Space-e nem igazán, és sehogy sem tudok belőle kicsikarni egy normális írási sebességet. (Itt még egyformán NTFS-el formáztam meg mindet.)
Játszott már valaki ezzel? Van erre ötletetek? Vagy "reménytelen"?
Persze RAID köteten is lehet még ReFS, de ahogy olvasgattam (bár még nem lehet túl sok infót találni róla), Storage Space-el lenne az igazi (olyankor érvényes, hogy maga a filerendszer tudatában van annak, hogy igazából egy paritásos RAID-5 féleségen ül, szóval olyan ZFS féleség, csak Windows-on...).
És végül is csak szekvenciális írással van a baj, Write-back módot amúgy sem nagyon szeretnék használni az IRST-vel sem.
*** Illetve meg kéne fejteni hová rejt el ennyi lemezterületet a Storage Spaces???
Azt láttam, hogy lecsíp valami hülyeségre ~700Mb-ot (valami olyasmi lehet, mint a Microsoft Reserved Space partíciók, minden lemezre egy-egy, csak itt manuálisan sem tudom megkerülni annak a létrehozását), de utána még Gb-ok tűnnek el. (Meg tudnék lenni a tárhely nélkül, de utálom ha akár csak 120Mb is abszolút feleslegesen van kidobva, maga a tudat zavar...)[ Szerkesztve ]
-
Talán nem minden AMD chipset-tel működik, és BIOS-t tekintve semmiképp sem visszamenően (tehát lehet, hogy a 990FX-el egyáltalán nem támogatott, és ha igen, akkor is frissíteni kell az alaplapi BIOS-t, de még akkor is lehet, hogy konkrétan az ASUS és/vagy konkrétan ennél az alaplapnál erre lusta volt, hogy kiadjon egy BIOS-t a friss SATA firmware-el, ami már tudja ezt).
Amúgy pedig próbáld letölteni a drivert közvetlenül az AMD-től, az frissebb szokott lenni, mint a gyártók csomagjai (főleg régi alaplapoknál).
-
válasz
HUfantom
#9038
üzenetére
Ezt konkrétan még nem teszteltem, de szerintem lassabb a 4 lemezből álló RAID-5, mint a RAID-6, és míg előbbi kevéssé, utóbbi még biztonságosabb, mint a RAID 1+0 (bármely két lemez is meghalhat, nem csak keresztben).
A szimpla alaplapi Intel/AMD/nVidia SATA chipset + szoftver driver RAID fokozottan érzékenyek arra, ha nem páratlan számú lemezből raksz ki RAID-5 tömböt. (Igazából érzékeny erre a dedikált CPU+RAM vezérlőkártya is, csak ott a RAM általában elrejti a problémát, legalább is, míg nem futsz ki belőle.) A CPU igény azért közel sincs az egekben a mai adattároló és CPU erőviszonyai mellett (utóbbi sebessége sokkal gyorsabban fejlődött, még akkor is SSD-kről beszélünk, de szerintem ezek HDD-k), nem olyan durva dolog az a paritásszámítás (feltéve, hogy nem valami olyan programot futtatsz, ami folyamatosan koppra szeretné terhelni a CPU-t, és közben rengeteg adatot szeretne kiírni a tömbre).
-
válasz
Pubszon
#9034
üzenetére
A BIOS/UEFI setupban a SATA módok közül (IDE/AHCI/RAID) a RAID-ot kell választani, aztán használhatod azt a textmode setup-ot is, ami a post képernyő után vár, vagy a Windows alatt telepíthető IRST driver vezérlőpanelét.
A két SSD-t átviheted egy másik Intel-es géphez, amin már fut Windows, és ott is megcsinálhatod, majd visszateheted a lemezeket az SSD-ket az eredeti helyükre.
Vagy talán megoldható ez valamilyen pendrive-ról futó OS-el is.Vagy bootolhatsz egy Linux-ot pendrive-ról, készíthetsz egy képfilet az SSD-ről egy HDD-re, megcsinálhatod a tömböt a post képernyő utáni kis textmode setup-al, vissza linux-ba, képfile fel a tömbre, aztán boot a tömbről.
[ Szerkesztve ]
-
válasz
soldi3r
#9033
üzenetére
Lényegében két választásod van:
RAID 1+0 : ~2 lemez írási és ~4 lemez olvasási sebessége, kisebb CPU használat
RAID-6: <=2 lemez írási és 2<x<=4 lemez olvasási sebessége, nagyobb CPU használat
Melyik tűnik jobb választásnak?
Van ettől egy még rosszabb: RAID-5 3db lemezből +1 hotspare, ami hülyeség, mert minden szempontból több értelme lenne aktívan használni azt a tartalékot akár 6 akár 1+0 tömbben. -
válasz
Pubszon
#9031
üzenetére
Megoldható, bár legtöbbször felesleges.
Semmire. A RAID kötetet egy szál lemeznek látja a Windows (még ha tudja is róla, hogy nem, akkor is így kezeli), ugyan az vonatkozik rá, mint egy HDD-ről költöztetnéd a Windows-t egy másik HDD-re (vagy épp SSD-ről SDD-re, vagy egyik RAID tömbről a másik RAID tömbre).
Sőt... Az Intel szoftvere felkínálja neked egy RAID-0 tömb létrehozásakor, hogy megtarthatod az egyik lemez adatait. Bár ehhez egy harmadik lemezről kell bootolni, nem futhat a Windows az építés alatt álló tömbről (mert a tömb létrehozásakor eltűnik az eredeti lemez és azzal lefagyna az OS, a tömb pedig sohasem jönne létre...).
[ Szerkesztve ]
-
válasz
Cpt.Zsöci
#9029
üzenetére
Ha sietsz és minimális munkával akarod megúszni, akkor most azonnal elkezded újraépíteni a tömböt, vagy ha ráérsz és inkább elébemennél a dolgoknak, akkor előbb tesztelgeted egy kicsit a kihullott lemezt (pl. teleírod csupa 0 vagy véletlenszerű adatokkal és visszaolvasod az összes szektort, hátha elakad valahol, helyez át közben szektorokat, stb).
Mielőtt nekiállsz újraépíteni, azért nem árt valahova lementeni egy másolatot a fontosabb adatokból. (Bár gyakorlatilag ha elakad, akkor is olvasható szokott maradni az ilyen szoftveres RAID-5 tömb.)
Amúgy nemrég csináltam ilyet én is szoftveres Intel RAID-5 tömbbel.
Gajjra ment egy WD winyó, elkezdtem újraépítnei, de nem sikerült, mert onnantól kezdve megállás nélkül köpködte a szoktorhibákat.
A tömb azóta is olvasható, ha végre visszajön majd a garanciás cseredarab, akkor újraépítem.Én sem sok helyen olvasom ezt, helyette inkább azzal van tele az internet, hogy:
1: a RAID-5 abszolút megbízhatatlan, mert egy esetleges újraépítéskor megeszi majd egy URE az egészet (elfelejtik, hogy ha jobb is a RAID 1+0 vagy 6, az 5 azért még mindig nagyságrendekkel jobb, mint egy szál lemez, dehát az 5 az akkor is szar otthonra is...)
2: a szoftveres RAID-5 használhatatlanul lassú, mert nincs dedikált írási gyorsítótár (ami általában egy bizonyos fokig nagyon jól elrejti többek közt azt a problémát is, mikor nem páratlan számú lemezből építesz RAID-5 tömböt) és dedikált processzor (szóval a mai gyors CPU-dból elpazarol egy otthoni körülmények közt gyakorlatilag elhanyagolható számítási időt).Ha 3 lemezed van RAID-5 tömbben, és 32k a stripe size, valamint 64k a filerendszer foglalási egység, akkor minden kiírandó kis egységet szét tud vágni a vezérlő 64/2=32+32 szeletekre, hozzá tud csapni még 32k redundanciát, majd 3 lemezre kiírni ezt a 32+32+32k szeletet.
4 lemeznél ez közel sem ilyen szép, mert tört értékek jönnek ki, amiket össze kell várnia egy gyorsítótárban, míg felesleges lemezműveleteket kell végeznie. Aztán ha betelik a gyorsítótár, akkor nagyon lassú lesz, és szoftveres vezérlésnél nem szoktak lehasítani túl sok RAM-ot erre a célre (nem úgy, mint ha egy kártyák van dedikáltan RAM csak erre a célra).
[ Szerkesztve ]
-
válasz
Cpt.Zsöci
#9027
üzenetére
Ez csak megjegyzés, de RAID-5 tömböt páratlan számú lemezzel érdemes építeni (3,5,7), főleg szoftveres vezérlésnél, ahol kisebb az írási cache.
Vedd ki a lemezt a tömbből és nézd meg, hogy mi a baja (pl. a HDSentinel is elárulhatja). Ezt vagy itt csinálod, vagy a Windows-os GUI-val. De átteheted egy másik gépbe is, és akkor ott semmit nem kell csinálni, hogy sima HDD-ként legyen felismerve.
Aztán, ha tényleg hibás és nem "javul meg" attól, hogy teleírod nullákkal, és még garanciás, akkor gariztasd, ha nem lehet, akkor vegyél egy másik ugyan ilyet. De lehet, hogy igazából semmi baja, csak valamiért azt hitte a vezérlő.
Ha "megjavítottad"/cserélted, akkor pedig újra kell építeni a tömböt.
[ Szerkesztve ]
-
válasz
ratkaics
#8997
üzenetére
10-es szinthez biztos megéri a külön kártya? Nekem már a 3 lemezes RAID-5 is hozta szoftveresen is, amit el lehetett várni maguktól a lemezektől ilyen módban. Egyedül a folyamatos automata patrol read funkció hiányzott, de alkalmanként indítottam kézileg és az is alacsony prioritáson ment, nem sokat zavart.
-
válasz
HUfantom
#8979
üzenetére
Az eloszlás sem egyenletes, de azt se felejtsük el, hogy ez tudtommal nem nyers statisztikai, hanem egy jogilag vállalt számérték. szerintem nem azt mondja a gyártó, hogy 10^14 az URE előfordulási valószínűsége (tehát nagy átlagban biztosan jön egy URE 10^14 bit után), hanem azt, hogy mindenképp ez alatt marad. Ő ennyit vállal a termékére, hogy nagy átlagban legalább ennyi bit írható fel URE előtt. Ennyi, vagy sokkal több is, de nem kevesebb. És csak itt köszön vissza az egyenlőtlen eloszlás, és lehet, hogy a 10^16 minősítésű termék is már élete legelső teleírása után bekap egyet, aztán egy hosszú további élet során egyet se.
Ha ez egy nyers visszatérési valószínűség lenne, akkor már minden consumer HDD tulajdonos csak úgy merne adatokat mozgatni, hogy előtte-utána checksum-ot számol rajtuk és ha nem is napi rendszerességű, de teljesen hétköznapi esemény lenne az, hogy ellenőrzés után újra meg kell kísérelni egy-egy file felírását, mert nem olvasható vissza hibátlanul.
-
Az "én még nem láttam"-om kívül van jobb érv is?
Én továbbra is csak azt látom, hogy akár RAID-1, akár RAID-5, ha kiesik egy lemez, akkor a megmaradt lemezekről nagyságrendileg ugyan olyan eséllyel tudod visszanyerni a tárolt adatokat. A RAID-5 csak picit parásabb, mert több winchesterhez kell imádkozni azért, hogy ne pont a backup/rebuil közben kövesse ő is társát a halálba, vagy dobjon URE-t.
De ez csak kétszeres kockázat, és továbbra sem "minden" forog a kockán, csak az a néhány bit, amit lehetetlen megbízhatóan kiolvasni.
Ha az egyik megmaradt lemezen lesz egy olvashatatlan szelet, akkor szerintem tök mindegy, hogy 1 vagy 5 tömb volt. Mindkettő csak egy szintű redundanciát adott.
Az szerintem már csak gyakorlati előny, hogy az 1 tömbről egyszerűbben és gyorsabban menthető az adat, ha baj történt, és speciális szoftver kellett hozzá.
Ugyanakkor mégis aranyszabályként emlegeti sok "szakember", hogy az 5 teljesen megbízhatatlan és manapság már nem is szabad használni az URE miatt, de bátran használható az 1, sokkal jobban megéri a plusz egy lemez árát a szerintük sokkal nagyobb biztonság.
Szerintem nem éri meg plusz egy lemez árát a kétszeres biztonság, ha még az sem abszolút biztonság. Ellenben a plusz egy lemezzel már RAID-6 is építhető, ami viszont nagyságrendileg biztonságosabb az egyszerű és egyszeri tükrözéstől (egy helyett két rétű redundancia).
Mondhatnánk, hogy a RAID-10 sem csak egyrétegű, de egy kicsit bizonytalanabb, miközben lemezigényesebb, mert itt is meghalhat két lemez is, de míg RAID-6 esetén mindegy, hogy melyik kettő, itt csak a szétszeletelt blokkok páros és páratlan oldalán egy-egy, nem véletlenszerűen (ez is azonos nagyságrendben mozog, de drágábban kapsz kevesebbet, nem ugyan azért az árért vagy olcsóbban).
[ Szerkesztve ]
-
Ez nekem még nem szentesíti ezt a "pro" szlogent, hogy a RAID-1 és RAID-10 az "de facto", míg a RAID-5 "semmire nem jó, mert jön az URE". Ez szerintem sokkal árnyaltabb. Olyannyira, hogy nem speciális körülmények közt gyakorlatilag szinte elhanyagolható a különbség. Mindkettő hasonlóan URE érzékeny és mindkettő hasonló mértékben sínyli meg azt meg.
-
Ha kiesik egy lemez, akkor még olvasható (vagy akár írható) a RAID-5 tömb.
Ilyenkor készíthetsz backup-ot (mindentől függetlenül érdemes is, mielőtt nekilátnál az újraépítésnek, mert az írással is jár, és nagy, hosszú művelet, ami nem csak URE miatt hiúsulhat meg).
Ha itt jön egy URE, az ugyan olyan, mint ha a szétesett RAID-1 esetén jönne az URE. Ugyan úgy nincs meg az a szektor máshonnan, amit nem lehet olvasni.Ha a RAID-5 vezérlője emiatt elhajítja az egész tömböt, és azt mondja nem is olvasható többé róla semmi, akkor is összerakhatod adatmentő szoftverrel olvasásra, és folytathatod a mentést, akár sokszor is megkísérelve újra és újra a problémás szektor kiolvasását.
Ugyan úgy előfordulhat RAID-1 esetén is, hogy nem sikerül valamit kiolvasni, és RAID-5 esetén is csak az az egy file sérül, amit az URE érintett, mint törött RAID-1 esetén.[ Szerkesztve ]
-
Alapvetően ugyan úgy megy tovább, mint előtte, hacsak nincs szándékosan beállítva valami script, hogy fusson le hiba esetén, pl.: álljon le a munka, kezdjen el backup-olni, riasszon, kapcsoljon le.
Amíg egyedül van a lemez, addig pont olyan, mint ha egy hagyományos egy lemezes rendszer lenne. Írható, olvasható, egy lemez sebességét hozza.
---
Én most azon gondolkodtam, hogy egy szimpla egyszer tükrözött RAID-1 is csak kétszer biztonságosabb, mint a RAID-5, előbbit mégis etalonnak, utóbbit pedig vakvágánynak tekintik a szakértők.
Van ugye ez a félsz, hogy RAID-5 újraépítéskor jön egy URE.
Nos, RAID-1 esetén a megmaradt lemez újratükrözésekor ugyan úgy jöhet...
Esetleg annyi, hogy 3 lemezes RAID-5 esetén kétszer akkora eséllyel jön, mert 3-ból 2 marad, amit olvasni kell, nem csak 1, és minden esetben lemezenként x%, hogy lesz-e valami probléma, vagy sem.Szóval... Ha bedöglik egy akár RAID-1, akár RAID-5 kötet, neki lehet állni backup-olni, és mindkettőnél, a paritását vesztett RAID-5 kötetnél, és tükrét elhagyott lemeznél is lehet URE. Mindkét esetben többször is neki lehet futni, hátha véletlenül mégis sikerült kiolvasni azt a szektort, mindkét esetben csak az a file lesz hibás, ami az adott területen volt, és így tovább... Ha pedig már van backup, majdnem mindegy, hogy magát tudja újraépíteni, vagy leáll, törölni kell a kötetet és újra létrehozni, majd visszaállítani a mentést (csak kevésbé kényelmes, és közben kiesik a munkából).
Szerintem így a RAID-6 sokkal biztonságosabb, mint az egyszer tükrözött RAID-1. Illetve a RAID-5 sem értelmetlen, hanem még mindig sokkal biztonságosabb, mint egy lemez, mert nem mindegy, hogy egy file lesz oda, vagy egy egész kötet tartalma.
-
válasz
Gregman
#8949
üzenetére
Más (köztük én is) pedig úgy vélekedik, hogy legjobb egymást követő sorozatszámú HDD-ket pakolni egy RAID tömbbe.
Az egyiknél az az elv, hogy ha selejtes az egész széria, akkor veszélyes, hogy egyszerre halhat meg a kelleténél több lemez is, mielőtt lementenéd a fontos adatokat és/vagy újraépítenéd a tömböt a kiesett HDD cseréje után.
A másiknál az, hogy lehetőség szerint egyformán viselkedjen minden lemez (a modellnév mögött tényleg ugyan attól a beszállítótól származó, azonos revíziós alkatrészekből, ugyan azon a gyártósoron összerakott termék bújjon meg, mindegyiken azonos a firmware-el, stb, ne két, csak gyakorlatilag, de mégsem teljesen azonos, hanem picit más HDD-k).
De az is igaz, hogy ha meghal egy lemezed, és nem teszel már most félre egy cseredarabot egy rendelésből (ami baromira nem gazdaságos, hisz sokkal több értelme lenne már akkor berakni azt is a tömbben, vagy még nagyobb redundancia, tárhely, teljesítmény eléréséhez, kinek mi a prioritása), akkor úgyis ugrik az egymást követő sorozatszámok mókája.
Szerintem egyszerűen ne foglalkozz vele. Rendeld meg egyben, hogy olcsóbb legyen a szállítás, és onnan, ahol a legolcsóbban adják.
-
válasz
HUfantom
#8942
üzenetére
Ami eszembe jut ellene, hogy alapvetően nem nagyon lehet róla bootolni, bár manapság már úgy is SSD-re érdemes pakolni a rendszert. Illetve, hogy a Microsoft nem hogy nem fejlesztette tovább, de ki is vette a Windows-ból a paritásos RAID szinteket. De a Linux-nál pl. nemrég is csiszolták a sebességet ezen a téren (kernel szinten).
De amúgy teljesen igazad van. Manapság és főleg otthon már egyszerűbb és hatékonyabb a szoftveres RAID. Igazából régen is csak a paritást használó szintekkel volt a gond, de a mai világban már ez sem igaz, mikor a PC-ink CPU-ja felhízott >=4 magosra és (legalább is megfelelően kihasználva az utasításkészleteiket) magonként is jelentőset gyorsult, miközben a HDD-s alig (sőt, már divat az 5400RPM a hang és fogyasztás miatt, amit csak részben kompenzált a nagyobb sűrűségű korong), így megfelelően beállítva, és csak néhány lemez esetén gyakorlatilag a szoftveres RAID-5 vagy RAID-6 is hozza azt az írási sebességet, amit egy hardware-es.
Ezzel szemben a hardware RAID otthonra, csak néhány lemezhez nagyon távol áll a gazdaságostól. Ugyanakkora kapacitásra otthon olcsóbb a RAID 1+0, mint a RAID-6 + saját RAM-os kártya (és az is csak addig fog virítani a tesztekben, míg be nem telik a buffer).
[ Szerkesztve ]
-
válasz
radi8tor
#8933
üzenetére
Megnézem, bár ez itt most csak az elméleti kérdés.
A gyakorlati, hogy miért nem találom most azt az opciót az IRST vezérlőpultban, hogy RAID-0-ra konvertálom a degradált RAID-5 kötetet.
Szinte abszolút biztos vagyok benne, hogy lehetett ilyet régebben, mert úgy rémlik egyszer véletlenül csináltam ilyet: Elfelejtettem visszadugni a SATA adat vagy tápkábelt az egyik winyóra, és mikor ezt pótoltam, akkor azt hittem, hogy amire kattintok (talán "reset to normal" vagy hasonló opció) az újraépíti majd a tömböt, de helyette 0-t konvertált az 5-ből, a harmadik lemez pedig ott maradt szólóban, és aztán kézileg konvertáltam át 0-ból 5-be, miután végzet a degradált5->0 konverzióval. De lehet, hogy rosszul emlékszem, vagy hogy okkal vették ki azóta ezt az opciót az IRST-ből. -
Igen, azt tudom, hogy még egy hibát már nem bír el.
De íráskor lassabb, nem olvasáskor, és nem tudom ilyenkor mi az extra művelet, ami eddig ne lett volna. Hacsak nem fut a háttérben némi olvasgatás is, ami viszont, ha nagyon lassú, akkor esetleg nem hagy szabad időkeretet az írásra. De azt sem tudom miért lenne lassabb az olvasás, mint 3 lemezzel az írás (akkor oda, most visszafelé megy a paritásszámítás). -
3 lemezes RAID-5 kötetből kihullott 1 lemez (azóta kínzom tesztekkel, és gyűlik-gyűlik az áthelyezett szektor, de még nem csődölt be végleg, hogy vigyem gariztatni). Normális, hogy most tetű lassú az írás (önmagához képest, mikor még 3 lemez volt)? Csak mert nem értem, hogy mivel van így több dolga, mint mikor megvolt mind a 3 lemez.
Illetve Intel fake-RAID esetén lehetne most valahogy RAID-0 kötetté konvertálni, hogy ne legyen ilyen, míg rendeződik a harmadik lemez sorsa? (A fontosabb dolgokat most átmásoltam máshová is, és lehet, hogy inkább le kéne már cserélnem minden HDD-t, amúgy is akartam majd bővíteni a tárhelyet, de még nem napokon , max heteken belül.)
-
Ezért érdemes úgy belőni a stripe size-t, hogy páros számmal szorozva adja az allocation unit size-t, vagy esetleg egyezzen vele (de ne legyen 1-től kisebb a szorzó).
A Windows ugye szigorúan csak 4k-s NTFS-re települ, de ettől kisebbet a RAID vezérlők se szoktak engedni RAID-0 módban, így ott jobb híján egyezzen, adattárolás (nagy, több megás fileok) esetén pedig a 2 (lemez) x 32k (stripe ) = 64k (allocation unit) lehet nyerő (esetleg 4 x 16k = 64k vagy talán 2 x 16k = 32k, ha túlnyomórészt nem néhány sok gigás, hanem sok-sok pár megás file lenne rajta).
-
válasz
hackeeeee
#8603
üzenetére
Attól függ mire kell jónak lennie.
Teljesítmény szempontjából jó (előolvas a HDD-ről a cache-be, mikor nincs jobb dolga, és oda ír először, nem a lemezre, csak ha az már ráér írni), váratlan áramkimaradások alatt veszélyesebb (gépházon belüli kábelhiba ellen a szünetmentes táp sem véd, csak ha a RAID kártya is szünetmentes áramforrású).RAID-0 esetén nincs akkora jelentősége a kötet szintű gyorsítótárnak, mint RAID-5 esetén. Már ha jól választottál stripe és allocation unit méreteket, illetve páros számú lemezeket használsz.
-
Lehet, hogy a benchmarkok sem igazán hitelesek. Ezeket ma lőttem ->
SSD-ről RAID5-re (látszik mennyi fért a cache-be
![;]](//cdn.rios.hu/dl/s/v1.gif)
):
RAID5-ről SSD-re (Samu 840 Pro, úgyhogy mindig bír írni minimum 300Mb/s-el):
Érdekes, hogy egy valódi file másolása Windows filekezelővel mindkét irányba lényegesen gyorsabbnak tűnik, mint a szintetikus szekvenciális tesztek eredményei. Ez már szép olvasás, a tömb lassabbik WD lemeze 135-75 (szélső-belső), és most kb. 3/4 részig foglalt a tárhely.
-
Neked az olvasások vannak a helyükön. Kicsit még gyorsabb is a 3 lemezes, mint a 2 lemezes olvasás, ami tükrözi az elméletet, hogy a 3 lemezes RAID-5 a 2 és 3 lemezes RAID-0 közé eshet olvasásban, ha átugorja a paritás blokkokat.
De nálam most valamiért az olvasás is lassú, és ez szerintem a lemezek, nem az Intel pseudo-software RAID bűne (vagy csak részben, hogy nem tudja jobban megkerülni a lemezek galibáját: jelen esetben az egyik winyó véletlenszerű lassulgatásait, ami talán még gyakoribb olyan lemezelérések alatt, amit a RAID-5 generál).
De az is lehet, hogy a RE4 direkt fel van készítve arra, hogy szekvenciális olvasáshoz hasonlóan kezelje azt, ha lényegében azt is csinálja, csak minden x-edik stripe-ot át kell ugrania, amitől a WD Blue és/vagy Samu F3 olvasási sebessége jelentősen visszaesik, és inkább random olvasáshoz kezd hasonlítani a tevékenységük.
Én inkább előbbire tippelek. Szerintem ezzel a sok tesztelgetéssel most exponenciálisan meggyorsítottam a haldokló Samu winyó állagromlását (30+ órán át nyúztam felület tesztekkel, majd megint 30+ óra míg RAID5-re migrált RAID0-ról, közben már kétszer végig hasholtam az adatokat, hogy megvannak-e még.. máskor akár egy hónap alatt se dolgozott ennyit...).
[ Szerkesztve ]
-
Nálam is érdekesek most az eredmények, de másként.
RAID-5, 32k stripe, 64k allocation unit, write-back cache, kikapcsolt cache flush
3 darab 500Gb/tányér 7200RPM winyó, amiből az egyik kicsit lassabb de szinte új WD Blue, és két öregebb Samsung F3, amikből az egyik rosszalkodik (egyedül tesztelve is fura: bal-alsó).
Ha csak a számok abszolút értékét nézzük, akkor elszomorító, mert kb. egy lemez sebességét produkálja nem csak írásban, de olvasásban is. Ugyanakkor, ha csak azt nézzük, hogy gyakorlatilag ugyan olyan gyorsan ír, mint olvas, akkor ebből a szempontból tapsolhatunk (csak ezt véve alapul úgy tűnhet kvázi ingyen van íráskor is a paritás).
A második tény biztató, hogy ki kéne próbálni három egyforma és egészséges lemezzel is (netán kifejezetten olyanokkal, amiket RAID tömbbe pakoláshoz is szán a gyártó, pl. ha nem is WD RE4, de legalább Red). Illetve még így is megelőztelek írási sebességben, ami szerintem a beállítások fontosságát hangsúlyozza.
Vagy ha igazán a végére akarnék járni, akkor még gyors SSD-ket (pl. Samsung 840 Pro) is érdemes lenne megnézni. HDD-s tömbhöz képest ugyan nem igazán lenne mérvadó (a HDD-k fejmozgatási ideje miatt), de az látszódna, hogy mit hoz ki a lemezenként ~500Mb/s írási sebességekből: visszafogja-e a host-CPU-s paritásszámítás, és ha igen, akkor még a mai 1Tb/tányér HDD-k max szekvenciális sebessége felett, vagy alatt.
[ Szerkesztve ]
-
Aha. Az még mindig több, mint a semmi. Mondjuk itt Intel-nél is el lehet indítani kézileg egy ellenőrzést, ami RAID-0 esetén alacsony prioritással futott, RAID-5 alatt pedig még nem próbáltam, mert tegnap éjjel kezdtem migráltatni (közben a stripe size is vált 64k-ról 32k-ra), és most jár 44%-nál, szóval kb. holnap éjjelre fog végezni.
Kíváncsi vagyok, hogy használható lesz-e az írási sebesség, ha lezárult a folyamat.Annyi biztos, hogy így már zavaró lett a hangerő, hogy a WD Blue is folyamatosan forog a két Samu F3 mellett (máskor a WD vagy le is volt húzva, vagy 1 perc üresjárat után, szóval szinte mindig leállította a Windows).
-
válasz
janos666
#8595
üzenetére
A wikipedia szerint nem:
The parity blocks are not read on data reads, since this would add unnecessary overhead and would diminish performance. The parity blocks are read, however, when a read of blocks in the stripe fails due to failure of any one of the disks, and the parity block in the stripe are used to reconstruct the errant sector
Kár, ezt szerintem opcionális felhasználói paraméterrel kéne szabályozni: lehetne egy "performance" és egy "safety" üzemmód, pl. az IRST-ben kapcsolgatható ahogy a különböző szintű cache-elések és energiagazdálkodási paraméterek. -
válasz
janos666
#8594
üzenetére
Na, sikerült újra előkotorni, szóval szoftveres RAID-5 esetén:
Szigorúan kerüljük a páros számú lemezeket, tehát 3 vagy 5, nem 4 vagy 6 lemez
NTFS cluster size szigorúan 64kb (több nem lehet, kevesebbel túl kicsi lenne* úgy, hogy:
Stripe size = cluster size / [lemezek száma mínusz egy], pl 64/(3-1)=32, nem 64 vagy 128!
Windows eszközkezelőben cache engedélyezve, cache flush tiltva
IRST féle write-back cache egyéni tesztelés és döntés alapján, de valószínűleg bekapcsolva*Esetleg lehetne 32 a cluster size, de akkor csak 16 a stripe, pedig a mai winyókhoz 64 is előbb passzolna, mint 16 (de 128-as cluster már amúgy is túl pazarló lenne, ha vannak Mb-os nagyságú filejaink is nagy tárterületen, szóval a 3 lemez 64 és 32k-val tűnik optimálisnak).
Lehet, hogy ki is próbálom, mert olcsóbbnak és kényelmesebbnek tűnik RAID-5 kötetté konvertálni a RAID-0 kötetet és a backup winyót, mint lecserélni a kikopó félben lévő RAID-0 alatti winyókat, vagy folyton figyelni, hogy mindenből legyen friss backup a tömbről.
Ennek eldöntésére még egy dolgot kéne tudom: Az Intel féle szoftveres RAID-5 vajon olvasás közben is ellenőrzi a paritás alapján, hogy esetleg meghibásodott-e az adat valamelyik lemezen, és szól, ha igen (kiszúrja, ha előfordul egy javíthatatlan szektorhiba az egyik winyón), illetve neki lehet állni végignyúzni és korrigálni a hibát (ha a winyó még át tudta helyezni azt az LBA szektort a tartalék területre) vagy ezt elspórolja a jobb olvasási teljesítmény érdekében, és csak akkor van hibajelzés, ha egy lemez tejesen használhatatlanságig bedöglik (viszont addigra talán már hibásak az adataim a véletlen szektorhibák miatt)?
Mert ha a RAID-5 bebiztosítana a javíthatatlan írási hibák ellen is, akkor használnám így a winyóimat, míg végleg be nem döglik az egyik (vagy a praktikus használhatóság határáig lassul - a SMART adatok alapján nagyon nehezemre esik megjósolni a sorsát). Még mindig túl post-cinami-snak érzem a winyó piacot ahhoz, hogy most vásároljak be.
-
Pedig egyszer gondolkoztam már RAID-5-ön és mikor utánaolvastam, akkor annyi kiderült, hogy ott nagyon fontos a Windows féle cache flushing tiltása és a write-back cache engedélyezése (hogy legyen átfutási ideje a szoftveres paritásszámításnak), illetve még az is, hogy át legyen gondolva a cluster és stripe size méretek aránya (annak megfelelően, hogy hány lemezes a tömb).
Kár, hogy nem tudok kölcsönkérni 3 egyforma winchestert és letesztelni.
Ha valahol a szóló lemez és a két lemezes RAID-0 közt (de nem előbbi alatt) lenne a 3 lemezes RAID-5 kötet írási teljesítménye, akkor szerintem belevágnék, mert kezdenek elöregedni a régi winyóim, az újakról pedig csak rosszat hallani (jó ha a garidő végét megélik, és nagyobb a mechanikai totálkár esély, mint a fokozatos elhasználódásé a figyelmeztető felpörgési hibákkal és/vagy gyarapodó írási/szektorhibákkal). -
Kösz az infót.
Az eredmény pedig sajnálatos.
Pedig szerintem csak akart (szoftver) kérdése, mert 5-6 éve is volt már olyan RAID kártya, amin a CPU teljesítmény a közelébe sem ér a te CPU-d egy magjához, mégis elkezelt sok lemezes RAID-5 tömböket, a HDD-k pedig nem lettek nagyságrendekkel gyorsabbak.Próbáltad kisebb és nagyobb stripe size-al és hozzá passzoló allocation unit size-al, illetve ki és bekapcsolt write back cache-el?
Ma ezzel szórakoztam két 1Tb-os (2 tányéros) winyón, és a 64k-s stripe size nyert. Az allocation unit gyakorlatilag mindegy volt (a 4k is ugyan olyan, mint a 64k), a write-back cache viszont minden esetben lassított, kivéve a 128k-s stripe size + 4k alloc unit párost, de ott cache-vel együtt is lassabb volt, mint 64k-s stripe-al cache nélkül.
A szélsőségek (4k stripe +cache és 64k cache nélkül) közt akár ilyen ~60%-os különbségekről beszélek...
(Cache nélkül: a hardware-es cache nyilván ment, különben drasztikusan esett volna a teljesítmény, ez a kötet szintű szoftveres cache a fura, ami egy hardware cache-t emulál szoftverből a kötetnek...)[ Szerkesztve ]
-
Tesztelgette valaki mostanában, hogy a szoftveres Intel RAID (friss 12.6-os BIOS ROM-om van) 5-ös módban mennyivel lassabb, mint 0-ásban (ugyan olyan lemezekből 3-al 2 helyett)?
A mai fürge CPU-kkal ma már elvileg nem lehetne különbség egy saját procis RAID kártyához képest, a lemezek tekintetében pedig a paritás bit az extra harmadik lemezre megy, de a gyakorlatban bármi elképzelhető...
[ Szerkesztve ]
-
Nekem 60Gb-os SSD-n van a Windows 7. Így sokkal jobban hasít, mint mikor két HDD-s RAID0-on volt. És ennyin szerintem el lehet férni a rendszerrel.
Egy fullos Win7 (Ultimate, ami igazából felesleges is) és egy AutoCAD Civil3D 2012 (szintén full install, pedig sok modult nem használok) van rajta, ami számottevő. Aztán ilyen kisebb dolgok, hogy MathCAD, PhotoShop (szintén full install), plusz még persze az a nagy kazal vacak, amit a hangkártya, multifunkciós nyomtató-scanner, okostelefonok, VGA kártya és egyebek mellé települ (amikből lehetne szelektálni, mert nem használok minden ilyen kisalkalmazást, de lusta vagyok, mert elfér).
És még így is van perpill majdnem 14Gb szabad helyem (mondjuk 8Gb RAM mellé most nincs is lapozófile, de beleférne pár giga - bár ha kéne, inkább rendes RAM-ot vennék, az még mindig gyorsabb és most olcsó is...).Játékot mondjuk nyilván nem telepítek ide, de egyszerre egy még el is férhetne, ha lenne értelme (főleg, ha takarékosan bánnék a hellyel).
És ha több helyet szeretnék, akkor összedobhatnék magamnak egy egyedi Win7 telepítő CD-t, amiből kivághatnék egy kazalnyi felesleges cuccot, illetve kiválogathatnám minden software telepítésekor, hogy mely funkciókra lesz szükségem. Ezzel szerintem simán kapnék még 10Gb-ot, ha nem többet.[ Szerkesztve ]
-
Nem igazán látom, hogy (főleg egy software raid esetén) miért lenne zavaró az, hogy mi van a lemez olyan területein, ahol épp nem zajlik írás/olvasás.
A lemezeken ugyan úgy csak 1-esek és 0-ák vannak, a SATA vezérlőnek is mindegy, mert ő is csak ennyit lát belőle, a Windows drivernek pedig épp csak annyit kell tudnia, hogy honnan kell olvasni a lemezről, mikor valamelyik tömbről kérsz adatot, ami nem tánik bonyolultabbnak, mint mikor azt találja ki, hogy melyik partíció hol van egy sima HDD-n.Abban látnám a problémát, hogy fizikailag ide-oda kell ugrálnia a HDD fejeknek, ha egyszerre van írás/olvasás a lemez különböző területein, ami súlyosabb gond lehet, ha mindennel meg kell várni mind a két lemezt a mirror vagy stripe mód miatt.
[ Szerkesztve ]
-
Az SSD sokkal jobb rendszernek, mint HDD-s RAID0.
Viszont nem biztos, hogy rossz a kettő egymás mellett.
A RAID-1 részen vélhetően inkább csak fontos adatokat tárolnál, amiket inkább tárolsz, mint rendszeresen írsz vagy olvasol (legalább is nagy adatforgalommal, folyamatosan jelentős terhelést okozva), míg a RAID-0 rész inkább a sebesség miatt lenne nem kritikus adatoknak, amit így nem annyira zavar a kvázi passzív RAID-1 jelenléte.
-
válasz
janos666
#7526
üzenetére
Nem volt kedvem scanelni, így megpróbáltam egyszer rebootolni és elölről kezdeni. Most scanelés nélkül is meglett a partíció és jónak tűnik.
Akkor most 2x4 óra oda-vissza mozgatás és rendben lesz. -> Remélem most már huzamosabb időre.
Nem tudnám esetleg lementeni az első x szektort valamivel FreeDOS alól bootolva és ilyenkor visszaállítani, ha kitalálja, hogy nem többé már nem tömb a tömb?
Milyen programmal és mely szektorok kellenének?Minden esetre ha belefér, akkor csinálok HD Sentinellel egy írás tesztet a két winyón a másolások közt, mert most kipróbáltam és az új, átmeneti RAID0 tömböm (amire most megy a software-es adatvisszanyerés) nem esett szét attól, hogy bebootoltam egyszer Windows-ba IDE módba rakott vezérlővel.
Ami eddig mindkét szétesésnél megvolt: ugyan az a Z68-as alaplap, CMOS clear, Windows boot IDE módban lévő vezérlővel.
Bár az is igaz, hogy most legutóbb ki-be nyomkodtam a táp főkapcsolót is, mert nem akart elindulni a vízpumpám, de a CPU-t sem szerettem volna megsütni...
[ Szerkesztve ]
-
Lehet, hogy most valami másról van szó.
Mikor legutóbb széthullott a tömb, akkor szétszedtem, betallóztam R-Strudioban és ott rögtön lehetett olvasni a filerendszert, mindenféle scanelgetés nélkül.
Ilyen opció most nincs, nem talál értelmes filrendszert és scanelés közben teledobálja a logot azzal, hogy:
Warning File System 2012.05.29. 13:35:40 Unexpected MFT record 320 at 3356753920. If you are scanning RAID and this message will reappear constantly, check RAID for consistence.Vagyis most talán nem egyszerűen csak arról van szó, hogy egyik bootolásról a másikra kitalálta a vezérlő, hogy ez már nem lesz többé RAID0 tömb, hanem valami gebasz lehet már az adatokban is.
Most leállítottam pár perc után a scan-t, megnyitottam az eddig talált egyetlen értelmes partíciót és kicsit fura, mert olyan mappákat is töröltként lát, amik sohasem voltak törölve.
Így most futtathatom végig a scanelést, aztán agyalhatok, hogy mégis mit és miképp állítsak vissza, nem egyszerű ömlesztett ide-oda másolgatás lesz.
Annyi különbség mondjuk volt, hogy legutóbb a post screen alatt előhívható menüben szedtem szét a tömböt, most pedig Windows alól töröltem. Lehet, hogy másképp szedte szét, és most direkt törölte fizikailag az első szektort...?
-
De valami történik, mert ha IDE módban bootol a Win, akkor megjelenik az egyik lemez, mint rendes szingli lemez, a másik mint nem inicializált lemez dupla mérettel és innentől kezdve reboot és RAID mód bekapcs után már a BIOS post alatt is FAIL és ugyan az a helyzet Windows-ban.
Esetleg a Windows-os driver nyúlna bele?
De a lemezre is ír valami, mert újabb CMOS clear és rögtön bekapcsolt RAID mód is ilyen ettől kezdve, FAIL.[ Szerkesztve ]
-
Na jó, én ezt már nem hiszem el!
Pár hete elszállt az Intel RAID-0 tömb egy alaplapi firmware frissítés után.
Most úgy tűnik kiderült, hogy nem a firmware csere okozta a gondot, hanem az, hogy bebootolt a Windows 7 x64 SP1 úgy, hogy a frissítés resetelte az UEFI setup-ot és így nem volt RAID módban a vezérlő.Ugyanis ma ismét megtörtént!
Most nem volt semmi frissítés, más miatt reseteltem és megint volt egy-két Windows boot is közben. (Szerelgettem a gépet és nyomtam egy CMOS clear-t, mikor nem akart postolni, de csak én nem dugtam be rendesen a CPU tápkábelét.)
Most is megjelent egy formázatlan lemez a kettő közül az intézőben, és miután visszaállítottam az elmentett beállításaimat az UEFI setupban, utána azt mondta postoláskor a RAID BIOS, hogy FAIL.
Valahogy nagyon nincs kedvem megint előkaparni két másik winyót és órákon át ide-oda másolgatni R-Studio-val.
Tényleg nincs valami megoldás erre, hogy visszaálljon? Mert ez így már gáz, hogy mozgatni kell, pedig igazából semmi baja, talán csak az egyik winyó bootszektorát verte ki.
Nem értem miért baszódik szét a tömb, ha bootol egyet a Windows úgy, hogy szét van szedve. Miért áll neki kérés nélkül írni a lemezre?
[ Szerkesztve ]
-
Na, az R-Studio progival mindenféle scanelés nélkül megnyitotta a partíciót a két lemezről.
Kapásból felismerte a 64k-s stipe size-t, kisakkozta hogy melyik a #1 és #2, és már ott is volt a tallózható partíció, ami első ránézésre rendben van.
Mindjárt ki is hámozom a winyót a DVR-ből és elkezdek mentegetőzni.
Persze sokkal szebb lenne, ha most egyszerűen csak el lehetne menteni a felismert konfigurációt a lemezre és a következő bootoláskor az Intel vezérlő is ismét így látná RAID tömbként. De nem hiszem, hogy erre létezik megoldás.
-
Most ZAR-al estem neki.
Ez ránézésre képes fizikai lemezként kezelni az eszközöket és azt ígéri filokat is tudok majd menteni.Viszont már a quick prescan sem olyan gyors és így 60% körül még a kis data fragments térképe sem túl biztató.
Lehet mindjárt ránézek az említett progikra, ha lefutott a quick és semmi.
(Á, agyoneszi a CPU-t, vissza kellett volna állítani a CPU órajelet az alaplap reset után és ez előtt.)Image-eket tuti nem fogok lementegetőzni, pillanatnyilag csak egy darab 1Tb-s winyót tudok kibányászni egy DVR-ből (elég is lenne lementeni, ami kell, sok kacat is volt a tömbön amit csak lusta voltam törölni míg nem kell a hely), már egy második 1Tb-ért is messzire kéne menni, több pedig nem lesz.
-
-
Valami nem stimmel.
Átraktam IDE módba a SATA vezérlőt. A Windows most eszköz szinten már csak lemezeket lát (egy SSD, 2x1Tb HHD), de a lemezkezelő még mindig lát egy 2Tb-os array-t (lemezként) és mellette csak a kötetből kiesett 1Tb-os lemezt.
És a recovery progi is hasonlóan téved el, amit most próbáltam (DiskInternal RAID Recovery - egyelőre trial verzió, de scannelni tudna, csak épp ugyan úgy hülyén ismeri fel a köteteket, mint a Windows). -
válasz
HUfantom
#7389
üzenetére
Az alaplapi Intel vezérlővel raktam össze Windows alól. Ez ilyen "fake-raid", lehet róla bootolni is, de igazából software-es.
A bekapcsolás utáni post screen közben a RAID Option ROM is postol és az is kötetnek látta eddig, de most kötet FAILED és hosszan vár, hogy be szeretnék-e lépni a konfigba.
Beléptem már egyszer, de nem találtam ott semmi használhatót. (Itt lehet létrehozni vagy törölni köteteket, vagy újraépíteni a RAID5-öt, de erre semmit nem láttam.)Próbáljam IDE módban valami software-el lementeni a legfontosabbakat, aztán hagyjam megdögleni a tömböt?
Vagy software-el nem lehet file szinten, csak kötet szinten kimenteni adatokat? (Ahhoz kéne 2x1Tb winyó...)Gondolom akkor lett bibis a kiesett lemez, mikor a Windows megpróbálta inicializálni. (Miután visszajöttem és próbáltam tallózni a D: meghajtót, akkor akkor nem a tömbön lévő partíció volt, hanem csak egy szál lemez...)
[ Szerkesztve ]
-
Van egy "kis" problémám:
Alaplapi UEFI-t frissítettem és közben el is hagytam a szobát (ordibáltak a szomszédból, hogy kellenék). Mire visszajöttem, már be is volt bootolva a Windows.
Nyitottam volna az intézőből a meghajtómat, ami a tömbön volt (két lemez, egy tömb, egy partíció), erre kiírta a Windows, hogy előbb illene megformázni a lemezt
Jó, ekkor még semmi pánik, felismertem a problémát, hogy vélhetően konfogit resetelt az alaplap és RAID helyett IDE módban van a vezérlő.
Reboot, IDE módból RIAD-ba raktam, majd elképedtem, hogy a post screen alatt is kiírja a tömbre, hogy FAIL.Postoláskor kilistázza mindhárom lemezem: egy SSD és két egyforma HDD, a kötet még mindig megvan, de csak az egyik HDD jelenik meg úgy, mint member disc, a másik non-member disc.
A Windows-os program nem tud ellenőrzést csinálni a tömbön, mert azt mondja hiányzik az egyik lemez (ami ott látható üres lemezként).
Ilyenkor mit lehet még csinálni?
-
válasz
El Kebir
#7056
üzenetére
Én eddig ICH9-től Z68-ig mindig azt láttam, hogy a write back cache rontja a RAID-0 teljesítményt. Erre jutottak pl. itt is, igaz azt is mondják hogy RAID-5 esetében sokat segít (itt pedig nem tudom te melyikre értetted, mert 0-val említed egy mondatban de 5-ről is írsz).
-
válasz
djculture
#7044
üzenetére
Ez a progi nézi kis és nagy "fileok"-ra is és mind fura.
De mindjárt nézem nagyobb stripe-al. De nem véletlen volt ez 4k, tesztelgettem valamikor régen. (Igaz másik lappal, másik, kisebb winyókkal).Most a writeback cache-t kapcsolgatom, és lényegsen gyorsabb lett az új tömbön az írás és olvasás is ha kikapcsoltam. Bár fura, hogy most már itt is az írás a gyorsabb, mint az olvasás, de haladás.
A régi még így is lomha, de lehet hogy azért is, mert tele van adattal, így töredezhet a file, amit a tesztprogi csinál.
[ Szerkesztve ]
-
válasz
djculture
#7041
üzenetére
Rajta van a képen, 4k.
Most én is erre gyanakszom. De mint mondtam, régen ez bevált a 4k-s allocation unit-al. És míg rendszerpartíció is volt a tömbön, a unit size amúgy sem mehetett fentebb, úgy meg kár a stripe-ért is.
Most hogy SSD-n a Windows, így végül is mehet fentebb amúgy is. -
válasz
radi8tor
#7040
üzenetére
Ezen adatok nagy része olyan, amiért nem kár (hadd ne valljam be milyen ~30-40Gb-os fileokkal van tele a nagyja
), a fontos dolgokról van másolat a laptop winyóján.És kopogjuk le, de sohasem szállt még el végleg RAID-0 tömböm (egyszer egy túlképzelt CPU tuningot követő kékhalál után ki kellett szedni az adatokat kölcsön winyókra egy software-el, de ott sem veszett el semmi, csak kellemetlen volt.) Ok nélkül még sohasem gondolta így. (Amúgy direkt egymást követő sorozatszámú winyók a Samuk, a kölcsön WD-k most random, egyik már 1400-szor ki/be kapcsolt, a másik csak 100-szor, DVR-ekben voltak.)
Most összefűztem a két WD winyót. Hasonló a helyzet, csak fordítva az írás/olvasás:
Itt az írás lett lasabb, mint egy lemezen, de az olvasás is alig gyorsabb a RAID-0 tömbön, mint egy lemezen volt.Lehet, hogy kicsi a stripe size ekkora mérethez?
Valamikor régen tesztelgettem a stripe size beállításokkal még kisebb winyók idején, és úgy döntöttem jó nekem a legkisebb 4k, és 4k-s allocation unit. De lehet ekkora méretnél má bugzik ettől az Intel vezérlő...? -
Van egy kis gond a RAID-0 tömbömmel.
Nem tudom pontosan mióta, és azt hittem a régi alaplapomban a béta BIOS miatt zavaros, de most új alaplappal (X48 után Z68 chipset) is ez van:
Screenshot
A képen az első teszt a kétlemezes RAID-0 tömb, a második egy nem pont azonos, de hasonló szóló winchester (szintén két tányéros 1Tb-os, csak nem Samu hanem WD), a harmadik egy SSD.
Illetve ott a HDSentinel, hogy szerinte 100-as minden.
A Win7-et is most húztam újra alaplapcsere miatt...Mivel a SATA3-as SSD száguld, és az egyszál lemezzel sincs gond, így nem értem mi baja van a RAID-0 tömbnek. De elég gáz már az is, hogy alig gyorsabb az írás a tömbön, mint a szóló winyón, na de hogy az olvasás annyivel lassabb az íráshoz képest és a szóló winyóhoz képest is... na az már jujjj...
Most azt tervezem, hogy a kölcsönkért és berakott WD winyókból is csinálok tömböt, megnézem azt is tesztprogival, aztán átmásolok arra a tömbre mindent a Samu-sról, szétszedem a tömböt és megnézem a Samu wnyókat is egyesével.
Ötlet, javaslat?
-
válasz
Jester01
#4629
üzenetére
Egy lemezes tükörkészlet? Frankó.
Nekem az ICH9R vezérlővel RAID0 tömb mellett is látta a Win7 a külön winyókat. Ha akartam csináltam belőlük tömböt a storage managerben, akkor előbukkant a tömb, ha akartam ismét szétszedtem, és előbukkant a két külön lemez.[ Szerkesztve ]
-
válasz
gardener
#4613
üzenetére
Nem, mert folyamatosan telíti a meglévőket adatokkal, ugyan úgy szükség lenne egy átmeneti tárolóra, amire kiteszi, mielőtt újra felosztja, mint ha te üríted ki, kreálod meg az újat, majd töltöd fel újra.
RAID1-hez lehet, mert akkor egyszerűen csak átmásolja az adatokat a tömbről a winyóra, és kész, olyan mint egy backup készítés.
RAID5-höz is hozzá lehet talán fűzni még plusz winyót, bár ott is necces, hogy ha több winyóból áll a tömb, akkor nő-e a paritásinformációk helyigénye, illetve újra kéne-e generálni az egészet, vagy ezt meg tudja-e oldani házon belül. Szerintem itt is ugyan az a szituáció, és kéne neki egy másik tárhely, ahova áthelyez mindent, majd vissza, szóval ugyan az, mint ha te mented le, és rakod vissza.[ Szerkesztve ]
-
Jut eszembe. Vettem ma 2db 1Tb-os Samsung F3 winyót (32Mb cache, 2-2db 500-as tányérral), mindenképp RAID0-ban akarom használni, csak még a stripesize-allocation unit size pároson töröm a fejem. Leírom mit elmélkedek, hátha valaki talál benne hibát, vagy épp ötletet merít...
Egyrészt folyton visszatérő kérdés nálam, hogy jön ki jól: ha azonos a két érték, vagy ha az allocation unit size az épp a stripesize duplája.
Nem tudom pontosan hogy működik a stripe ilyen szempontból. Ha 4k-s a stripe, akkor ugye minden winyóra 4k-s lépésekben lehet írni, így mindent 4k-nként szaggat szét a vezérlő. Ehhez elvileg az az ideális, ha az allocation unit size épp a winyók száma * stripesize, és akkor például a filerendszer 8k-s csomagjait elvágja 4-4k-ra, amit kiír 1-1 winyóra. Sokan mégis arra esküsznek, hogy a két érték legyen azonos, vagy akár legyen kisebb is az allocation unit size, mint a stripesize (akár pl 128k-s stripe, 4k-s allocation unit-okkal, pedig hát akkor elvileg 256k-nyi csomagot meg kéne várnia a vezérlőnek a filerendszer felől, mire ki tudja írni a winyókra a felvágott 128k-s csomagokat)
A kis fileokra való tekintettel, minthogy a windows partíció (és a lapozófile) is ezen a tömbön lesz (és a játékok is erre lesznek telepítve), így minél kisebb stripesizet akarok.
Ezzel nincs is gond addig a kérdésig, hogy egy ~1,9Tb-os partíciót hanyas allocation unit size-al illene formázni NTFS-ben? (és akkor ez, vagy ennek az értéknek a fele lesz a stripesize) Félek, hogy kicsit nagy lesz a filerendszer, ha ezen 4-8k-val szaladok végig (nagyra hízik az MTF, és hasonló nyalánkságok).
Vagy nyugodtan lehet akár 4k-s allocation unittal formázni még 20-30 terrákat is NTFS-re, nem lesz gond az MTF méretével (és ebből adódó fokozott töredezésével)?
Mert akkor mehetne 4k-s stripe, és 8k-s allocation unit size. Kár, hogy az intel vezérlővel nem lehet 2k-t stripeolni, és akkor maradhatna a default 4k-s allocation unit. Főleg ott érdekes ez, hogy a lapozófile az 4k-s csomagokkal operál, így 4k-s allocation unit passzol hozzá. Itt kérdés, hogy akkor megéri-e külön partíciót hagyni neki, amin 4/4k a stripe és alocation unit is. (bár még ez sem tökéletes, a 2/4k lenne az...)Ötlet, vélemény...?
[ Szerkesztve ]
-
#4609
janos666
nagyúr
hugoagagyilo
#4608
válasz
hugoagagyilo
#4608
üzenetére
Ha csak az alaplap halt meg, akkor semmi gond, ha rákötöd egy másik lapra, amin kompatibilis a vezérlő (tehát nem is feltétlenül ugyan olyan alaplapra, csak azonos típusú chipsetre, tehát még ez sem kell, hogy teljesen megegyezzen, intelnél lehet lépkedni, hogy ICH9-ről 10-re váltasz, és rákap, gondolom érvényes ez nfocre-ra is, a lényeg, hogy ne most válts AMD-ről intelre, vagy fordítva...), akkor felismeri tömbnek.
Esetleg ha szétesett a tömb is, akkor ha újra feldobod azonos stripesize-vel, és utána rögtön ráeresztesz egy partition recovery-t, még jó eséllyel lehet belőle valami. -
Talán azért nem volt népszerű kérdés, mert ez nem RAID témakör.
Ez valamiféle backup software-el oldható meg. Szerintem némely külső dobozos winyókhoz csomagol is ilyet a gyártó, gondolom egy kazalnyi közül lehet válogatni a neten is, amik közt netán még ingyeneset, esetleg jól működőt is találsz. (Ami automata, hogy csak kis prioritással másol, nem zavarja a munkád azzal, hogy nyúzza a winyót.)
Amúgy mi olyan fontos a gépen, amit nem elég néha kézileg lementeni? (kiírni -esetleg újraírható- DVD-re, vagy lemásolni asztali gépre? És nem ironikusan értem a kérdést, hanem hogy mekkora adatmennyiségről beszélünk, amik szétszórtan, vagy együtt vannak...?) -
válasz
SzlobiG
#4603
üzenetére
Az önmagára másolás is gyorsabb lesz a tömbön belül is, mint egy winyón belül, csak kevésbé, mint mikor A winyóról/tömbről B winyóra/tömbre másolsz (mert ilyenkor nem kell ida-oda mászkálnia a fejnek hgy innen olvas, amoda ír, csak halad előre mindkettő, de tömb esetén ezen is segíthet a még gyorsítótárazás).
Bocs, elsőre nem direkt neked reagáltam, csak elkaptam azt a gondolatmenetet, amit ő elkezdett, illetve hát a hsz vége elég univerzális, benne van a Raptor+RAID0 is.Ha alapvetően tárolsz, és olvasol, akkor mindenképp jobb a tömb. Akkor jó külön hagyni, ha elsősorban inkább mozgatod az adatokat, pl. muxolgatod az mkv-kat, csomagolod ki a rarokat, stb.
-
Intel vezérlő esetén köteten belüli másolásnál talán jól jön, ha engedélyezed a "kötetszintű visszaírási gyorsítótár"-at.
A többi mondandód pedig teljesen logikátlan.
A Raptor épp rendszerwinyónak való, mivel a windows még a sávszélességnél is jobban szereti az alacsony elérési időket (mikor pár Kb-os filokat töltöget 1000 felől...). Nameg fajlagosan drága rajtuk a tárhely így egy rendszermeghajtónak elegendő méret is elég drága.
Persze a RAID is gyorsít a windows működésén is, de ebben a felállásban inkább a Raptorra tenném a rendszert. Illetve nem is, inkább egy 30/60Gb-os SSD-re, úgy még ütősebb a rendszer, és nem fogja meg, ha a RAID tömbön ütyködsz.Másik: ha RAID0-ról másolsz sima winyóra, akkor ott a tényleges átviteli sebesség épp a lassabb winyó sebességével fog megegyezni, ez is logikátlan. Akkor ha már a RAID-on van a rendszer, akkor az egyszem winyóról kell a RAID-ra másolni, mert így annak a feles kapacitását felélheti a windows...
Szóval szerintem ez a sorrend:
Kis (akár jobb féle MLC-s, olcsóbbacska) SSD-n a rendszer, és mellette RAID0 tömbön az adatok.
Raptoron a rendszer, RAID0 tömbön az adatok, vagy ha kifejezetten az ide-oda mozgatás, és nem a tárolás/olvasás a cél, akkor két külön winyó, amik közt oda-vissza mozgatod az adatot (pl mkv muxolás, tömörítés, stb...)
Költséghatékony esetben csak egy RAID0 tömb, főleg, ha a tárhely mennyisége is számít, ezesetben akár nem is csak 2, hanem 3, akár 4 winyó a többe (vagy ha tényleg sokat mozgatsz ide-oda, akkor 2-2 winyó 1-1 tömbben).[ Szerkesztve ]
-
Annak ugye nincs semmi gyakorlati akadálya, hogy 3db winyót tegyek össze egy RAID-0 (4k) tömbbe? Nincs gond a páratlan számokkal, akár teljesítmény terén?
Azon filózom, hogy veszek pár darab Samsung F3 500Gb-ot, de nem bízom benne, hogy sebesség terén is érdemi növekedést tapasztalok, ha csak 2db F3-ra cserélem a 2db WDC-t.
Főleg, hogy nagyon jól esett, mikor korábban egy SSD-n volt a winows, és a RAID tömbön mozgattam az adatokat. Most gondoltam, ahelyett, hogy megint beruházok egy ~20k-s SSD-be, a tárhelybővítés igénye mellett akkor már gyorsabb féle winyókból több darabot veszek, és a végére talán jobban járok, talán végül még 4db-ot is veszek, majd meglátom holnap.
Illetve, akkor már: Ugye az ICH9R vezérlő még jó hatásfokkal tud együtt kezelni akár 4 winyót is? Nem nő drasztikusan a szétesés veszélye sem?[ Szerkesztve ]
-
válasz
janos666
#4359
üzenetére
Megoldódott. Az Active Partitino Recovery szenvedett vele, és hibaüzenettel kivágott, hogy ismeretlen partíció, csak MBR-t támogat, de mikor bootoltam Win7-be, megjelent a partíció, és olvashatóak a fileok.
Most már nem GDP hanem MBR a partíció típusa a disk manager szerint. (ezek szerint ilymódon konvertálni is lehet GDP-t MBR-be ) -
válasz
janos666
#4358
üzenetére
Az Active Partition Recovery megtalálja az NTFS partíciót, tudok is turkálni a mappákban, minden ott van szépen. Viszont helyreállítani nem tudom, mert hibaüzenettel kivág, hogy csak MBR tipusú meghajtókat támoat. Ez meg ugye GDP meghajtó volt. (Más átkozom a napot, mikor érdekességképp ilyennek csináltam meg a RAID tömböt, de ki gondol ilyenekre, míg nem tanulja meg valahonnan -> a saját kárán).
-
-
Huhh. Ma vízűtést szereltem a gépbe, és sikerült picit megáztatni az alaplapot a hangkártya PCI slotjánál.
Amint észrevettem, hogy csöpög, kirántottam a tápkábelt, kiszárítottam, letöröltem a kormot, és működik is minden, csak épp szétesett a RAID 0 tömböm.
Intel ICH9R vezérlővel van összerakva két winyó, a RAID BIOS most azt írja Status: Failed
Van rá esély, hogy szoftveresen helyrehozzam?(#4356) - Csak úgy, hogy letiltod a RAID vezérlőt, aztán ha nem raid tömbön van a windows, akkor onnan, ha azon, akkor pendriveról bootolva DOS alól (HD Sentinel-ből van ingyenes DOS verzió).
[ Szerkesztve ]
-
Ja, miután lemondtam az adatokról csináltam egy tömböt, feltoltam egy XP-t, szétszedtem a tömböt, az egyik winyót felpartícionáltam, gyorsformáztam, és elindítottam az XP telepítést hogy rámásoljon pár filet, reseteltem a gépet, összeraktam megint tömbbe a két vinyót (ugyanakkora csíkszéllel de más néven) ás az állam leesett, de bootolt az XP, csak néhány dll hiányára panaszkodott amit nem bírt betölteni.
Állítólag az SSD-ket már nem nagyon szolgálja ki RAID0-ban az ICH9R, és a széthullások egyik oka lehet a BIOS is.
Nálam 90% hogy nem a vezérlő adta be a kulcsot hanem az oprendszer szemetelte szét az MTF-et vagy az MBR-t mikor elszált kékhalállal, csak még bootolható maradt és ahogy tovább használtam szarráment az egész a hibás infók alapján írva míglen használhhatatlan lett.[ Szerkesztve ]
-
Sehogysem tudtam semmi értelmeset visszanyerni a felbomlott tömbről. Most érdekességképp kézileg szedtem szét, csináltam egy partíciót és gyorsformáztam az egyik disket, rekreáltam a tömböt új néven, de azonos csíkszéllel, erre gond nélkül bootolt az a windows amit a kézi szakítás előtt telepítettem.
Szóval nem egyszerűen a BIOS hülyesége miatt szakad fel a tömb, úgy hogy semmit se lehet visszanyerni, mert akkor a rekreálás után akár még a windows is bootolhatott volna.
A régi partíciókat nagynehezen megtaláltam Active partition recoveryvel, csak nem lehetett őket visszaállítani (állítólag nem fért fel a lemezre), a getdataback meg nem bírt értelmes fileokat lementeni. (meg se nyíltak vagy hibásak voltak a fényképek, egy mp3-at se lehetett lejátszani amit kivettem, a mappaszerkezet emlékezetett az eredetire de nagyon hiányos volt...)
Meg ha már így jártam csináltam 1-2 rövid tesztet, most 4k-s csíkra, de 8k-as allocation unit formázásra állok majd át. (eddig 4k/4k volt)
(#3758) - Talán az X58 mellé fejlesztenek már rajta valamit.
[ Szerkesztve ]
-
Lehet hogy a RAID széthullás is következmény volt, nem pedig kiváltó ok. Szórakozott mostanában az alaplapom is, használtam béta oprendszert amiben előidéztem vöröshalált (igen, az új windows 7 már vörösen hal meg nem kéken
)
Általában ez mind nem lenne gond. De mikor baj van kiválóan rá lehet verni az ilyesmikre a balhét...
(bár mikor faileddel bootolt volna azelőtt szabályos leállításon esett át a Vista SP1 előző este)[ Szerkesztve ]
-
Najó, kezdek lemondani az adatokról. Ha már így alakult:
- Manapság mi a javasolt csíkméret?
- Szerintetek mi a jobb: a csíkmérettel egyezőre/kissebbre, vagy épp a késtzseresére állítani a formázáskor az allocation unit sizet?Nekem most 4k csík volt 4k allocationnal, de mikor ezt megszültem volt aki 8k-s blokkra voksolt 16k-val formázva, volt aki azt bizonygatta nem szabad a blokkmrettől nagyobbal formázni...
-
Nagyon nem jön össze, az Active@ Partition Recovery program megtalálta a legutolsó nagy partíciót ami nekem kellett volna (az első 35Gb csak rendszer, az veszhet), de nem tudja visszaállítani, szerinte kívülesik a cím a lemezterületen (vagyis a talált adatok alapján), próbálkozzak másik találattal (csak azokból hiányoznak a fileok...)
A testdisk se jött be, az még ennyit se talál.
Még valami tipp hasonló softverre?[ Szerkesztve ]
-
-
Hmm. Visszaraktam a diszkeket ugyanolyan 4k-val csíkozott azonos nevű tömbbe ahogy régen voltak. Windows PE alól futtattam a TestDisk-et, 3x is lefutott a deep test. Egyszer NTFS-t keresett Vista kérdésre igennel, aztán nemmel, de csak egy sosem létezett 30Gb-os partíciót talált amiről nem tudod egy filet se listázni, majd Non particioned módban is keresgéltettem vele, így kaptam egy rakat fals találatot ami közt keresgélve se volt semmi értelmes. (NTFS alig volt, egyiknél se stimmelt a méret).
Most feláldoztam az első partíciót és csináltam egy kis 3Gb-os új partíciót, felhúztam egy XP-t. Most futtatok róla egy Active Partition Recovery nevű programot, egyenlőre csak a logba listáz ez is rakás fals találatot (bár most legalább vannak már méretben stimmelő találatok, szóval biztatóbb). Úgy nézem nem egyszerűen a RAID vezérlő adta be a kulcsot hanem valami nagyobb gáz történt és a raid szakadás csak annak az eredménye, és nem kiváltója volt. (de kár volt beáldozni az első partícióm, most látom ez a program futott volna még DOS-ból is - bár mire GUI nélkül kiválogatom ami nekem kell a 100 fals eredményből...) -
Kösz a tippet hogy kreáljam újra ugyanúgy.Viszont nem sikerül BartPE-vel bootOS-t csinálnom. XP Pro SP2 finetuned CD verzióval próbálom, a legújabb verzió kidob egy csomó hibát, az egyel korábbi viszont hiba nélkül lefut, de azt írja nem található meg az ATIIDE.sys
Tipp CD-ről bootoló OS-re amiből alkothatok valamit? -
Sürgős segítség kéne ICH9R RAID töréshez.
Mostanában csinált hülyeségeket az alaplapom, pl. visszavette 16x-ről 1x-re a PCI-E sávszélt, de ezt az új VGA-nak tudtam be, ma valamiért már az FSB is beált nála fix 267-re (nem is 266-ra, és se fel, se le, megamarad amit kézileg állítok csak nem alkalmazza), erre meg azt hittem a procim unja a magas feszt.
Nade most beütött a szar! Megtört a RAID0 kötetem is. Azt mondja a RAID BIOS bootláskor hogy az faiked, non bootable, az eslő lemez nem része a kötetnek, a második viszont még Memeber Disk. Ha belépek a konfigjába ott csak bontani lehet a kötetet vagy másikat csinálni, nincs javítási opció. Windows ugye nem indul... (Vista, az ismer szoftveres raidot, rákapna ha hamis jelzés lenne)Valami tipp hogy leheljek élelet a megtört kötetbe? (nincs 3. winyóm amiről bootoljak) Roszkor jött, televolt kiíratlan adatokkal a 300Gb-os kötet...
-
Igen, csináltam egy tömböt, rámásoltam a tesztmappát aztán ott ismét lemásoltam ugyanarra a tömbre. És igen, 50-50 hogy emiatt amit írsz, bennem is felöttlött, viszont a mindennapi használat során is vegyes méretű írás-olvasások történnek, kivéve mikor mkv-kat muxolok szét vagy avikat/képfileokat tömörítek ki ki rar-okból, de ezek is össze-vissz 0,5-2 percen belül lezajlanak, nem halok bele ha picit lasabbak.
Azóta már felhúztam a Vistát, tömörítettem ki DVD-képfilet rar-okból és elindítottam egy játékot is.
Úgy vettem észre a Vista jobban érzi magát 4K-s stripeon mint 128K-n (bootolási idő, vezérlőpult megynyitása stb...), bár ez lehet attól is hogy most még friss telepítés...
Érzetre nem lassult a tömörítés se és ilyen mércével a játék is hasonló idő alatt töltött be. Sőtt, mikor spawnol a Crysis mintha kevésbé zavarna be a winyónyúzás. (lehet hogy apró csomagokban olvasgat be innen-onnan és így kedvezőbb neki a kissebb stripe ; direkt nem raktam addig fel az új patchet hogy azonos verziót vessek össze, 1.1-el már lehet kevesebbet spawnol...)Szóval összességében nem bántam meg mert rosszabb tuti nem lett. A pagefilenak és a Vistának szerintem jobb lett 4K-n mint 128K-n. Az még jó kérdés hogy többet ért-e volna 2 tömböt feldobni és a rendszernek szánt helyre 4K, a maradéknak meg 16K, de már mindegy, rosszabb nem lett mint 128K-val volt.
-
Nos, két dologra jöttem ma rá:
A HD-Tune teljesen alkalmatlan stripe-size tesztelésére, de főként az alloccation unit-éra, mert egy összefüggő kötetként megy végig a RAID-tömbön, nem is érdekli hogy van-e rajta partíció, valamint szinte ugyanazt az eredményt kaptam min-max-average speedre és acces timera is minden stripe sizevel (4K és 128K közt), csak a CPU-utilization változott és tűnt értékelhetőnek, de mértékadónak ezt sem nevezném.
A fontosabb felfedezésem hogy a HD-Tune benchmark szerint rengeteget dob a sebességen (főleg a stripe-sizenél kissebb csomagokkal való tesztnél) ha a matrix storage managerben bekapcsolom a kötetszintű visszaírási gyorsítótárat, de másolgatós-stopperelős tesztem szerint majdnem másfélszeresen lassítja a kötetet! (talán nem véletlenül van alapértelmezésben kikapcsolva)
Miután a benchmarkról lemondtam a fixált rendszerkötetemen összekészítettem magamnak egy mappát egy 700Mb-os AVI-val, 3 MP3 albummal és a windows könyvtárból méret szerinti kereséssel összehalászott apró fileokkal. Ezt többféle stripesizevel kreált és stripesizevel megegyező, vagy ha volt rá lehetőség (64K-ig) akkor annak kétszeresére vett foglalási egységgel formázott kötetre másoltam és ott duplikáltam miközben lemértem az időt stoperrel és néztem a taskmanagerben a CPU terhelést.
Végül arra jutottam hogy 4K-s stripe sizenek állítottam be az egész tárkapacitást és 4K-s fe-vel formázom. Miért?
A duplikálgatós teszt szerint koránt sem kell annyira félni a CPU használtattól mint a HD-tune mérésében, de ott is 20% volt a csúcs úgy hogy csak 1 magot használt a 2-ből, ez szerintem csúcsértéknek belefér a keretbe (ha 1000-rel ír a winyóra akkor úgyse nyúzza a program a CPU-t, ha meg a CPU-t nyúzza 1000-rel akkor nem akar a winyóra is veszettül írogatni mert gondolkodik mit kell írni...) Ezzel kár foglalkozni a stripe-size eldöntésekor.
A vegyes méretűre válogatott mappám duplikálásakor eltelt idő stopperrel való mérése nem a legpontosabb, de nekem megtette a ~10ms pontosság is, főként hogy alig volt különbség a mérések közt, tehát gyakorlatilag másolás sebességben sincs nagy különbség stripe size kapcsán. A 4K és a 128K néhány század másodperccel elmaradt a 16K-s mellett (neten keresgélve is olvastam hogy 16K lehet a nyerő), de 4K sem volt számottevően lassabb, így valós életbeli sok véletlenszerű ide-oda írogatást-olvasgatást is feltételezve iskább bíztam a gépet 4K-s stripera.
Az foglalási egység pedig stopperrel kimérhetetlen változást hozott duplikáláskor, a fent említett indokkal (esetleges sok random read) inkább 4K-ra tettem az fe-t is.
Az align-al próbálkoztam és 4K-ra is lehetett volna tenni, de a biztonság kedvéért 64K-val igazítottam a partíciókat (ezt már nem teszteltem ki, de elvileg a stripezize felett minden páros szám jó, mely egész számú többszöröse a 8-nak, a default meg 63...)
[ Szerkesztve ]
-
válasz
janos666
#2875
üzenetére
Úgy döntöttem inkább rászánok holnap egy pár órát, megbontom a mostani tömböm, aztán felhúzok egy XP-t és az intel matrix storage managerből felpakolok 10Gb-os RAID tömböket 3 féle sripe sizevel (4K, 32K és 128K), egyiknél kipróbálom majd az allocation unit belovését is stripesizera, vagy annak duplájára aztán mindhárom verzión lefuttatok 4 HD-tune tesztet (512-es, 8K-s, 64K-s és 8M-os tesztcsomagokkal) Persze mindhárom teszttömböt törlöm és újrarakom ugyanoda (mert tudom hogy a winyó eleje gyorsabb mint a vége...)
-
-
Uhmm, ami miatt igy konkretan rakerdeztem az hogy: A sripe sizenél nagyobb eltolás is ugyanolyan jó mintha pontosan kiszámolnám az MS cikk példaképletével hogy az aktuális stripe sizehez mekkora kell... Tehát ha 2Mb-al tolok az jó minden 1Mb alatti stripesizere, de nem jobb ha pontosan számolom? (most kérdésnek írom megint de tulajdonképp már válaszoltál hogy igen)
-
-
Nah, akkor erre még mondjon már valamit egy okos ember, hogy egy 4K-val csíkozott tömbön is kell-e partíció-eltolást csinálni vagy csak 64K-s csík felett?
-
-
-
Aha, szóval ha az intel vezérlőn 4K a minimum csíkszél akkor formázzak 8K-s foglalási egységgel swappartíciónak? És egy 32K-s stripe sizenél meg formázzak 64K-s foglalási egységgel? Az alapértelemzés paraméterezetlen formázáskor ugye 0,5K, tuti jobban érzi magát 64K-val formázva (tudtommal ez a megadható legnagyobb érték, ezért sem 128-as stripe sizet hoztam példának) a 32K-val csíkozott tömb? (végül is logikus, csak nem egyértelmű...)
).
![;]](http://cdn.rios.hu/dl/s/v1.gif)
):
Kíváncsi vagyok, hogy használható lesz-e az írási sebesség, ha lezárult a folyamat.
Új hozzászólás Aktív témák
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest