Nyugodtan kihagyhatod a bevezető mesét, és egyből a segédlethez ugorhatsz!

Amióta megvan a laptopom, dualbootos rendszert használok. A GRUB alapból a Linuxot tölti be, mindennapi munkám során ezt használom, de a másik partíción lévő Windows XP-től sem tudok szabadulni, néha mások kényszerítenek rá, legtöbbször viszont játék miatt indítom újra a rendszert. A két operációs rendszer közötti kapcsot a legnagyobb adatpartíció jelenti, az azon lévő fájlokat bármikor el kell tudjam érni. Ez a partíció NTFS fájlrendszert használ, hogy a Windowsnak a legkevesebb gondja legyen vele. Ez a felépítés tökéletesen működött is, amíg néhány hónapja súlyos teljesítménygondok nem akadtak Ubuntun.

Az adatpartíción tárolom a zenegyűjteményt, és a helyi webszerverek gyökérkönyvtára is ez. Ubuntu 10.10 alatt előjött egy olyan gond, hogy ha Bansheeval zenét hallgattam, és közben a helyi Apache szerveren akartam dolgozni, akkor egy-egy oldal betöltése 30-60 másodperceket is igénybe vett, miközben a zene akadozott. Gyakorlatilag gyorsabban tudtam fejleszteni a távoli szervereken, mint a saját gépemen. Ez pedig nem egészséges dolog, gyakorlatilag teljesen hazavágta a fejlesztési kedvem. A helyzetet még fokozta, hogy ha a Transmission torrentkliens az adatpartícióra töltött, akkor az egész rendszert 5-10 másodperces általános késleltetés sújtotta, gyakorlatilag fuldokolt a rendszer.

Minden jel arra mutatott, hogy az NTFS olvasással van a gubanc. A GNU/Linux rendszerekben az NTFS-3G program végzi el ezt a feladatot 2006 óta, ezt tudtam, mivel korábban Debian Etchben még kézzel kellett fordítani. Rákerestem tehát angolul, hogy miért is lehet az NTFS-3G lassú, talált is nekem a kereső egy GYIK-ot a Tuxera oldalán. (Ha ti sem tudtátok volna, akkor elárulom, hogy 2008-ban Szakacsits Szabolcs úgy döntött, hogy a nyílt forráskódú NTFS-3G köré egy céget szervez, és kereskedelmi terméket is kínál, ezt a céget nevezték el aztán 2009-ben Tuxerának.) A GYIK tartalmaz (többek között) egy olyan pontot, hogy a nagy töredezettségű lemezeken magas processzorhasználat léphet fel. Gondoltam ez lehet a gondom, mivel amióta megvan a gépem soha nem töredezettségmentesítettem az adatpartíciót. Azonban a tipp tartalmaz egy kitételt is: a fájlalapú töredezettségmentesítők általában nem oldják meg a problémát, viszont a fájlrendszer átméretezők, mint az NTFSRESIZE igen.

Így néz ki egy tökéletesen töredezettségmentesített partíció

Bíztam benne, hogy a kitétel téved, mert lusta voltam biztonsági másolatot készíteni a fontosabb fájlokról, mielőtt átméretezem a partíciót, ezért a Defraggler nevű programmal Windowsból megpróbáltam töredezettség mentesíteni az adatok lakhelyét. A horrorisztikus 53%-ról sikerült is 24%-ig ledolgozni, a Windows érezhetően repdesett a boldogságtól, de ez a lelkesedés nem ragadt át az Ubuntura. Nem maradt más hátra, mint a fontos fájlok áthelyezése, és a partíció átméretezés megkezdése.

Segédlet

Fontos! Az NTFSRESIZE erősen épít a Windows beépített CHKDSK programjára, ha nem áll rendelkezésre Windows, akkor ne kezdjünk bele a folyamatba! Habár az NTFSRESIZE meglehetősen óvatos az átméretezés során, a fontos adatainkról (vagy az egész partícióról) készítsünk biztonsági mentést!

Az NTFSRESIZE-ot használja többek között a GParted is, ezért a bátortalanabbak megpróbálhatják grafikus felületen átméretezni a partíciót. Tapasztalatom szerint a GParted viszont egyáltalán nem segítőkész ha hibát talál, ezért a konzolból fogjuk az NTFSRESIZE-ot használni. Nyissunk tehát egy konzolt (terminál). Először is legyünk tisztában, hogy melyik partíciónk milyen néven érhető el a rendszer számára. Írjuk be a következő parancsot: sudo fdisk -l. Ez a program kilistázza nekünk az egyes partíciók adatait, a blokkok száma és a rendszer információ alapján be tudjuk azonosítani azt a partíciót, ami nekünk kell. Az én esetemben a nagyobb NTFS partícióra lesz szükség, ami a /dev/sda4 alatt szerepel.

Adjuk ki ezután a sudo ntfsresize -i /dev/sda4 parancsot, amivel információt szerezhetünk a partícióról. Elképzelhető, hogy kapunk egy ERROR: Device ‘/dev/sda4′ is mounted read-write. You must ‘umount’ it first. hibaüzenetet, ekkor csatlakoztassuk le a meghajtót a rendszerben. A legegyszerűbb talán úgy, ha minden más programot bezárunk a terminálunk kivételével, majd beírjuk, hogy sudo umount -a ami leválasztja az összes nem használt partíciót, kivéve persze azt, amin a Linuxunk fut. Ha sikerült leválasztani a kérdéses partíciót, akkor essünk neki újra a sudo ntfsresize -i /dev/sda4 parancsnak.

Kaptam egy hibaüzenetet, ami azt mutatta, hogy jó nyomon járok! Az NTFS fájlrendszer inkonzisztens, ezt azonban az NTFSRESIZE nem tudja kijavítani, tanácsolja, hogy Windowson futtassuk az chkdsk /f parancsot, majd indítsuk újra kétszer a rendszert. Ráadásként megjegyzi, hogy ameddig ez nem történik meg, addig nem hajlandó változtatni a fájlrendszeren, nosza tegyük meg amit kér. Windowson is nagyjából hasonlóan működik a terminál, gépeljük be, hogy chkdsk /f d:

Ezek után vagy végrehajtja a kívánt feladatot a Windows, vagy közli velünk, hogy mivel a rendszer erről a partícióról fut, ezért most nem tudja leellenőrizni, de indítsuk újra, és a rendszer indulás előtt elvégzi a dolgát. Így is történik, az indulás előtt egy kék karbantartó képernyőn mutatja a vizsgálat menetét és a javításokat. Bármelyik módszerrel végez is, ellenőrizzük, hogy minden adatunk megvan-e, majd indítsuk újra. A második újraindítás után már nincs semmilyen változás, megvolt az NTFSRESIZE által kért kétszeri újraindítás, mehetünk vissza Linuxba, majd újra adjuk ki az sudo ntfsresize -i /dev/sda4 parancsot.

Most már sikeresen lefutott az ellenőrzés, és el is árulja nekünk a program a maximálisan felszabadítható terület méretét. Ez az én esetemben 6135 MB, ami nem egy óriási valami, de lehet hogy ez segít a rendszeren. Az NTFSRESIZE azt tanácsolja nekünk, hogy teszteljük ezt az értéket az -n és -s kapcsolókkal. Az -s kapcsoló határozza meg a méretet, az -n pedig azt jelenti no action, azaz nem hajt végre tulajdonképpeni változtatást, csak szimulál. Adjuk ki tehát a sudo ntfsresize -n -s 71948M /dev/sda4 parancsot (a számot cseréljük le arra, amit az előző futtatáskor kaptunk).

Meglepetésünkre kiírja, hogy mégsem képes ekkora helyet felszabadítani, próbáljunk egy picivel nagyobb méretet meghagyni a partícióból. Hívjuk meg megint a fenti parancsot, de növeljük az -s mögött álló számot sudo ntfsresize -n -s 76000M /dev/sda4.

A szimuláció sikeresen lefutott, tehát elég nagy lesz ez a méret, hogy biztonságosan átméretezze a partíciót, most már élesben is futtathatjuk a programot, vegyük ki a -n kapcsolót: sudo ntfsresize -s 76000M /dev/sda4

Minden teszt sikeresen lezajlott, de még utoljára figyelmeztet minket, hogy az adatok elveszhetnek. Mivel van biztonsági mentésünk, és egészen eddig szabályszerűen jártunk el, nyugodtan nyomjunk egy “y”-t.

Sikeresen átméreteztük a fájlrendszert! Ami a sok információból fontos nekünk, az az, hogy ellenőrzésre ütemezte a partíciót, tehát ha majd átmegyünk Windowsba, akkor rögtön a CHKDSK fogad majd minket. Ezen kívül még emlékeztet minket, hogy most csak a fájlrendszert zsugorítottuk, majd a partíciót is át kell, de mivel nekünk nem egy kisebb partíció a cél, hanem az adatok tömörítése, ezért ezt figyelmen kívül hagyhatjuk. Ha most elindítanánk az NTFSRESIZE-t, hogy visszaállítsuk eredeti méretére a fájlrendszert, akkor szólna a program, hogy a Windowsos CHKDSK ellenőrzést előbb le kell futtatni, tehát spóroljunk meg itt egy programindítást, és menjünk át Windowsba.

Miután a Windows újfent leellenőrizte a fájlrendszert, és mi újraindítottuk a gépet, majd megnyugodva láttuk, hogy minden rendben, akkor menjünk vissza Linuxba, és állítsuk vissza eredeti méretére a fájlrendszert. Ha lusták akarunk lenni, és MB-ban adjuk meg az eredeti méretet, akkor a kerekítés miatt hibaüzenetet kaphatunk, hogy a partíció nincs akkora, amekkorára mi a fájlrendszert méretezni szeretnénk:

Ezt elkerülendő, rendesen írjuk ki az összes számjegyet, és byteban adjuk meg az eredeti méretet. Az eredeti méretet a current device size sorban találjuk meg, ezt másoljuk bele a parancsunkba: sudo ntfsresize -s 78082583040 /dev/sda4

Így már sikeresen veszi az akadályt a program, biztonsági kérdésnél megint válaszoljunk az angol igennel, majd visszaméretezi a program a fájlrendszerünket. Nincs más hátra, mint két újabb Windows újraindítás. Amikor a hosszú munka után visszatértem az Ubuntuba és kipróbáltam a javított fájlrendszer teljesítményét, akkor örömmel nyugtáztam, hogy sikerült az akció, olyan a sebesség, amilyen korábban volt!

Még két villámtanácsot érdemes megfogadni. Az első, hogy az /etc/fstab állományban a csatolási paraméterek közé vegyük fel a noatime paramétert, ezt az NTFS-3G is támogatja. A másik pedig az, hogy a transmission beállítófájlban az előfoglalás (preallocation) értéke nem logikai (0 és 1), hanem egész szám, és 2-re állítva megkapjuk a régi működést, tehát hogy az egész fájlt lefoglalja előre, ezzel minimálisra csökkenti a töredezettséget.