Kolmas osio: ~30GB EXT4 liitospisteellä "/home"
Konvertointia en ole kokeillut.
Konvertoin juuri data osion ext4:n, meni oikein hienosti.
Nyt pitäisi miettiä /boot konversiota, mutta kaikesta lukemastani päätellen taidan jättää sen tekemättä. Ei jaksa enää näin vanhana propellihattuna kaivaa verta nenästä ihan tahallaan.
ext4:ään vaihtaminen vaatii grubin päivittämisen käsin
Jos aiot päivittää ”/”- tai ”/boot”-tiedostojärjestelmäsi ext2:sta tai ext3:sta ext4:ään säilyttäen tiedot (kuten dokumentoitu ext4-wikissä), sinun täytyy myös käyttää ”grub-install”-komentoa Ubuntu 9.04:ään päivittämisen jälkeen asentaaksesi käynnistyslataimen uudelleen. Jos et tee tätä, käynnistyssektorille asennettu GRUB-versio ei osaa lukea ydintä ext4-tiedostojärjestelmästä ja järjestelmä ei käynnisty.
Tuo kyllä viittaa siihen että grubin päivittämisen jälkeen pitäisi toimia. Voisin oikeastaan ensin päivittää grubin ja sitten miettiä vielä asiaa.
Toinen ongelma joka tuli vastaan on se, että taas kerran nopeasti polttava cd-asema on tehnyt sellaista sutta, ettei tämän koneen asema lue levyä. Eli kun ei ole vara-bootti levyä jauntylle, en taida uskaltaa ruveta sössimään. Eikä / konversiota varmaan pysty tekemään mounttaamatta ja todnäk umount / ei taida toimia. (Joku viisaampi voisi valaista miten homma hoidetaan), jos ylipäätänsä on mahdollista.
Toisekseen oli mahdollista käytää ext4 "modea" ilman extents tilaa, jolloin monet ext4 ominaisuudet ovat käytössä, ilman extents tukea. Tuon voi käsittääkseni muuttaa suoraan mount-optioista käyttöön. (taas kerran mutua lukemani perusteella, vailla oikeaa tietoa).
*** jatkuu *** ext4 boot käytössä ja kone käynnissä ***
Poltin Ubuntu levyn uudelleen koneen omalla polttimella ja se toimi. Koska olin tehnyt jo GRUB-päivityksen aikaisemmin. Oli CD:ltä bootin jälkeen aika helppoa tehdä ext4 päivitys myös /dev/sda1 devicelle. Kaikki levyt siis hodettu migraation / konvertoinnin, eikä uudelleen formatoinnin kautta.
Kaikista negatiivisista odotuksistani huolimatta, kaikki toimii kuten pitää kun vaan luki ohjeet ja seurasi niitä.
Nyt siis levyn kirjanpito ja ajurit on ext4 ajassa. Ainoa ongelma on se, että levyllä jo oleva data EI ole ext4-ajassa. e4defrag sovelluksen pitäisi hoitaa tuo asia kuntoon. En kuitenkaan löydä sitä synapticista. Eli ilmeisesti sen osalta ei ole vielä valmista?
Pitänee tarrata fileet poistaa ne ja purkaa takaisin. Öh, legacy defrag-menetelmä, heh. Mutta tuon operaation pitäisi siis hyödyntää datalle uutta allokaattoria.
e4tools ja e4defrag paketteja odotellessa.
Kiroilen kyllä jos jotain menee metsään, mutta tähän asti kaikki näyttää oikein hyvältä.
*** Datan katoilusta ***http://www.h-online.com/open/Ext4-data-loss-explanations-and-workarounds--/news/112892Menee juuri niin kuin odotinkin sen menevän. Kyseessä ei siis ole missään nimessä vika. Jos se olisi vika, voisi koko tiedostojärjestelmä räjähtää käsiin. Nyt vain osa datasta jäi puuttumaan.
Levyjärjestelmän korruptoituminen ei tarkoita sitä että pari viimeistä "kirjoitusta" katoaa, kuten raporteissa. Vaan sitä että kokonaiset hakemistorakenteet sekoaa, tiedostojen ja hakemistojen sisällöt on sekaisin jne. Tietokannoissa tuota tapahtuu silloin kun tietokannan kirjanpitotiedot sekoaa ja indeksit sekoaa. UUdelleen indeksointi voi toimia, mutta silloinkin menetetään joskus dataa jos myös tietokannan sisältö on korruptoitunut. Kyllä, tuota tapahtuu aina ajoittain. Silloin seuraava askel onkin se, että kuinka hyvä korjausrutiini tuolle on kehitetty. Tyyliin fat levyjen cross linking fix.
Miksi käytetään upseja, miksi järjestelmät kahdennetaan, miksi softissa on omat logit joiden pohjalta tehdään vielä data rollback jos jotain on kesken? Miksi järjestelmät toimivat rinnakkain koneissa joiden tulosten pitää olla samat?
alloc_on_commit optio "korjaa" tuon "ongelman". Koska molemmat ovat suhteellisia asiota. Henkilökohtaisesti vihaan em. toiminnallisuutta. Meillä tuotantojärjestelmät käsittlee esim valtavia määrtiä suhteellisen pieniä XML aineistoja. Jos käytetään alloc_on_committia, putoaa järjestelmän nopeus tuhannesosaan siitä mitä se on ilman tuota optiota. Koska nyt esimerkiksi 1000 luotua tiedostoa voidaan järjestää levylle muutamalla kirjoituksella, sen sijaan että kirjoiteaan levylle esim 8000 kertaa.
*** Ihan muuta horinaa ***Joo, paljon pikkutiedostoja on hölmöä. Se on vielä hölmömpää FTP:n kanssa. Mutta minkäs voit, näin on joskus järjestelmä suunniteltu. Tietysti voisi korvata tuon FTP palvelimen "virtuaali ftp:llä" jossa data "tiedostot" luodaan lennossa tietokannan perusteela silloin kun niitä noudetaan. Mutta kovin on työläs vaihtoehto tuo.
Vielä parempi olisi jos kaikki integraatiot jotka käyttävät tuota teidonsiirtorajapintaa konvertoitaisiin käyttmään jotain uutta järkevämpää protokollaa. Joka siirtäisi datan esim 20-50 megan paloissa ja yhden TCP session kautta. Mutta vaatisi standardin FTP:n korvaamisen omalla softalla. Kun integraatioita on useille eri alustoille, sekään ei ole kovin järkevä vaihtoehto. Koska nykyinenkin ratkaisu toimii ja protokollan uusiminen maksaisi kymmeniätuhansia.
