Szeretnék egy LV-t csinálni úgy, hogy több PV van alatta. A kérdés az, hogy ha az egyik PV kihal, akkor a többin marad-e használható adat? Vagy kb. annyi, mint RAID-0 esetén? Wikiben ennyit találtam:
http://en.wikipedia.org/wiki/LVM2
Creating single logical volumes of multiple physical volumes or entire hard disks (somewhat similar to RAID 0, but more similar to JBOD), allowing for dynamic volume resizing.
A JBOD alatt lévő HD-k közül egy meghibásodik, akkor oda az összes adatnak. Tehát ilyen működés van LVM alatt is?
Köszi!
- 4661 megtekintés
Hozzászólások
Szia.
Alapvetően szerintem mindkét állítás igaz, hiszen a fájlrendszer lesz az, ami nem fogja elviselni a lemez meghibásodását. Ebből a szempontból mindegy, hogy az most egy raid0, JBOD vagy éppen egy lvm kötet.
Véleményem szerint lvm-et csak abban az esetben érdemes használni, ha biztosított a lemezek redundanciája. Ha ez teljesül, akkor viszont az LV-t létrehozásakor érdemes megadni a PV-k számát és a stripe méretet is, így az LV egy kvázi raid0-t alkot a résztvevő PV-ken. Esetleg raid1+0 + sima LVM, mdadm esetén inkább ezt szoktam preferálni.
Üdv: Zoli
- A hozzászóláshoz be kell jelentkezni
Szia!
Köszi a választ! Nem szeretnék redundnciát, mert alapvetően pótolható adatokat tárolnék rajta, csak azt szeretném, ha kihal az egyik disk akkor a másikon még elérhetőek maradnának a layer által elfedett módon oda mentett fájlok. Lehet inkább raid liner-ban gondolkodjak?
- A hozzászóláshoz be kell jelentkezni
ilyen állat nincs.
illetve van: mindkét diszkre készítesz egy-egy fájlrendszert, és egymás mellé mindkettőt felmountolod, aztán a fájlaidra eldöntöd, hogy melyikre kerüljenek.
- A hozzászóláshoz be kell jelentkezni
Ez azert bukta, mert a volume-ok meretei nem feltetlenul fognak megegyezni a diszkek mereteivel.
Lasd az en hozzaszolasomban.
- A hozzászóláshoz be kell jelentkezni
Azt akarta mondani, hogy felejtse el az lvm-et, és használja a diszkeket a'la natúr device-ként az fs alá, és kézzel csinálja meg a fájlok szétszórását a kettő között.
Egyébként nekem anno sikerült 18G (4*4.5G) összefűzött diszktömbből kibacarintani egyet (scsi-ID ütközött yool...), és hát igen... Volt adatvesztés...
- A hozzászóláshoz be kell jelentkezni
Ha nincs alatta egyéb redundancia (raid1) akkor pusztul. Egyébként a pv alatt vg van, és az alatt vannak az lv-k. Azokat az lv-ket amik a működő pv-n vannak, el lehet indítani, ehhez a vg-t vgreduce-al kisebbre kell venni (ki kell venni a döglött pv-t).
Remélem érthető, szép magyar mondat lett... :)
--
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
Köszi a választ! Azt hiszem értem. :) Tehát itt nincs olyan, hogy az lv-k között feldarabolja a rendszer a mentendő fájlokat, és ha kihal egy pv, akkor csak egy halom „félbyte” lesz meg a fennmaradó lv-ken?
Hogy jobban érhető legyen mit szeretnék: alapvetően pótolható adatokat tárolnék így egybekötött lv-kkel, de jó volna, ha egyik pv kiesése esetén azért még megmaradna a többi anyag a másik pv-n. Még erősen gondolkodom a raid linear-on, mert tudtommal ez tényleg pl. két ext3-ra formázott partíciót egynek mutat, de attól még külön-külön is fel lehet csatolni őket ha adatot kellene visszaállítani.
- A hozzászóláshoz be kell jelentkezni
Tehát itt nincs olyan, hogy az lv-k között feldarabolja a rendszer a mentendő fájlokat, és ha kihal egy pv, akkor csak egy halom „félbyte” lesz meg a fennmaradó lv-ken?
Ha az LV-t stripping-al hoztad létre, akkor ugyanúgy kis blokkokat fog tárolni felosztva a PV-ken, mintha egy RAID0-t használnál, egyébként szépen sorban fogja kiosztani a blokkokat.
Hogy jobban érhető legyen mit szeretnék: alapvetően pótolható adatokat tárolnék így egybekötött lv-kkel, de jó volna, ha egyik pv kiesése esetén azért még megmaradna a többi anyag a másik pv-n. Még erősen gondolkodom a raid linear-on, mert tudtommal ez tényleg pl. két ext3-ra formázott partíciót egynek mutat, de attól még külön-külön is fel lehet csatolni őket ha adatot kellene visszaállítani.
Az a probléma, hogy ezek még mindig csak blokk eszközök, erre hozod létre a fájlrendszert. És ha a fájlrendszer alól kiveszel egy darabot, azt nem fogja túlságosan tolerálni, így erre építeni nem lehet, csak annyira, mintha egy raid0-t használnál.
A raid linear sem fájlrendszer alapon fűzi össze a lemezeket, hanem blokk szinten és erre hozod létre megint csak a fájlrendszert. Így semmivel sem lesz több, mint egy LVM kötet.
Összességében vagy bevállalod, hogy tönkremehet a fájlrendszer és ekkor pótolni tudod az adatokat (illetve egy részüket), vagy biztosítani kell a redundanciát, bármelyik megoldás mellett is döntesz.
Üdv: Zoli
- A hozzászóláshoz be kell jelentkezni
2. raid linear: csak ha szerencséd van, akkor igaz amit írtál.
1. attól függ :) hogy hogyan/hova csinálod meg az lv-ket. mondhatsz olyat, hogy csak egy bizonyos pv-re tegye az lv-t. Sőt, mozgatni is lehet pv-k között egy lv-t úgy, hogy közben használod. Csinálhatsz lvm-en belül is redundanciát (raid1), ekkor két pv-n lesznek ugyanazok az adatok.
Tulképp mindent lehet amit el tudsz képzelni, csak megfelelően fel kell paraméterezni a parancsokat.
--
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
Egy LV-re egy filesystemet teszel, és egy helyre mountolod.
Ígyhát a válasz: nem, a mentendő fájlokat a rendszer nem szórja szét neked különböző mount pointok és filesystemek között.
Akkor szívsz, ha egy LV-d több PV tetején ül. De ezt persze tudod befolyásolni.
- A hozzászóláshoz be kell jelentkezni
Ha nem redundans pv-kbol akarsz epitkezni, es elfogadod, hogy pv vesztes eseten odaveszik nehany erintett volume, akkor lehetoseg szerint olyan volumeokat hozz letre, ami nem lep at egyetlen pv-pv hatart sem. Suru vgcfgbackup javasolt, a meglevo volumeokat pedig pvmove-val szepen elrendezgetheted ennek megfeleloen. En a helyedben minden egyes disken ketto particiot hoznek letre, egy nagyot, ami pv-kent funkcional, valamint egy egesz picit, amibol (az osszes disk resztvetelevel) egy raid1 tombot csinalnek, amire a visszaallitashoz elengedhetetlen metaadatokat mentenem. Esetleg meg tennek ra egy sysresccd-t is, bootolhatoan.
Asd
--
zsebHUP-ot használok!
- A hozzászóláshoz be kell jelentkezni
Köszönöm szépen mindenkinek a segítséget, úgy döntöttem maradok a legegyszerűbb megoldásnál: nem vonom össze a két üres területet, majd hol ide hol oda másolok kézzel.
- A hozzászóláshoz be kell jelentkezni
Miért döntöttél így?
- A hozzászóláshoz be kell jelentkezni
Végülis azért, mert nem akartam túlbonyolítani az életem. Ez egy sima otthoni desktop gép, majd megoldom kézzel.
- A hozzászóláshoz be kell jelentkezni
Symlinkekkel ez is frankón megoldható, csak akkor leszel bajban, ha "meg akarsz cserélni" nagyobb adatmennyiségeket mint amennyi helyed van. Meg a symlinkekbe könnyű belezavarodni... :)
--
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
Szokás szerint a HP-UX LVM-jéből indulok ki, de amit leírok talán működik Linux alatt is!
- csinálj egy volume groupot a két diskből!
- hozz létre egy nulla extent hosszúságú logical volume-ot!
- mivel az lvcreate-nél nem, de az lvextendnél megadhatod a cél-PV (physical volume) címét, a nulla hosszú LV-t növeld meg akkorára, hogy felhasználja a megadott PV összes extentjét.
- a fentieket megteheted a második disken egy második LV-vél.
Persze a fentieknek nincs túl sok értelme, de így oldható meg amit szeretnél. Szerintem.
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
- mivel az lvcreate-nél nem, de az lvextendnél megadhatod a cél-PV (physical volume) címét, a nulla hosszú LV-t növeld meg akkorára, hogy felhasználja a megadott PV összes extentjét.
Úgy látom, hogy megadható az lvcreate esetén is, legalábbis Linuxon.
Üdv: Zoli
- A hozzászóláshoz be kell jelentkezni
Akkor az élet egyszerűbb, nem kell a nulla hosszúságú LV-vel trükközni, egyszerűen csak akkorát kell létrehozni mint a PV és explicite meghatározni, melyik PV-n jöjjön létre!
- A hozzászóláshoz be kell jelentkezni
Azt azért elárulhatnád, hogy HP-UX-on mi a bánatnak kell ez az agyament trükközés - szűz VG-k esetén? Definíció szerint az lvcreate/lvextend a vgcreate-ben megadott sorrend szerint használja a diszkeket, azaz:
vgcreate vgzahy /dev/sda1 /dev/sdb1
esetén ha kiadok egy
lvcreate -n volzahy1 -l sizeof_sda1_in_extents vgzahy
parancsot, az így létrejövő volzahy1 pontosan *csak* az sda1-et fogja elfoglalni, majd a következő
lvcreate -L sizeof_sdb1_in_MB vgzahy
az pedig pontosan *csak* az sdb1-et. Abban természetesen igazad van, hogy ha már vannak különböző LV-k, akkor az egyik megoldás az általad fentebb vázolt. (De lehet például "pvchange -x n /dev/sda1" paranccsal letiltani az sda1 későbbi felhasználását :-) - amit nyilván szükség esetén újraengedélyez az ember, ha kell.)
- A hozzászóláshoz be kell jelentkezni
Mert amit te írsz, az valószínű, amit meg én, az biztos. Ráadásul működik nem szűz VG-n is.
- A hozzászóláshoz be kell jelentkezni
Az első pontot elmagyarázhatnád, miért valószínű? Minden doksiban benne van, hogy így működik a HP-UX LVM-je :-)
- A hozzászóláshoz be kell jelentkezni
Mert úgy vagyok én ezekkel az "így működik, le van írva" dolgokkal, hogy az csak valószínű. Mint pl. spare disk az LVM-ben, amit sokáig csak a doksi tudott. Másfelől egy defaultnak hitt működés egyik patchelésről a másikra megváltozhat.
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni