Sziasztok!
Fent említettek közül szeretnék választani az alábbira:
Adott 4db 3TB-os merevlemez.
A cél, egy ~12TB-os partíció.
Másik cél:
Szeretném lineárisan összefűzni a 4db hdd-t. Azaz ha megtelt az egyik, jöjjön a másik, stb.
Ami fontos lenne, hogy ha elszáll az egyik HDD, akkor ne omoljon össze az egész 12TB-os tábla. (Ha jól tudom, akkor LVM összeomlik)
Illetve, nem kell redundánsnak lennie, csak hogy a maradék 3db hdd tartalmát ne veszítsem el örökre, hanem vissza lehessen hozni.
(Értelmét ne kérdezzétek, ez a feladat, amit nekem is meg kell oldanom. :D Ebből lesz 2db.)
Köszi előre is.
- 8963 megtekintés
Hozzászólások
Szerintem ilyent nem fogsz tudni csinálni, mert ha bármely fájlrendszer adatainak 1/4-én megsemmisíted (főleg, hogy sokan a tömb elejét preferálják erre/arra), elég nagy a sansz rá, hogy belehal minden, bár inkább úgy mondanám, hogy papi segítség kell ahhoz, hogy maradjon értelmesen felhasználható rész számodra (Kürt és társai nem játszanak most...).
- A hozzászóláshoz be kell jelentkezni
Miert is?
LINEAR-ra keress.
udv,
tamas
- A hozzászóláshoz be kell jelentkezni
Nem az a bajom, hogy hogyan fűzöm össze a 4db diszket látszólag egy kötetté, de mit csinálsz a fájlrendszerrel rajta, ha valamely lemez kiesik?
Vagy kérdezek konkrétat: ismersz olyan fájlrendszert, ami ezt kibírja ép ésszel?
A feladat az, hogy összerakd a 4 lemezt *és* kibírja a kihullását valamelynek az üzemeltetett rendszer.
- A hozzászóláshoz be kell jelentkezni
ismersz olyan fájlrendszert, ami ezt kibírja ép ésszel?
GPFS talán :)
Majd az IBM-es kollégák megmondják.
- A hozzászóláshoz be kell jelentkezni
Ahogy irtak lentebb is, erre iranyultan megoldhato a dolog. ZFS vagy btrfs is jo elvileg. Vmint ott van az unionfs es az uafs, ahogy lentebb okosan irtak, nekem az eszembe sem jutott:)
Ettol fuggetlenul nem vagyok benne biztos, h az ext4 egy fsck nem mukodne vmelyest utana, probald ki.
Persze az egesz otlet egy nagy baromsag, szoval a megoldasok is jobbara pont annyira eroltetettek (kiveve a btrfs-t es a zfs-t).
tompos
- A hozzászóláshoz be kell jelentkezni
Mondjuk nekem sem jutott eszembe. Valamiért a klasszikus fájlrendszereknél elakadtam. :)
- A hozzászóláshoz be kell jelentkezni
Tehát ha pl mdadm-el csinálok egy linear /dev/md0-t.
És kiveszem, az egyik merevlemezt, akkor a többit nem tudom helyre állítani ?
Ha fail-nak jelölöm és remove-al eltávolítom, egy scan-el nem kapja össze magát?
- A hozzászóláshoz be kell jelentkezni
A RAID osszekaphatja magat, de kerdes, hogy a fajlrendszer hogy fogja ezt turni. Ha sikerul az elso merevlemezt kivenni, akkor sehogy. Ha az utolsot, akkor egy resize talan meg tudja oldani a kerdest, bar cinkes.
Altalaban azt szoktak mondani, hogy ilyet csak ugy erdemes csinalni, ha az adatok nullahoz konvergalo idot toltenek ott, vagy nem erdekes, ha nem marad meg a tartalom. Az elsore pelda lehet mondjuk valami idoszakos rogzitoeszkoz, amirol folyamatosan lapatoljak ki az adatot, csak nincs olyan gyors halozat, hogy mindezt valos idoben tegyek, a masikra pelda valami cache, pl. proxy cache.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Olyasmit szeretnél, amit nem lehet.
Ez csak akkor valósul meg, ha semmit tárolsz rajta, mert azt könnyű visszaállítani. :)
Ahhoz, hogy egyik disk kihullása esetén az adatokat helyre lehessen állítani két megoldás van.
1. kialakítasz egy olyan rendszert, ami ezt megoldja
2. kürt kft, ha tönkremegy, viszed és megoldják.
Egy közös van bennük, mint a kettő pénzbe kerül. Első kicsit olcsóbb.
1. esetben, mindenképpen be kell áldoznod egy disk-et, hogy a leírt adatvesztés nélküliséget megoldjad. Erre így első a raid5-öt javaslom. Így marad 9T helyed, és egy disk kihullást elvisel. Minél nagyobb biztonságra törekszel, annál több disk-et kell beáldoznod.
A dmraid akkor jó, ha a hw támogatja a raid funkciót, de ezek legtöbbje csak raid0-át és raid1-et támogat.
A mdraid egy sw raid linux rendszerhez. Ennél feldarabolnám minimum 4 részre a disket, és ezeket a szeleteket tenném egy-egy raid5-be. Majd ezeket a raid5 részeket tudod egy LVM-el összefűzni egy 9T méretű partícióvá.
Ennek utána tudsz olvasni, hogyan is kell.
Az a gond, hogy másképp csak 4db különálló területed lenne, mert maga a filerendszer nem bírja el a disk kihullást.
- A hozzászóláshoz be kell jelentkezni
Igen.
Ezért írtam hogy ez a feladat. Így én is meg tudnám oldani, tud is a hardver raid-eket. Azt is tudom hogy kell egy spare disk stb.
De nem az egész 12TB-ot szeretném diszk kihullás esetén visszaállítani, nem vagyok hülye :D
Azért gondoltam a sw raid-re, met pl Win alatt is van olyan, hogy egy NTFS partíciót ha törölsz, ingyenes egyszerű progikkal vissza lehet állítani a partíciós táblát.
Még másolgatni sem kell.
u.i: Ez az egész csak egy backup lenne.
- A hozzászóláshoz be kell jelentkezni
Marmint hogyertve backup? Van 12T adatod amit hirtelen ki kell rakni valahova?
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
Miert jo particiokat RAID-be rakni? Szerintem csak a winyofejet fogja enni meg jobban.
En csinalnek mindegyikre 1 particiot, azt RAID5-be, LVM es hajra. Nincs ertelme particiozni, ha utana ugyis ujra fel lesz osztva az egesz.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
A RAID5 addig jo, amig nincs valami komolyabb baj. Elmeletben persze csak beraksz egy masik HDD-t, a gyakorlatban viszont eleg izgulos a dolog. (Fog-e mukodni a rebuild, nem szar-e a szoftver, nem hal-e meg a masik HDD is menetkozben...).
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
Milyen igazad van. Minden addig jó, amíg el nem romlik :) Azért egy raid5 még mindig biztonságosabb az adattárolás szempontjából, mint a semmi.
- A hozzászóláshoz be kell jelentkezni
A RAID-5 egy automatikus snapshottingal rendben van. Anelkul csak illuzio, termeszetesen.
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
Persze. És raid nélkül mi van?
- A hozzászóláshoz be kell jelentkezni
Ez raid1 eseten is igaz....
- A hozzászóláshoz be kell jelentkezni
RAID1 eseten egy elhalalozo OS vagy kontroller nem okoz gondot. (Legalabbis Intel alaplapi fakeraiddel (dmraid), linuxos mdraiddel, Windowsos Intel Matrix Storage-el es Windowsos softraiddel volt dolgom, barmelyik HDD-t kiszedve a tombbol es berakva egy masik PC-be tokeletesen olvashato volt az anyag).
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
"nem hal-e meg a masik HDD is menetkozben..."
Amugy igaz, nem egyszer klonoztam igy gepet...:)
- A hozzászóláshoz be kell jelentkezni
Ha feldarabolod a disk-et, akkor egyes részeknek gyorsabb lesz a szinkron, így kisebb a széthullás esélye. Főleg, ha van spare disk.
Plusz így több disk IO hibát is elvisel, ha az a másik partíciós részen van, tehát egy kis plusz munkával növelhető a biztonság, bár a hibásodás is nőhet.
- A hozzászóláshoz be kell jelentkezni
"egyes részeknek gyorsabb lesz a szinkron, így kisebb a széthullás esélye."
He? Ezt a mondatot lécci magyarázd el, én elvesztettem a fonalat az "így" szónál.
Az IO hibat meg... ez se jön össze sehogy. Ha RAID1 a téma, az váltogatva olvas a tükörpárról, így gyorsítva fel az adatok cachelését (pontosabban, megpróbálja elöre belátni, hogy honnét fogsz olvasni (readahead), es a cache-ba egyszerre mindkét diszkröl olvas), ez a lényege. Nyilván ha kap egy sallert (IO error), akkor automatikusan fallbackel a tükörpárra (ez a mirror működési elve), és ez független a résztvevő tükörpárok méretétől.
A RAID5 esetében pedig ugye akkor nincs gond, ha legfeljebb egy diszkről kap IO errort ugyanahhoz az olvasási egységhez, mert akkor vagy simán, vagy a paritás alapján helyrelövi az adatot. Ez megint blokkszinten megy le, lényegtelen, hogy 10G vagy 10T darabokban vannak a RAID párok.
Ahogy én értem, ez valójában egyre jó: minél gyorsabban hazavágni a winyófejet. Mivel az LVM totálisan hardverfüggetlenül fogja újraosztani a blokkokat (ennek a szerencsétlennek meg ez adja a lényegét, plusz esélytelen a RAID alá látni), rossz esetben minden blokkolvasás más particiót fog érinteni (főleg random növelgetéseknél van ez így, de a töredezettség is okozhat ilyet), ami jó sok fejmozgással jár. Ha valami, hát ez garantálja a gyors amortizációt.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Ha csinálsz több partíciót a rendszernek egy adott disken, akkor is rángatja a fejet.
Tehát ha már jártál úgy, hogy a szinkron alatt lett hibás még egy disk, és megállt az egész, akkor elgondolkozol, hogyan tudtál volna időt spórolni.
Ha már sw raid, akkor lehet játszani.
nézzünk egy klasszikus raid1-et 2 disk-el 1 partíció. Mi van, ha az egyik disk IO hibás lesz? Akkor az hibássá válik, és olvas a másikról. Ezután a másik disk is IO hibás lesz. Ez a totál szívás. Nézzük ugyan ezt 4 partíció esetén. Ha a több partíció van akkor kisebb adat repül a kukába, ha a másik disk másik partíciós helyes lesz IO hiba, akkor még mindig nincs adatvesztés.
Fejrángatást meg a cache méretével lehet kulturálttá tenni, így csak nagy adatokat ír ki.
Persze mindig a felhasználási körülmény határozza meg a választott felépítést. Olyan rendszer ami sok statikus adatot tárol, ott nincsen sok fejrángatás, de fontos az adat biztonság. Ahol sok IO művelet van, ott nem lesz több T disk, mert csak lassítja az egészet, így ott teljesen más felépítést választanék.
- A hozzászóláshoz be kell jelentkezni
Figyelj, olyan kornyezetben dolgoztam/dolgozom, ahol ha IO hiba van, akkor a winyo repul a kuka fele, koszonni nincs ideje. Nem volt eselye annak, hogy bejojjon az, hogy a masik winyo is hibas. Annak meg egy picit kisebb az eselye hogy egyidoben ket winyo hibasodik meg a tombbol (bar nem nulla, volt mar ilyen sajna).
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Attol meg igaza van am.
Plane, h fuggetlen a leirtak fuggetlenek a kukatol.
tompos
- A hozzászóláshoz be kell jelentkezni
"Mi van, ha az egyik disk IO hibás lesz? Akkor az hibássá válik, és olvas a másikról. Ezután a másik disk is IO hibás lesz. Ez a totál szívás."
Igen, idaig igaza van. Azonban ahol ilyen egyaltalan felmerul (a masik disk is hibas lesz), ott sokkal nagyobb problemak is vannak, mint ez az IO hiba: a jobbik eset az, hogy a rendszergazda nem ert hozza, a rosszabbik, hogy a ceg szarik az ilyenekre, es nem szerez be uj disket. Az elobbi eset orvosolhato a szakember lecserelesevel, az utobbinal viszont fejtol buzlik az egesz. Ahol nem kepesek belatni, hogy az IO error kozvetlen veszely az adatokra...
Viszont ha jobban hasznaljuk a winyofejet, akkor elobb lehet IO hibank, illetve hamarabb jon a SMART error bootolaskor, mint kellene. Persze, ez megint hasznalattol fugg, ha alapvetoen csak olvasunk a diszkrol, azt is ritkan, akkor persze, miert ne. De ilyen tortenetet lattam mar eljatszani konkretan virtualizacio ala tolt diszkparokkal is, ahol viszont az ilyen otleteket meg fogamzasukkor kell elfelejteni.
Szoval, elfogadom, lehetnek olyan esetek, esetleg, neha, talan, ahol ennek van ertelme. Az esetek nagy reszeben nincs.
PS: marmint, ugye most arrol folyik a tema, hogy ezt a felszabdalt winyot utana egyesitjuk LVM-ben. Ha kulon slice-k maradnak, es a RAID node-k mas-mas dologra vannak felhasznalva, akkor semmi kifogasom ellene, sot en is igy tervezek gepeket. Nekem azzal van a gondom, hogy utana LVM-ben akarja egyesiteni ezeket a kulonallo node-kat, majd ujraosztani. Altalaban nem sikerul ugy ujraosztani oket, hogy pont winyohatarra essenek az LV hatarok.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Pont arrol van szo, h ha kiesik egy _particio_, akkor attol meg az adatok nagyobb biztonsagban vannak, mintha kiesett volna masik particio is (azaz az egesz HDD).
Nem kell feltetelezni, stb. Eleg csak annyi idore, amig a spare-re szinkronizal, vagy javitjak, amit javitani kell.
Igy a szolgaltatas tovabb tud mukodni, megbizhatobban.
Egyebkent igen, van hogy vissza kell/lehet rakni, mivel nem egyertelmuen a HDD a hiba. Lehet meg a vezerlo, a kabel vagy akar a tap. A HDD-t hiaba cserelgeted az eleted vegeig, a hiba elo fog jonni.
tompos
- A hozzászóláshoz be kell jelentkezni
- Ezt most nem ertem. Adott egy 4 RAID tomb, ezt felfuzzuk egy LVM-re. Ez volt a kiindulasi alap. Ebbol 2 particio (1 RAID tomb) kiesik, akkor egyreszt ki kell venni a tombot az LVM alol, ha erre egyaltalan van meg lehetoseg; masreszt ugyis a komplett winyot kell cserelni, mert egy darab particiot cserelni nem lehet.
- A szinkronizaciot semmiben sem fogja gyorsitani tobb particio. Az MD RAID-nak megvan az a kellemetlen tulajdonsaga, hogy egyszerre csak egy tukorpart szinkronizal. Ha a komplett winyo cseres volt, osszessegeben pont annyi idot fog elszinkronizalni, mintha egyben lett volna az egesz. Mivel a szinkron alatt sem valik RO-va a disk, igy ez legfeljebb IO kiesest okoz, ebben viszont nincs kulonbseg sem idoben sem terhelesben a ket megoldas kozott
- Ha visszarakjak a HDD-t, mert nem az a hiba, az egy masik dolog, de itt nem is a vezerlo meghibasodasarol beszelgetunk. Egyebkent ha vezerlo oldali meghibasodas van, az altalaban ugyis egy hosszabb downtime-mal jar, mert akkor vagy kabelcsere, vagy firmware frissites, vagy vezerlocsere tortenik, ezek mindegyike csak offline vegezheto biztonsagosan. De a vezerloproblemat senki nem hozta elo, csak te. Azt mar nem is bizgatom, hogy az esetek 80-85%-ban nem az elso gyanu a vezerlo meghibasodas, hanem 3-4 HDD csere utan szokott ez lenni a diagnozis.
Osszessegeben: van ertelme feldarabolni egy disket, es kulon RAID node-kkent kiajanlani, ha azok a node-k kulon-kulon, direktben kerulnek felhasznlasra. Tehat mittomen az md0 lesz a /boot, az md1 a /, az md2 a /home az md3 meg a /srv, ebben az esetben van ertelme. De ha a RAID node-okat osszefuzod egy LVM-be, majd ujraosztod, akkor tobb kar van az egeszbol mint haszon, mert egyreszt semmi garanciad nincs arra, hogy az LVM alol ki tudod tepni a hibas RAID node-t (amennyiben a RAID mindket fele pont ugyanazon a particion hibasodik meg, ez is ritka allat, de hat...), masreszt pedig tobb adminisztracio es tobb lehetseges hibaforras van az egeszben. Nem tudom belatni, hogy ebben az esetben (LVM) is hasznos lenne ez a feldarabolos moka.
Azt szinten nem akarom megemliteni, hogy nem vagy sokkal beljebb ha az egyik winyo az egyik particion a masik winyo a masik particion hibasodik meg. Valo igaz, hogy ez az eset jonak latszik, viszont a szolgaltatas megbizhatosaga mindenkeppen csokkent. Csak most raadasul meg winyot sem tudsz cserelni, mert nem tudod, melyik ujjadat harapd meg, ugyanis ha az egyik winyot kiveszed, akkor kiveszed az egyik hibas particio jo parjat, ha a masikat veszed ki, akkor a masik hibas particio jo parjat veszted el. Olyankor jonnek az olyanok, hogy akkor rakjuk be az uj winyot kulon eszkoznek (mar ez is necces, van-e egyaltalan hely hozza), synceljuk at az osszes particiot (IO lassulas, jo hosszan), egy winyo ki, masik uj winyo be, synceljuk le megint az osszes particiot (mint fent)... Semmit nem nyertel az ugyon, viszont legalabb jo bonyolult lett a munkad.
Helyes diskmenedzsmenttel ez ugy nez ki, hogy az elso winyon megjelenik az IO hiba, akkor betoljuk az uj winyot, lesynceljuk a masikat, es kossz. Utana idoben kesobb ha meghibasodik a masik winyo, akkor megint cserelunk egyet, lesynceljuk 1x a masikat, es megint kossz.
Mint korabban mondtam, a vezerloproblemat azt itt kulon nem targyalom, mert az egy egeszen masik allatfaj, es nem lehet anamnezis (elozo tunetek) nelkul megmondani, hogy az adott IO error az most disk vagy controller error.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Nem olvastam vegig, de azt hiszem, h mar ertem, min akadtal fenn. Igy persze, igazad van.
tompos
- A hozzászóláshoz be kell jelentkezni
ezt hívják JBOD nek, mikor csak egymás után fűzöd a diskeket, és egymás után írja az adatot. Azt viszont sose néztem, hogy mi történik ha 1 disk kihullik, valószínűleg az FS-nek nem nagyon fog tetszeni.
Fedora 16, Thinkpad x61s
- A hozzászóláshoz be kell jelentkezni
A striped vagy JBOD jellegű RAID0 esetében a fölé rakott (RAID-ről nem tudó) fájlrendszer mindenképpen szomorú lesz, ha kiesik alóla egy rakás blokk. Esetleg ha lineárisan jönnek az adatok, akkor használható lehet valami (fájlrendszerekről nem igazán tudomást vevő) recovery tool, például a photorec. Az adatok egy része így visszanyerhető, de a könyvtárstruktúra pl. nem.
Ha valamiért mégis nagyon fontos lenne, akkor két lehetőséged adódik.
Használhatsz olyan fájlrendszert, aminek van tudomása a RAID-ről. Ilyen lehet a btrfs fájlrendszer 4 eszközzel úgy, hogy a metadata raid1, a data pedig raid0 (vagy single) módot kap. Ilyenkor degraded módban valószínűleg felcsatolható marad a fájlrendszer, a hiányzó adatblokkok esetében pedig olvasási hibát kapsz. Ez egyrészt nem lesz lineáris (ezt szeretted volna), másrészt elképzelhető, hogy egyáltalán nem is engedi felcsatolni ilyenkor, tehát mindenképpen ki kellene próbálni.
A másik lehetőség, hogy a 4 eszközön csinálsz 4 db független fájlrendszert, majd egy virtuális (egyesített) fájlrendszerré összevonod őket. Erre ad lehetőséget az Aufs vagy az UnionFS. Mindkét esetben több (4 db) írható branchet kell majd megadnod. Az Aufs esetében a create=mfs opció osztja el a terhelést, ellenkező esetben elfogyhat a hely, ha betelik az első partíció. És hogy a teljes méretet mutassa a df, szükség lehet a sum nevű mount opcióra is. Ez sem lesz lineáris, de legalább marad 3 db teljesen ép fájlrendszered az egyik diszk kiesésekor is.
- A hozzászóláshoz be kell jelentkezni
Ez a második ez jól hangzik, utána olvasok, köszönöm!
- A hozzászóláshoz be kell jelentkezni
Momentán nem jut eszembe a neve, de van egy ilyen cucc, ha jól emlékszem linux alapú. Pont ezt tudja amit írsz, jellemzően filmek tárolására egyszerű buta otthoni nas-nak.
Ha eszembe jut a neve, megírom ide.
Standard linuxos eszközökkel nem hiszem, hogy megoldható lenne, persze az a parasztos megoldás van, hogy csinálsz minden nagy diszknek külön fs-t, külön mountpointot, majd egy közös dir alá behúzod mindet. Már amennyiben ez megoldás persze.
Mondjuk ekkora fs-t raid1 nélkül nem csinálnék, az is biztos, és akkor már mehetne lvm-el simán.
--
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
Ez maga lesz egy backup.
Nem tudom mi a f*sznak kell így, hisz ha a 12TB összeomlana, tükörben meg van az egész...
És sztem egyszerűbb is volna onnan a 12TB-ot helyre állítan 1-1ben, mint szopni az összeomláskor :D
De ha eszedbe jut a cuccmák, szólhatsz, mert elsőre én is azt ajánlottam amit Te, hogy 4FS, 4mount, 4dirs.
* html {display: none}
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Ha ilyen feladatot kapsz, a balhet is radverik majd, mikor oda van x Tb adat.
Orosz rulett; en nem csinalnek ilyet, bar hasonlot tolem is kertek. Epp volt egy sw raid0 -t tartalmazo tesztgep; megmutattam, mennyi ido alatt veszited el az osszes adatot (megpoccintettem a hot swap keretet kicsit jobban...). Nem kellett tovabb magyarazkodnom.
- A hozzászóláshoz be kell jelentkezni
http://karikasostor.hu - Az autentikus zajforrás.
- A hozzászóláshoz be kell jelentkezni
:O :D :D Hát, ez a világ azon része, amiről nem biztos hogy akartam tudni..! :D
- A hozzászóláshoz be kell jelentkezni
Na azt hiszem ez a megoldás ami kellett. Ma le is tesztelem és beszámolok róla.
Köszönöm!
- A hozzászóláshoz be kell jelentkezni
Itt az ideje, hogy hogy a laptopon és a desktopon lvm-lg-pv-raid1(féllábú) (pen)drive-okat a desktopon fstab-ban mountolva vizslassak.
Keresztfürtözés: - Vajon mindkét gépen megtehetem ezt ugyanazzal a két logikai meghajtóval, egyidejű használat mellett?
- A hozzászóláshoz be kell jelentkezni
Megvan a megoldás.
http://hup.hu/node/113303#comment-1442517
p2pking adta a jó megoldást. Drive Pooling-nak hívják az eljárást.
A leírás: http://romanrm.ru/en/mhddfs
A már fel mountolt 4db partíciót egyesíti egy Virtuális mount pointban.
Kipróbáltam, tökéletesen működik és erre való amit én szeretnék most.
+ jól mutatja az összegzett szabadhelyet.
Köszönöm mindenkinek!
- A hozzászóláshoz be kell jelentkezni
Miket tanul az ember...
- A hozzászóláshoz be kell jelentkezni
subscribe
(Remélem soha nem kell ilyet megoldanom)
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
"A +1 az a proletárlájk."
- A hozzászóláshoz be kell jelentkezni
Mielőtt az élesben használnád, kipróbáltad, hogy mi van ha kirángatod alóla az egyik vagy több diszket? Érdekelne az eredmény.
- A hozzászóláshoz be kell jelentkezni
subscribe
- A hozzászóláshoz be kell jelentkezni
subs
- A hozzászóláshoz be kell jelentkezni
Egymást kizáróak a feltételeid. Ha bármilyen redundancia nélkül összefűzöd a diszkeket, akkor egy diszk kiesése olyan csodálatos adatvesztést fog csinálni, hogy ihaj. Ekkora böszme nagy diszkekből én max. raid10-et lennék hajlandó összerakni (az ugye pont a fele annak a kapacitásnak, ami neked kell, azaz még ként négy diszk), vagy ha írási teljesítményben (jóval) lejjebb adod (vagy vesztek egy normális raid-kártyát), akkor egy diszket hozzápasszintva raid6.
Miért nem raid5? Murphy. Ha egy diszk elpukkan, Murrphy a megmondhatója, hogy pont a resync alatt fog a következő diszk meghalni, úgyhogy raid6, öt diszkből pont kifér a ~3 diszknyi nettó kapacitás.
- A hozzászóláshoz be kell jelentkezni
Mintha már megtalálta volna a feltételeinek megfelelő megoldást.
- A hozzászóláshoz be kell jelentkezni
Feliratkozom, hogy lássam a teszt eredményeket.
- A hozzászóláshoz be kell jelentkezni
Már csak azért sem sima diszkekkel!
a gyakorlóeszköz összerittyentése:
pendrive két elsődleges autoraid partícióra felosztva.
mindkettőből raid1-pv-lg-lv,
:~# mdadm -C /dev/md91 -l 1 -n 2 /dev/sdc1 missing
:~# pvcreate /dev/md91
:~# vgcreate pen91 /dev/md91
:~# vgdisplay
...
VG Size 500,00 MiB
...
:~# lvcreate -n lpen91 -L 500MiB pen91
:~# mkfs.ext3 /dev/pen91/lpen91
:~# mkdir /mnt/pen1
:~# mount -a /dev/pen91/lpen91 /mnt/pen1
...
...
:~# mkdir /mnt/penall
:~# mhddfs /mnt/pen1,/mnt/pen2 /mnt/penall -o allow_other
mhddfs: directory '/mnt/pen1' added to list
mhddfs: directory '/mnt/pen2' added to list
mhddfs: mount to: /mnt/penall
mhddfs: move size limit 4294967296 bytes
:~# df
...
/dev/mapper/pen91-lpen91 495844 10669 459575 3% /mnt/pen1
/dev/mapper/pen92-lpen92 495844 10773 459471 3% /mnt/pen2
/mnt/pen1;/mnt/pen2 991688 21442 919046 3% /mnt/penall
Működik, ami nem fér be a lista-első egységre, az megy a következőre.
Ha a /mnt/penall-ba írt könyvtárnak több hely kell, akkor duplázódik, és a tartalma másik fele a másik egység ugyanolyan nevű könyvtárában lesz fizikailag.
- A hozzászóláshoz be kell jelentkezni