Naív kérdések az életből merítve

 ( bzs | 2012. május 7., hétfő - 8:34 )

Sziasztok.

1-2 olyan kérdésem lenne, amely szerintem Nagykönyvben nem nagyon leledzik, inkább a tapasztaltabb elmékben.

1.
Áramszünet esetén elszállhat-e ext2 vagy ext3 fájlrendszer oly módon, hogy csupán bizonyos könyvtárak fájljai olvashatatlanokká válnak, a többi sértetlen marad?

2.
Hogyan lehet megoldani azt, hogy bár írható merevlemezen van a teljes rendszer, mégse használja írásra csak akkor, ha akarom?
(Konkrétan a /home/user ramdrájvra "kitarozva" fut a /tmp szintén, a /var ramdrájvosítását nem merem megtenni, pedig állítólag lehetne. Van még valami könyvtár, amire írna a linux bootolás közben vagy után?)

3.
Ha valaki nagy nehezen megtanult fordítgatni, itt-ott még 1-2 programba bele is tud kontárkodni, helyes-e az a meglátás, hogy bizonyos kernelhez forgatott gcc-vel forgatva a programokat jobb eredmény érhető el, mint más kernelhez forgatott gcc-vel? (Érdemes-e megrögzöttként ráállni arra, hogy MINDENT magunk fordítsunk?)

4.
Létezik-e olyan filerendszer, amely a squashfs-től eltérően írható is?

5.
Ha van egy /usr/include és egy /usr/src könyvtáram külső vinyón, az oda leforgatott programok make installozhatók-e más kernelű linuxokra, vagy olyankor ki kell ürítenem és újrafordítanom mindent (utóbbira gyanaxom)

6.
Mikor érdemes kernelt fordítani (féltem a .configomat, nagy kín volt megtanulni, így minden új kernelt fordítottam eddig a régi configommal..) Valóban "csak" a páros végződésűek a "jók"?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

1. Legjobb tudomasom szerint: minden esetben igaz, hogy azok a fileok serulhetnek, amik eppen nyitva vannak es irnak bele. Tehat ha egy adott pillanatban egy adott konyvtarban vannak csak nyitva ilyen modon fileok, akkor igen, serulhetnek. Ezen felul az ext2 eseten, mivel nem journaling filerendszer, elofordulhat az, hogy egy adott konyvtar inodeja szemetre mutat. (fixme) Errol a temarol van egy egesz jo leiras itt.

2. Linux disztribucionkent valtozik, hogy hova szeretne irogatni. /tmp, /var/run biztosan, ezen felul van meg egy par dolog. Ezt ki lehet deriteni, ha read onlyban mountolod fel a disket (virtualis gepben persze) es megnezed, mire sipitozik.

3. A sajat forgatas hozthat sebessegbeli elonyoket, de ez gyakorlatban nem lesz tobb, mint 1-2%. Ennel sokkal fontosabb a karbantarthatosag, mivel a szoftvereket rendszeresen kell frissiteni is.

4. Allitolag letezik de hogy mennyire kiforrott, az egy masik kerdes.

5. Alapvetoen a forditott binarisok mukodokepesek lesznek mas kernelu linuxokon, ha a libek megvannak a megfelelo helyeken. A /usr/include-ban levo header fileok csak a forgatashoz kellenek, a futtatashoz nem.

6. Alapvetoen a security fixeket mindenkeppen erdemes beleforgatni a kerneledbe. Amikor megszunik a supportja egy adott kernelnek, akkor nyilvan arrol erdemes lemigralni. Ezt a kernel.org-on az EOL felirat jelzi.

Szia!

Az én válaszaim az alábbiak:

1. Igen. Az ext2 nem naplóz, itt nagyobb az esélye az adatvesztésnek. Az ext3 (és ext4) naplózó fájlrendszer, ezeknél jóval kisebb az esélye annak, hogy áramszünet esetén adatvesztés történik. Mindenesetre szerintem 2012-ben alapelvárás, hogy legyen szünetmentes táp mindenhol, vélhetően ez tudja a leginkább csökkenteni az adatvesztés kockázatát. :)

2. Ha írásra akarod felmountolni a fájlrendszert, akkor:

mount -o remount,rw /fajlrendszer-neve

Ha pedig read-only módban szeretnéd használni, akkor:

mount -o remount,ro /fajlrendszer-neve

Mindkét parancs kiadható futó rendszeren, nem okoz adatvesztést - bár igazából nem tudom, mi történik, ha megnyitsz egy fájlt írásra, majd utána read-only módba újramount-olod a fájlrendszert. Valószínű, hogy az írásra megnyitott fájlra rá tudsz még menteni, de az újonnan megnyitott fájlok már írásvédettek lesznek.

3. Szerintem nem. Már rég leáldozott az a korszak, amikor saját magunk által fordított kernelt kellett használni, a legtöbb disztróban az általános felhasználási területeknek tökéletesen megfelelő csomagolt kernelek vannak. Az én meglátásom az, hogy forrásból csak akkor fordítunk bármit is, ha nincs kellően friss és stabil csomagolt változat. Nem szabad elfelejteni, hogy a forrásból kifordított programok nem frissülnek automatikusan, ha viszont repóból telepítesz, akkor számíthatsz rá, hogy a csomag időről-időre frissülni fog (ez leginkább a biztonsági frissítések miatt fontos).

Félreértés ne essék, bizonyos esetekben (pl. embedded eszközöknél, ahol kevés a memória és a háttértár) szükség lehet kézi fordítású kernelt használni, de feltételezem, hogy te sima desktop környezetben használsz Linuxot (vagy valami UNIX-alapú oprendszert), és a kérdéseid is erre a felhasználási területre vonatkoznak.

4. Nem teljesen értem ezt a kérdést. Számtalan írható fájlrendszer létezik, sőt, a legtöbb fájlrendszer írható, pl. ext2, ext3, ext4, ntfs, fat, exfat, reiserfs stb.

5. Ez szoftverfüggő. Ha a szoftver használ valamilyen kernelmodult vagy bármi módon függ az aktuális kernelverziótól, akkor igen. Egyébként a függőségek (pl. libc, libgtk, libakármi) és az architektúra (x86/x64) határozza meg leginkább, hogy a program el fog-e indulni más rendszereken újrafordítás nélkül.

6. Erre sajnos nem tudok okosan válaszolni, évek óta nem fordítottam kernelt, és nincs sok tapasztalatom a kernelfordítással kapcsolatban. Ahogy fentebb is írtam, a legtöbb csomagolt kernel megfelel a legtöbb esetben, sok disztróban alapból vannak különféle feladatokra kihegyezett kernelek (desktop, server, virtual host, médiaszerver stb).

A fentieket az elmúlt 5-6 év tapasztalatai alapján írtam. Egyáltalán nem vagyok öreg motoros a szakmában, de szeretem a Linuxot, és napi szinten használom is. Nyilván lesznek majd több évtizede Linuxszal foglalkozó hozzászólók is, akik mondanak majd okos dolgokat, és rácáfolnak az általam leírtakra... :)

1. Elszállhat. Védekezni ellene a file rendszer naplózási szintjének (journal) emelésével tudsz (de a merevlemezekben lévő írási/olvasási cache miatt sose lesz 100%-os). Lásd: http://www.ibm.com/developerworks/linux/library/l-fs8/index.html#4 , http://linux.die.net/man/8/tune2fs . (Ezek ext esetén évenyesek. Reiser esetén nem tudom, hogy van, mivel nem használom.)

2. Külön partícióra rakod a rendszert a változó adatoktól (utóbbi kategória általában a /home, /var, /tmp csomagból szokott állni. A rendszer partíciódat az /etc/fstabban csak olvashatóra csatlakoztatod. Mielőtt módosítasz, kézzel újra csatlakoztatod írhatóra. Ha végeztél a rendszer módosításával, újracsatlakoztatod csak olvashatóra. Lásd: http://linux.die.net/man/5/fstab , http://linux.die.net/man/8/mount (ezek az előző kérdésedhez is jól jöhetnek). A /var ramdrivera tételét nem erőltetném, mivel ott kikapcsoláskor is megörzendő változó adatok is vannak (Kiemelten a rendszernaplók, boot napló, a nyomtatási sorok. Egyes rendszerek a leveleket is ott tárolják, vagy néhány esetben a publikus adat szolgáltatások, mint pl.: http és ftp dolgai is ott vannak.). A /tmp -re használd kitarozás helyett a tmpfs-t (http://en.wikipedia.org/wiki/Tmpfs), már csak azért is, mert újra induláskor onnan semmi nem kell. A home ki-be tömörítgetésében sem látok túl sok hasznot. Lemez területet nem tudsz annyit spórolni, cserébe viszont rengeteg emóriát elpazarolsz (ami jóval drágább). Ráadásul napi használat mellett elég keményen el tud hízni a home, mivel mindenki minden adatát ott tárolja (a desktop gépemen jelenleg 20GB-ot használok fel a saját könyvtáramban).

3. A gcc működése "független" kerneltől. Ha saját gcc-t fordítasz, akkor azért lehet némileg gyorsabb, mert igazodik a konkrét gépedhez (cpu-hoz), kihasználja a processzor összes képességét. Szerintem erősen elméleti jellegű a kérédés, nem éri meg a befektetett időt. Ettől független ez ügyben konzultálj a Gentoosokkal (http://www.gentoo.org/), vegül is az egész disztribúciójuk erre az ötletre épül fel.

4. Nem vagyok benne biztos, hogy jól értem a kérdésedet. Ha olyan megoldásra vágysz, hogy tömörítetten (esetleg titkosítottan) tud kezelni egy fájlrendszert, akkor a loop divece-ok szolgáltatása megfelelő lehet neked. Induláshoz lásd: http://en.wikipedia.org/wiki/Loop_device . Ez alapján el tudod dönteni, hogy erre gondoltál-e. Esetleg a 2.-es kérdéshez kapcsolódva érdemes lehet ebben az irányban tapogatozni a ki-be csomagolgatás helyett.

5. Egy megjegyzéssel indítanék: ha saját komponenseket készítész, amit te forgatsz, vagy a disztribúció nem szállít, azt mindig az /usr/local/... struktúrába rakd (tehát az /usr/local/bin a programok, az /usr/local/lib a könyvtárak, az /usr/local/src a források, az /usr/local/incude a fejléc állományok, stb... helye).
A kérdésedre vonatkozólag: a felhasználói programok a kerneltől jellemzően nem függenek, cserébe függnek a rendszeren található könyvtáraktól és függhetnek egyéb szolgáltatásokat biztosító rendszer komponensektől. Ennek megfelelően a bináris átvitel a különböző rendszerek között mindig rejt veszélyeket. A siker leginkább attól függ hogy a két rendszer emnnyire hasonló, és a konkrét pogramnak milyen függőségei vannak. Szamárvezetőnek érdemes lehet azt használni, hogy az azonos architektúrájú és azonos disztribúciók telepítései között nyugodtan megteheted, minden más esetben újra forgatod.

6. Amikor szükségét érzed :). Minden más esetben teljesen felesleges (egyébként sok disztribúció tárolójában lehet találni különféle előrefordított kerneleket a különböző felhasználási módozatokhoz). A kernel configodat viszont nem feltétlenül kell annyira féltened. Ha engedélyezték fordításkor (általában szokták), akkor az éppen futó kerneled konfigurációját tömörítve megtalálod a /proc/config.gz fájlban. A verzió számozás esetén régebben a második szám páros vagy páratlan állapota jelezte, hogy fejlesztői vagy stabil verzió-e. A 3.0-ás verziótól visont átálltak egy másik modellre, így ott ez már nem érvényes. Wikipédián jól le van írva: http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering .

Zavard össze a világot: mosolyogj hétfőn.

4.-hoz, unionfs-sel szoktak megoldani a dolgot.