[Megoldva]Hogyan?

Linux-kezdő

Egy távoli szerveren van egy ilyen felállás:

sdb 8:16 0 1,8T 0 disk
├─sdb1 8:17 0 243M 0 part /boot
├─sdb2 8:18 0 1K 0 part
└─sdb5 8:21 0 1,8T 0 part
├─vg--system-system 254:0 0 465,7G 0 lvm /
├─vg--system-swap 254:1 0 9,1G 0 lvm [SWAP]
└─vg--system-data 254:4 0 1,4T 0 lvm /mnt/backup-home

A vg--system-data terhére kellene csinálnom egy 100G 'native' sdb6 partíciót, lvm nem jöhet szóba. Hogyan célszerű ezt távolról csinálni. Mint látható, ez a boot disk.

Szerk:
Many thanks az építő jellegű és kevésbé építő jellegű hozzászólásokért. Az Ő lelki békéjük megnyugtatása miatt ezúton kérem Trey-t, hogy tegye át "Linux-kezdő"-be az egészet :). Külön köszönet Zs-nek a bibliáért.

Be kell látnom, a nagy sietség közepette kicsit hiányosan fogalmaztam. Tudom hogyan kell megcsinálni, sok évvel ezelőtt csináltam is, csak abban bíztam, hogy azóta az fdisk-et már kiváltotta valami okosság. Úgy néz ki marad a tömjén meg az áldozati kecske.

Szerk2:
A tömjén és az áldozati kecske kiegészítve némi sámán dobbal és Mekka felé fordulással meghozta a gyümölcsét.

Ez volt:
Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 2048 499711 497664 243M 83 Linux
/dev/sdb2 501758 3906246655 3905744898 1,8T 5 Extended
/dev/sdb5 501760 3906246655 3905744896 1,8T 8e Linux LVM

Ez lett:
Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 2048 499711 497664 243M 83 Linux
/dev/sdb2 499712 3906248703 3905748992 1,8T 5 Extended
/dev/sdb5 501760 3700000000 3699498241 1,7T 8e Linux LVM
/dev/sdb6 3700002816 3906248703 206245888 98,4G 83 Linux

Volt némi para, mert az fdisk csak úgy engedte ugyanazt a startszektort beállítani sdb5-re, ha az extended partíciót is töröltem és újra létrehoztam. Viszont így az extended startszektora nem egyezik, de úgy néz ki ez nem lényeg.
Mivel mindenképpen meg kellet csinálni a para ellenére a csodának is adtam egy esélyt és bejött.

Szerk3:
Most vettem észre, hogy én is át tudom rakni másik témába. Most már a méltó helyén, a "Linux kezdő"-ben van. :-)

  • 3434 megtekintés

( Hevi v | 2016. 05. 04., sze – 15:34 )

"Hogyan" adjunk semmitmondo cimet a topicnak?

Egyetértek. Miért nem tett egy egyszerű kérdőjelet a címbe? Meg ez mióta "naplózó filerendszer" kategória? Sokkal inkább "Linux kezdő".
Már Bocsánat.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

( zeller | 2016. 05. 04., sze – 15:36 )

Azaz az aktív vg alatt kéne megkurtítani a partíciót? IP-konzol/ILO/DRAC/értelmes ember, aki oda tud menni a konzolhoz és telefonon távirányítható van? Csak ha valami nem úgy sülne el, ahogy szeretnéd...

( locsemege v | 2016. 05. 04., sze – 15:56 )

Szerintem resize2fs kicsire, lvresize megfelelőre, resize2fs akkorára, hogy beletáguljon az lv-be, aztán pvresize, utána fdisk, ezzel a partíció végét átírni, majd létrehozni a kívánt új partíciót.

Mondjuk számolni nagyon kell hozzá, tévedni nem kellene, ideértve azt is, hogy figyelni kell a PE méretére is.

Nem megoldhatatlan szerintem, csak ha megremeg az ujjad, akkor bajba kerülsz.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( dap | 2016. 05. 04., sze – 15:58 )

Ami kell:

  • lvresize -r (system-data -hoz)
  • pvmove (attól függ)
  • pvresize
  • fdisk

    • Az elv, hogy az első 3 eszközzel felszabadítod az sdb5 végén a szabad helyet, majd lecsapod az sdb5-ot és a szabad helyre megcsinálod az sdb6-ot. Az /mnt/backup-home -ot umount-olni kell, a többi mehet online.

    Reboot előtt tömjénezz vastagon és mutass be egy áldozati kecskét az IT istenének, másképp nem sok esélyed van. :)

    ( pepo v | 2016. 05. 04., sze – 16:01 )

    Workaround:
    Ha a rebootra van lehetőség, akkor ideiglenesen valamelyik sdb partícióra csinálj egy vg--system-system partíciónak megfelelő fájlrendszert, másolj át mindent a jelenlegi vg--system-system, írd át megfelelően a grubot. Rebootolj. Csináld meg az sdb6-ot és a vg--system-system. És aztán másolj vissza mindent az új-új vg--system-system-re, a grubot konfigold. Reboot, és az sdbX, amit átvariáltál, tedd rendbe.
    Amúgy helyileg jobban járnál.

    ( Zs | 2016. 05. 04., sze – 23:47 )

    Tudom, hogy oftopic, troll, oltás és miegyéb, de...
    - ha értesz hozzá, akkor ne azt kérdezd, hogy hogyan, hanem vázold fel hogy miként oldanád meg és a kérdés az legyen, hogy jó-e az elgondolás és hogy mire kell vigyázni
    - ha nem értesz hozzá, akkor viszont ez az esernyő és védőháló nélküli kötéltánc esete 100 méteres magasságban az informatikára alkalmazva, ahol is a legsegítőkészebb javaslat az, hogy ne csináld

    De hogy ontopic is legyek, az én "megvalósítási tervem" a következő lépésekből állna, nagy vonalakban:
    - vg-system-data kötet kicsatol
    - a kötet kap egy fsck-t, -f kapcsolóval - az fsck-nak futnia *kell*
    - a kötet megkapja a resize2fs műveletet is, így a kötet végén lévő terület felszabadul. Én itt nagyvonalúan 120GB-t szabadítanék fel. (Az fsck-t meg azért kellet erőltetni, mert a resize2fs csak akkor hajlandó csökkenteni az fs méretét, ha tuti hibátlan - ez valahol jogos óhaj.)
    - most már a vg-system-data kötet mérete is csökkenthető - itt én udvariasan az lvresize -L -110GB opciót használnám, ezzel a kötetet csak 110GB-vel csökkenteném
    - jöhet egy újabb resize2fs, immáron méret paraméter nélkül: ekkor az a 10GB difi, ami a korábbi resize2fs majd az azt követő lvresize között van, visszakerül az fs-hez. Ez a produkció azért van, mert ha nem sikerül precízen-pontosan kiszámolni, hogy mit mennyire kell összehúzni, akkor itt tuti nem tévedünk rosszul, mert az fs-t atombiztosan jobban összehúztuk, mint utána az LVM kötetet, így olyan eset garantáltan nem állhat elő, hogy az fs utolsó pár szektora már az lvm kötet vége után van. A nagyvonalúságot pedig ebben a lépésben korrigáljuk: a nagyvonalúan nagyobbra hagyott kötet utolsó, kihasználatlan területe így visszatér az fs-be. (Lehet a 10GB-nél kevésbé nagyvonalúnak is lenni! :-D)
    - a fentebbi produkció eredményeképp a pv alatt már tuti van szabad hely, tehát most a pvresize művelettel - ismétcsak nagyvonalúan - 105GB-vel csökkentjük a PV méretét. Ezzel a lépéssel immáron a sdb5 partíció végén szabadítunk fel területet
    - a winyó átparticionálása már kicsit meredekebb művelet. fdisk esetén az sdb5 törölhető, majd ismét létrehozható. Amire veszettül figyelni kell: a partíciónak precízen pontosan bitre ugyanott kell kezdődnie, ahol eredetileg is kezdődött - ennek az elnyesése egy erősen bootolhatatlan rendszert fog eredményezni! A méretnél udvariasan 100GB-tal kevesebbet írjunk be - majd a winyón így szabadon maradt 100GB-t rendeljük hozzá egy új partícióhoz, ez lesz az sdb6. Ezen a ponton egy reboot következik, hogy a kernel észlelje a partíció kiosztás megváltozását. Elméletileg van valamilyen misztikus művelet, amellyel ez on-the-fly kierőltethető - én jobb szeretem ilyen esetben látni a teljes boot folyamatot is. Lábjegyzet: gdisk esetén a reboot nem szükséges, a gdisk ismeri az emlegetett misztikus trükköt - de akkor is tisztább ügy a reboot. Viszont! A gdisk használata esetén nem tudom, van-e lehetőség az átméretezésre, de a törlés + újralétrehozás nem biztos, hogy sikeres lesz: a gdisk sok mindent elrejt a szemünk elől! Itt tehát van egy szép, méretes lyuk az elgondolásban - úgyhogy első lépésként azt kéne kideríteni, hogy a régi típusú partíciós táblád van, vagy már az új (GPT)? GPT esetén itt megáll a tudományom...
    - maradva az idealista feltételezésnél, hogy az fdisk használatával a particionálás megoldható és a reboot sikeres, ismét futhat egy pvresize, hogy az ismét csak nagyvonalúra hagyott terület kiosztásban az az 5GB, amivel többet húztunk össze, mint amennyit ténylegesen elvettünk, ismét visszakerüljön, mint a PV-n még használható terület
    - ha mindezek után nem akarunk egy árva bit tartalékot sem hagyni az LVM köteten, akkor a korábbiakban megspórolt 10GB-t is visszaadhatjuk a vg-system-data kötetnek: ez egy lvresize, majd resize2fs parancsunkba fog kerülni

    Tök jól leírtad, csak 2 észrevétel:

    1. Nem kell a resize2fs, használjátok az lvresize -r kapcsolót, kevesebb a matek: 

    
       -r, --resizefs
              Resize underlying filesystem together with the logical volume using fsadm(8).

    2. Feltételezed, hogy a system-data a partició (vg) végén van, de ez nem biztos, lehet hogy kell egy pvmove.

    Nem kell a resize2fs, használjátok az lvresize -r kapcsolót
    Mindig tanul újat az ember! :-) Kevesebb parancs és kevesebb matek --> kevesebb hiba lehetőség. Jegyeztem.

    Feltételezed, hogy a system-data a partició (vg) végén van
    A teljes winyón két partíció van: egy minimális boot, illetve egy extended, amiben a winyó teljes kapacitása ott van. Túl sok variáció nincs: a /boot vagy az eleje, vagy a vége - slussz! Viszont a /boot az, amit a klasszikusok miatt lehetőleg mindig a winyó elejére tesz az ember, partícióként is ez van létre hozva elsőként. Tehát amit írsz, az egy olyan elméleti lehetőség, amely gyakorlatban ugyan megvalósítható, de ha nincs valami ritka különös kényszer, ami miatt mégis így kell csinálni, akkor tekinthetjük ezt egy megfigyelhetetlenül alacsony valószínűségű eseménynek. :-)
    A másik fele a dolognak: a feladat kiírásból nekem az jött le, hogy ezt a produkciót a helyi winyón, további háttértárak bevonása nélkül kell megoldani. A pvmove esetén kell egy másik háttértár, amire az egész lvm átrámolásra kerül. Ha pvmove kell, akkor sebességben is egy lényegesen rosszabb megoldást kapunk: mindent el kell hurcibálni a winyóról, majd mindent illene vissza is tenni. 1.8TB adat esetén azért ez már nem két pillanat, pár lvresize, pvresize eltörpül emellett. Szerintem...

    A korábbi gondolatsorhoz pedig - MBR vagy GPT - azt tenném hozzá, hogy GPT esetén a partíció számozás folytonos, tehát a 2. és 5. partíció között nincsenek lyukak. Itt van. Ez viszont az MBR esetre jellemző, mert ott van a 4 elsődleges partíció, ha pedig ez nem elég, akkor az egyik elsődleges partíció kialakítható extended partíciónak és abban már tetszőleges számú további partíció hozható létre - viszont azok emiatt mindenképpen az 5-ös sorszámtól indulnak.

    A csökkentendő VG-n lévő LV extent-ek elhelyezkedése a kérdés: ha a data -t előbb hozta létre mint a system-et vagy korábban tartott fenn szabad helyet a VG-ben majd a system -et kiterjesztette rá, akkor a system LV (néhány extentje) a VG végén lesz. Ebben az esetben pedig a pvresize-os csökkentés nem fog menni, a pvresize hibával elszáll.

    Ekkor kell a pvmove, hogy VG-n belül előre mozgassa az extent-eket, pl így (man 8 pvmove): 

    pvmove --alloc anywhere /dev/sdb1:1000-1999 /dev/sdb1:0-999

    +1
    Tényleg tökéletes leírás. Némi pontosítás, és szerkesztgetés után (csak hogy megfeleljen a wikik elvárásainak) mehetne is a *wikire.
    Szóval gratula.

    ---------------------------------------------------------------
    Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

    ( locsemege v | 2016. 05. 05., cs – 13:29 )

    Ha sdb2 létrehozását nem ráhagytad volna az fdisk-re, hanem manuálisan a régi szektorcímet adtad volna meg, ugyanott lenne, mint korábban. Persze feltéve, hogy az fdisk hagyja. Lehet, hogy nyafogni fog, hogy nem cilinder határra esik a partíció, de manapság LBA címzésnél ennek semmi jelentősége.

    Amúgy azért nincs belőle bajod, mert sdb1 maradt a helyén, régen itt volt egy pici hézag, s onnan kezdődött az extended sdb2 container, most viszont rögtön sdb1 után. Az extended container-en belül viszont az sdb5 ugyanott kezdődik, mint régen, s ez a lényeg. Aztán meg jön az sdb6, ami egy EBR-be jegyzett logikai drive.

    tr '[:lower:]' '[:upper:]' <<<locsemege
    LOCSEMEGE