Partíció átméretezése adatvesztés nélkül

"nem tudom átmásolni máshová ideiglenesen."

Ha nincs most mentés, akkor ne bíbelődj vele, simán töröld le: úgysem volt igazán fontos adat...

Üdv,
Marci

... vagy nagyon kockázatos lenne?

Igen, én már szoptam be ezt _egyszer_ kiskoromban.

Mekkora a feltöltési sávszélességed és mennyi az adat? Lehet, megérné felhőbe menteni, legalább ideiglenesen.

Üdv,
Marci

Gondold végig, amit írtál. Nem akarsz adatvesztést, de nincs mentésed. Ez akkor is kockázatos, ha nem babrálsz a partíciókkal, csak sima üzem van! Készíts mentést, ha valóban fontos az az adattömeg és utána a kérdésed okafogyottá válik.

Gparted live-cd vel gond nelkul meg lehet csinalni, par napja csinaltam hasonlot (noveltem egy particio meretet) de ez egy VM volt, elotte ment a Snapshot... Enelkul en nem mernek...

Mondjuk az egy lényeges információ lenne, hogy milyen fájlrendszerről van szó és hogyan néz ki a partíciók kiosztása, van-e LVM, stb.

♲♻♲

Mentés nélkül felelőtlenség lenne bármilyen megoldást javasolni és arra biztatni!
Szünetmentes áramforrás legalább van?
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Célszerű átgondolni, hogy a feladat milyen lépésekből is áll. Egy kötet méretét megnövelni annyira nem kunszt: a végére taknyolunk némi helyet, szólunk az fs-nek, hogy hogy "hé te! tuggyál róla, hogy nagyobb vagy, mint gondútad", oszt jól van.
No, amikor helyet szeretnénk kinyerni a fájlrendszerből, akkor azért hirtelen macerásabb lesz a dolog: a szabad hely ugyanis össze-vissza elosztva helyezkedik el a fájlrendszerben, olyat viszont nem igazán tudunk csinálni, hogy kiscsillió helyről veszünk el kisebb-nagyobb területet. Ehhez a produkcióhoz tehát a legelső lépés, hogy át kell rámolni a mappákat, állományokat, hogy a szabad hely a kötet végén jelenjen meg. Ilyen akciót viszont nem konzisztens rendszeren erősen ellenjavallt elkövetni, az ön-tökön-szúrás kellemetlen esete lenne ugyanis. ext[2-4]fs esetén tehát az első kanyar mindenképpen egy fsck, méghozzá /f kapcsolóval, hogy tuti ellenőrizzen is. Ilyesmit persze csatolt köteten nem illik elkövetni - RO csatolt köteten sem! Az mondjuk kisebb gáz - egész addig a pillanatig, amíg nem jön egy "okos" remount,rw - ami ugye a memóriát nem fogja kitakarítani! Jutalmul a korábbi állapotból cache-be került és az fsck által már rég átalakított dolgok hirtelen ismét érvényessé válnak a rendszer számára, csak hát ugye ez a korábbi, fsck előtti állapot. Ezzel azután igen alaposan össze lehet barmolni a fájlrendszert... A dolog persze fokozható, hogy a kérdéses partíció legyen a rootfs - amelynek a nem becsatolása már eleve egy kényes produkció... Persze, lehet. Mindent lehet - radarszkóppal hegyet mászni is, bár erről Pirx is gyorsan le lett beszélve: bonyolult módja az öngyilkosságnak. Ezzel együtt aki érzi magában a késztetést és nem tud ellenállni a kihívásnak, továbbá a folyékony héliummal hűtött csapágyú szopórollert is jól kezeli csutkára húzott gázkar mellett, az játszhat olyat, hogy az init paraméterben "elrontja" a rootfs-t tartalmazó hivatkozást, így emergency promptot nyer az initrd-n - és ekkor még nincs csatolva a rootfs! Tehát a rootfs kézi csatolása után a szükséges binárisok kimásolhatóak az initrd-re, majd a rootfs kicsatolása után mehet a produkció! ... persze az initrd filerendszere is lehet olyasmi, hogy squasfs - azaz csak olvasható. A rutinosabbja tehát lendületből csatol tmpfs-t a /tmp alá és máris van írható, egyszer használatos könyvtára...
De térjünk vissza az ilyen extrém kihívásoktól mentesebb útra és folytassuk onnan, hogy a fájlrendszer tuti konzisztens. Jöhet a következő produkció: resizefs. Ha a méretet növelni akarnánk, akkor on-the-fly, csatolt kötet mellett mehetne ez is - így erről szó sincs, kicsatolt köteten kezd el mókolni a resizefs - és elvégzi az állományok, mappák áthelyezését, hogy az üres területet a fájlrendszer végére tegye, majd karbantartsa magának a fájlrendszernek az adatait, kezdve azon, hogy az fs mérete már egy kisebb érték. Ha ezen művelet közben mondjuk áramszünet következik be, az jó eséllyel gondoskodni fog arról, hogy az adatok egy részétől örök búcsút vegyünk - ráadásul a futási idő is nagyban függ attól, hogy mennyi adatot kell mozgatnunk.
Amikor az fs-t már sikerült kisebbre igazítani, jöhet az utolsó lépés: a partíció csökkentése. Itt ideális esetben a particionáló program ténylegesen csak a partíció bejegyzést módosítja - sajnos futottam már lyukra olyannal, hogy az okos particionáló program magába a partícióba is belebarmolt. Igaz, ott a resize mint törlés + új létrehozás lett elkövetve, start paraméterként az eredeti kezdő pozíciót megadva, de a dolgok jellegéből adódóan a pakliban ez is benne van: a sikeresen összehúzott fs-t a particionáló program rúgja oldalba. :-|

Mindezt átgondolva a feladat ugyan nem lehetetlen, de mentés, illetve szabad hely nélkül nem kicsit kockázatos. Ugyanakkor az eredeti peremfeltételek nem ismertek - tehát tisztán elméletileg az is egy opció, hogy dd segítségével gyártunk egy akkora imagefile-t, amekkorát akarunk, a losetup segítségével az image file-t loop eszközhöz rendeljük és innen kezdve van egy (mondjuk) /dev/loop0 eszközünk, amely pont az image file méretével egyezik meg. (Itt persze ajánlott no-write-cache attribútumot tenni az image file-ra, mert ha pl. naplózó filerendszert teszünk rá, akkor az jó, hogy a naplót a rendszer rögtön kiírja, csak nem lenne haszontalan, ha ez az írás az image file-ba is rögtön megtörténne, ellenkező esetben annyit ér a napló, mint lakat a vászontarisznyán.)