[Megoldva]Squeeze USB aufs hogyan

 ( tovis | 2011. október 24., hétfő - 12:15 )

netinst segítségével feltelepítettem a Squeeze -t egy USB -re és működik (roppant lassú a boot de ez most nem kritikus). Viszont úgy gondolom/érzem, hogy bizonyos alapvető dolgokat át kellene konfigurálni, ahhoz hogy a rendszer "fölöslegesen" ne írogassa a pendrive flash -t. Például a logokat valahova el kellene "suvasztani". Viszont mivel ez egy fejlesztés alatt álló cucc a logokra nagy szükségem van.
Sosem csináltam, de mondjuk csinálok egy RAM diszket, és oda irányítanám át a logokat - a legegyszerűbbnek az tűnik ha a RAM diszket rá mountolom a /var/log könyvtárra (mondjuk előtte felmásolom az eredetileg ott lévő dolgokat. Ezzel csak az a gond, hogy azért időnként ki kellene másolni a logokat a flashre, ráadásul összeomlás esetén ez sajnos elvész - azaz (ésszerű) időnként mégis ki kellene mentenem. Tudtok valami hasznos "trükköt" erre?
Mi van még a logokon kívül amit a rendszer sűrűn "karbantart" azaz ír?
(SQL vagy más, nagy háttérkapacitást igénylő dolog itt nem lesz, csak azok a dolgok amit a rendszer igényel)
Lehet, hogy a mai memória gazdagság mellett érdemes az egészet rRAM -ból futtatni? Végül is nekem egy minimál Debian is elég (nincs X, de még a HTTP szerver is a busybox applet).

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ő.

Én most így hirtelen kapásból azt csinálnám, hogy ha ext4-es FS-el telepítetted, akkor a writeback időt átállítanám valami nagyra, meg noatime opció is kell, és akkor nem ír vissza minden olvasáskor. Az fstab-ban ilyen opciókkal mount-olnmám a root-ot:

rw,commit=600,noatime,errors=remount-ro

Hoppá! Ha jól értem, ez azt jelenti, hogy a Linux minden olvasáskor írja a fájl leírót (utolsó hozzáférés stb)? Ajjaj, ez eszembe sem jutott!
Akármit is "csak" olvasson a rendszer akkor is ír is egyben, a végrehajtandó programokat is beleértve!?
Akkor igazándiból nem látok más megoldást, mint RAM -ba tölteni az egészet, és onnan futtatni! Végül is egy minimál Squeeze is elfér 3-4 megán.

* Én egy indián vagyok. Minden indián hazudik.

noatime (no access time written) kapcsolóval nem írja, hanem csak olvasni fogja ténylegesen. Nyugodtan hagyjad csak pendrive-on ha beállítod ezt. Ugye ezzel csak annyi lesz a különbség, hogy a fájl rendszer nem valós dátumát fogja mutatni az utolsó hozzáférésnek, hanem a módosításét. De ez nem gond általában. Én csak így használom minden rendszeremet.

Utolsó hozzáférés jegyzését ki lehet kapcsolni, nem?

Szerk.: Megvan a válasz :)

Más okból ugyan, de belenéztem a mount man -ba és ott van a noatime opció - fájlrendszer független - és azt is írja hogy a kernelben is ki lehet kapcsolni!

* Én egy indián vagyok. Minden indián hazudik.

Nalam a tuzfalak es AP-k CompactFlash kartyarol mennek,
itt leirtam, hogy van megcsinalva. A log69 altal irt noatime opciot ugyan nem irtam, de jo dolog, en is hasznalom.

Na, végre visszatérhetek ehhez a vonalhoz.
Nézegetem az általad javasolt unionfs dolgot. Az igazság az, hogy alig értem mit is csinál a unionfs. A honlapjukon, a második link (Unionfs in examples -> unionfs.org) azt ecseteli, miért jobb az aufs mint a unionfs. Mi van?
Szóval ha tudsz erről valami (szerinted jó) cikketannak örülnék.

* Én egy indián vagyok. Minden indián hazudik.

Az unionfs.org csak a konkurenciat egeti, semmi koze az unionfs-hez.

Dokumentaciot a kernel forrasban talalsz: Documentation/filesystems/unionfs/

A kovetkezot szeretnenk: legyen egy teljes erteku Debianunk (apt-get mukodjon, stb) flash-en, de a leheto legkevesebbet irkaljon a "diszkre". Mivel (szinte) minden iras a /tmp-be es a /var alatti konyvtarakba tortenik, ezeket ramdiskre tesszuk. Hogy erdekesebb legyen, a teljes /var-t nem lehet torolni indulaskor, egy csomo file ott kell legyen a helyen, raadasul egy ujrainditas utan is meg kell maradjon. Megnezzuk, melyik file-okra van tenylegesen szukseg, ezeket meghagyjuk a /var-ban (peldaul /var/lib/dpkg/info), megnezzuk, melyik file-okra es konyvtarakra van szukseg bootolaskor, de felulirodnak, es a tartalmuk nem kell megmaradjon ujrainditas utan, ezek mehetnek a ramdiskre (peldaul /var/lib/ntp), es vannak, amik nem szuksegesek, a rendszer ugyis letrehozza oket, amikor kell (peldaul a /var/lib/apt/lists/ alatti file-ok).

Csinalsz egy szkriptet, ami legelsokent fut majd le indulaskor (rcS.d/S00unionfs), es a kovetkezoket csinalja:

- letrehoz egy ramdisket:

mount -nt tmpfs tmpfs /mnt/tmpfs

- belemasolja/letrehozza benne a szukseges konyvtarakat:

tar -xzf /etc/unionfs/var.tar.gz

- letrehozza az union mount-ot:

mount -t unionfs unionfs /var -o dirs=/mnt/tmpfs:/var

Innentol ha olyan file-ba irsz, vagy olyan konyvtarban hozol letre egy file-t, ami a flash-en van, az tovabbra is a flash-en marad, minden mas file (akar a .tar.gz-bol szarmazo, akar frissen letrehozott) a ramdiskre kerul, es ujrainditas utan nyilvan elvesz. Ha jol valogatod ossze a ramdisked tartalmat, el lehet erni, hogy osszesen 1, azaz egy iras tortenjen a flash-re (a /proc/diskstats-ban ellenorizheted).

Köszönöm a leírást! Sajnos itt valami nem stimmel :(
1. Megnéztem, a Squeeze -ben használt 2.6.32 dokumentációban (Debian csomag) nincs ilyen "Documentation/filesystems/unionfs/"
2. A www.kernel.org/doc/Documentation/filesystems/ alatt nincs unionfs
3. Megnéztem a mount "type" opcióit - nincs unionfs
Milyen verziójú kernelről beszélünk?

Nagyon tetszik amit leírtál, ez így eléggé kézenfekvőnek tűnik, és még én is érteni vélem. Ráadásul lehetőséget nyújt arra, hogy a normál linux -ot tegyem USB/CF használhatóvá, azaz a fejlesztői/tesztelői környezetnek megfelelő konfigurációval léphessek a "production" fázisba. Szeretném így megvalósítani, de nem látom a hogyant. Lehet hogy az aufs -el leváltották a unionfs -t mondván hogy az fejlettebb? Gyakorlatilag az általad leírtaknak megfelelően tudnám használni az aufs -t? A szintaxis, első pillantásra azonos. Egyébként, az aufs -ről sem találok semmit a kernel dokumentációban, de a drivere ott van /lib/modules/2.6.32-5-amd64/kernel/fs/aufs/aufs.ko illetve létezik egy csomag, a Debianban aufs-tools néven.

* Én egy indián vagyok. Minden indián hazudik.

Unionfs (tudtommal) soha nem is volt a kernelben, tehat le kell tolteni a patchet, majd forditani egy sajat kernelt. Patcheles utan ott lesz a doksi.

Aufs-t nem ismerem, soha nem probaltam, de valami olyasmit olvastam, hogy kompatibilisek, tehat valoszinuleg mukodik azzal is.

Azon töröm magam, hogy az aufs segítségével ugyanezt megvalósítsam. Közben felmerült néhány kérdésem:
1. A /tmp mappáról most nem szóltál, gondolom az tök hasonló?
2. Mi a helyzet a /var/log könyvtárban a mondjuk a syslog fájlal? Nem emlékszem (rég kellett ehhez nyúlni) de ott mintha mindig új és új fájl(ok) keletkeznének, azokat is a ramdisk/tmpfs -be küldi? BOCS!!! erről írtál - kicsit szétszórt vagyok.
3. Csak úgy eszembe jutott, initrd -t használok, nem lehet/kellene ott létrehozni a ramdisket, hogy az megmaradjon? (Lehet, mivel te kernelt forgattál, te nem használsz initrd - egy routerhez nem kell mindenféle driver, jól behatárolható, érdemes monolit kernelt használni.)
4. Miért jó/érdemes/kell tar.gz -be tenni a szükséges fájlstruktúrát? Várjunk csak .. igen egyszerűbb, mert itt összegyűjtöd azokat az állományokat amiket valójában a ramdisken kell tartani, ahhoz hogy ne az USB/CF -et írja - pl. a /var/log tartalma. Kár hogy az USB/CF -ről ezeket ki kell törölni :( (Lehet hogy az aufs ezt megoldja - jobban megkell nézni a doksit)

* Én egy indián vagyok. Minden indián hazudik.

Idézet:
1. A /tmp mappáról most nem szóltál, gondolom az tök hasonló?

Persze, csak peldakat irtam mindegyikre (a /tmp amugy nalam egy symlink a /var/tmp-re).

Idézet:
3. Csak úgy eszembe jutott, initrd -t használok, nem lehet/kellene ott létrehozni a ramdisket, hogy az megmaradjon?

Utalom az initrd-t... :-) Ha azt hasznalsz, akkor nyilvan onnan is letre lehet hozni, a lenyeg az, hogy nagyon a boot folyamat elejen tedd, mielott valami elkezdene hasznalni a /var-t.

Idézet:
4. Miért jó/érdemes/kell tar.gz -be tenni a szükséges fájlstruktúrát?

Vegulis nem muszaj, csak nekem akkor igy tunt egyszerubbnek. Vegulis a lenyeg, hogy a file-ok tulajdonosa es a jogok megmaradjanak, utana a te dolgod, hogy ezt hogy biztositod.

Idézet:
Kár hogy az USB/CF -ről ezeket ki kell törölni

Ugy szoktam csinalni, hogy winchesterre installalom fel a rendszert, azon beallitok mindent, majd lementem az egeszet egy masik gepre. Azon eloszor torlom a /var-bol a folosleges file-okat, utana kulonvalogatom a ramdiskre kerulo file-okat (es persze azokat is torlom az eredeti /var-bol), majd felrakom az egeszet a CF kartyara, es orulok. :-)

Le a kalappal! Mindenre meg van a válasz! Nagyon kösszönöm.

OFF: Most épp az aufs doksijait próbálom megérteni. Rég nem éreztem magam ennyire hülyének :( Még a szótárat is be kell vetnem! Pl. mit kell érteni a "whiteout" alatt itt (MTA SZTAKI szótár elküldött). Sok oldalas dokumentáció és mintha valami szóhalmazt olvasnék - alig bírom az értelmét kihámozni :(
Az már látszik, hogy nem kér külön ramdisket/tmpfst csak néhány könyvtár bejegyzést (legegyszerűbb a /mnt alá, de a Debian Live készít egy külön mappát és oda "pakol".

* Én egy indián vagyok. Minden indián hazudik.

Kaptam némi útmutatást az aufs -el kapcsolatban :) (mailing list aufs-users)

Idézet:
Az egyetlen lehetőség arra hogy ez működjön az, hogy az összes fájlt át kell másolni a /var -ból a /var.real -be és a union mount-ot a boot folyamat elején kell végrehajtani, mielőtt bármi írni akarná a /var könyvtárban lévőket:
rm -rf /var
mkdir /var
mount -t aufs aufs "/var" -o dirs="/tmp/var"=rw:/var.real"=ro

MEGJ: nem túl precíz fordítás!
Tehát tulajdonképpen ugyanazt javasolja amit te még a parancs is nagyon hasonló.
Viszont, kicsit zavarba hoztál, az rcS.d/S00unionfs -el - még nincs semmi bemountolva? Az @S10mountall.sh csinálja, majd rögtön utána már "pucolja" a dolgokat a @S11mountall-bootclean.sh ez pl. a /tmp a var/run és a /varlock könyvtárakat pucolja.
Szerintem ezt jobb lesz mondjuk a mountall.sh -ba, a végére belecsempészni?

* Én egy indián vagyok. Minden indián hazudik.

Idézet:
az rcS.d/S00unionfs -el - még nincs semmi bemountolva?

Csak a rootfs.

Idézet:
Szerintem ezt jobb lesz mondjuk a mountall.sh -ba, a végére belecsempészni?

Az keson lesz, mert a checkroot.sh a /var-ba logol.

Idézet:
az összes fájlt át kell másolni a /var -ból a /var.real -be

Nem tudom, az aufs hogy mukodik, de unionfs-nel ha egy file mar letezik a flash-en es irsz bele, akkor az tovabbra is a flash-en marad, ami nem jo dolog mondjuk a /var/log eseteben. Javasolnam, hogy valogasd szet a file-okat, ahogy fentebb ajanlottam, az ugyanis kiprobalt modszer (kb 30 gepem mukodik igy), nem csak otleteles egy levelezolistan.

Igazad lehet! Elkezdtem felderíteni az /etc/rcS.d alatt felsorolt scripteket.
Rögtön az első az S01mountkernfs.sh - igen, de ez egy tmpfs -t mountol a /lib/init/rw "fölé", illetve montolja a /proc és a /sys, no és tmpfs lesz a /var/run és /var/lock ... hű. Sosem foglalkoztam ilyen mélységig a boot folyamattal. Mikortól lesz írható a root fájlrendszer (aminek a /var a része), és mit takar a "domount" amivel a jelzett műveleteket végrehajtja?
Jó lenne kinyerni, hogy hol tart a moutokkal a boot folyamat, a legkoraibb stádiumokban - de hova tudom kitenni, hogy én is lássam?
Persze megpróbáltam a echo -t - semmi nyoma az S00 -ba elhelyezett cuccomnak :(
Megpróbáltam a sorost (>/dev/ttyS0) de ez butaság, itt még sem ilyen device és nyilvánvalóan nincs felkonfigurálva, még úgy sem hogy earlyprintk -val beállítottam hogy a sorosra loggoljon a kernel :(
Ráadásul mit is loggolnék? - a /proc/mounts -nak még híre-pora sincs. Most akkor mire az /etc/rcS.d -ben megadott scriptekre kerül a sor, mi, hogy, és mire van bemountolva?

* Én egy indián vagyok. Minden indián hazudik.

Idézet:
Sosem foglalkoztam ilyen mélységig a boot folyamattal

Pedig most igencsak szukseg lesz ra... :-)

Idézet:
Mikortól lesz írható a root fájlrendszer

mountall.sh

Idézet:
és mit takar a "domount"

Ez egy fuggveny neve, hazi feladatkent keresd meg, hogy melyik file-bol veszi (hint: source parancs, amit . (pont)-nak szokas irni).

Idézet:
Jó lenne kinyerni, hogy hol tart a moutokkal a boot folyamat

Szimulald kezzel a boot folyamatot: /sbin/init helyett indits egy shellt, es egyenkent, kezzel inditsd el az init szkripteket, akkor jobban atlatod majd, hogy mi tortenik.

Csupa jó tipp. Köszönöm!
A domount -ot megtaláltam a /lib/init/mount-functions.sh (azért ez klassz hogy ezeket a kis létfontosságú dolgokat, így itt-ott szétszórták - /lb/lsb/init-functions).
A rcS.d/@S10mountall.sh - vagyis csak a tizedik a sorban - akkor hogy is mountolgat a kernel a /sys, /proc de még a /var/run és /var/lock directory "fölé" is?
Azzal vergődöm, hogy beillesszek egy @S10valami.sh -t - egyenlőre csak a mount állapotokat szerettem volna kiíratni, de sehogy sem akar működni :( A "script" mindösszesen ennyit tartalmaz:

#! /bin/sh
echo "..............................................." >&2

A utóbbi átirányítást a mountkernfs.sh -ból merítettem. Nem működik, mintha ott sem lenne, ha ezt a sort becsempészem a mountkernfs.sh - ba (a case elé, a funkció definíció möge) akkor működik? Már próbáltam @S011, @S02 és @S021 de semmi, mintha meg sem hívná :(

Az /sbin/init lecserélése mondjuk /bin/bash? Hol is kellene ezt? - az initrd.img "init" scriptjében?
Mintha valami derengene, hogy ezt a lilo/grub által átadott kernel parancssorban is meglehetne adni ... valahol azzal kapcsolatban ha elfelejtettük a root jelszót.
Biztos vagy benne, hogy /sbin/init -t kell lecserélni? - az initrd.img ben a végszó, hogy

exec run-init ${rootmnt} ${init} "$@" <${rootmnt}/dev/console >/dev/console

* Én egy indián vagyok. Minden indián hazudik.

Ez zavarba ejtő :( Én úgy tudtam, hogy ahhoz hogy egy bizonyos futási szinten valamit elindítsak, elég ha beteszem a megfelelő /etc/rcx.d -be (esetleg többe is). Most viszont az derült ki, hogy nem a Debian "update-rc.d" -t kell futtatni. Régebben enélkül is működött (tény hogy eddig az S -be sose pakoltam semmit).
Mindenesetre, az "update-rc.d check_mounts.sh S" szépen betette @S01check_mount.sh -ként az /etc/rxócS.d -be a scriptemet és így működött. Tény hogy így is valami warningot dobott majd még kitalálom miért is. De legalább így betudom illeszteni a futtatandók közé.

* Én egy indián vagyok. Minden indián hazudik.

A nagy kérdésre az a válasz - a Debian Squeeze világában - hogy S07checkroot.sh
Itt kerül a fizikai kötet (nálam címke alapján) rw -ként mountolva és a /proc/diskstat innentől kezdve mutat írási aktivitást az sd1 -es partíción, ami a rendszer. Mindenképpen ez előtt kell felépíteni a "unifikált" kötetet.
Lehetne még agyalni, hogy miért is ilyen a sorrend, de ezt már nem biztos hogy megéri - minél kisebb a beavatkozás, annál hatékonyabb :)

* Én egy indián vagyok. Minden indián hazudik.

Hát most leakadtam :(
Az S01 magasságában, a / fs nem írható, így az mtab sem :( A domountot kellene használnom, de abba hogy kellene beleilleszteni a "mount -t aufs -o br:/tmp/var:/var none /var" parancsot?

* Én egy indián vagyok. Minden indián hazudik.

Elbambultam, megint. Kell az a -n opció a mount -nak.
(persze, így meg azt nem értem minek a "domount" nevű eljárás, amit a debian használ?)

* Én egy indián vagyok. Minden indián hazudik.

Idézet:
Innentol ha olyan file-ba irsz, vagy olyan konyvtarban hozol letre egy file-t, ami a flash-en van, az tovabbra is a flash-en marad, minden mas file (akar a .tar.gz-bol szarmazo, akar frissen letrehozott) a ramdiskre kerul, es ujrainditas utan nyilvan elvesz.

Valami nem stimmel :( A /var/lib/alsa/asund.state tárolja a mixer beállításokat. Csak az "eredeti" /var könyvtárban található meg, még a könyvtár is /var/lib/alsa, ennek dacára, ha módosítok a beállításon az állomány nem változik? Ha direkt elmentem #alsactl -f /var/lib/alsa/asound.state store" akkor megjelenik mindkét helyen (/var és /mnt/var) viszont, ha újraindítom elvész. Most akkor ez hogy van?

* Én egy indián vagyok. Minden indián hazudik.

Idézet:
Csak az "eredeti" /var könyvtárban található meg

Feltetelezem, hogy az eredeti a flash-t jelenti.

Idézet:
Ha direkt elmentem #alsactl -f /var/lib/alsa/asound.state store" akkor megjelenik mindkét helyen (/var és /mnt/var) viszont, ha újraindítom elvész.

Ugye a ramdisken nincs /var/lib/alsa konyvtar, es a flash nem readonly branch?

Igen, a /mnt/var/alsa CSAK a flash -en létezik, és a ram -ba nincs ilyen könyvtár.

Ami a readonly branch dolgot illeti, ez a parancs állítja be:

#mount -nt aufs -o br:/mnt/var:/var none /var

ez vajon milyen branch? - nem tudom mi az alapértelmezés :( A man azt mondja az engedélyekre:
"rw Readable and write branch. Set as default for the first branch. If the branch filesystem is readonly, you cannot set it 'rw'."

A /proc/mounts ezt mutatja (a teljes listát lásd lejjebb):
tmpfs /mnt/var tmpfs rw,relatime 0 0
none /var aufs rw,relatime,si=1a502864c7c1c06b 0 0

Ez így readwrite -nak tűnik.
Tény ha a Debian start/stop scripteket nézem, a alsamixer állapot mentése K01 jóval utána jönnek az umount -ok.
Egyébként, az még egy "hiba", hogy a halt/reboot nem tudja umountolni az aufs branchet, de nem hinném hogy ez lenne a gond, vagy mégis? De akkor miért csak az alsa állapottal van gond, a crontab működik.

Szerk: NEM! Tévedtem, a crontab sem tud módosulni reboot esetén az addig bevitt dolgok elvesznek :(

* Én egy indián vagyok. Minden indián hazudik.

Idézet:
#mount -nt aufs -o br:/mnt/var:/var none /var/

Akkor itt lesz az eb elhantolva, mert a leiras szerint (az elso branch kivetelevel) a default a read-only.

Idézet:
none /var aufs rw,relatime,si=1a502864c7c1c06b 0 0
Ez így readwrite -nak tűnik.

Az aufs filerendszer maga read-write, nem a kulonbozo reszei.

Három lehetőséget látok.
- Az aufs mount -nál rw -nek "hazudom" a /var -t (ami azért nem igaz, mert csak a mountall.sh után lesz írható).
- Vagy a mountall.sh után kell felépítenem az aufs -t, vállalva hogy pl. a fsck belefirkál a logba.
- Amíg leírtam jutott eszembe, hogy esetleg két részre lehet bontani, egyszer valamit létrehozok az elején, hogy ne logoljon az USB -be (pl. simán "ráhúzok" egy tmpfs -t a /var könyvtárra) majd a mountall.sh után ezt megszüntetem úgy, hogy beállítom az igazi aufs könyvtárat. Nem biztos hogy ez így megoldható, mivel már az aufs -nél is meggyűlt a bajom az umount -al - "/var: device is busy".
(Kezdem érteni, miért beszélnek a leírásban ennyit arról, hogy mire nem lehet ráhúzni ezt a dolgot, illetve milyen branchet nem lehet alkalmazni)

* Én egy indián vagyok. Minden indián hazudik.

Csak a próba kedvéért, egy PXE bootos rendszerrel létrehoztam az USB -egy olyan könyvtárat és fájlt ami tutira nincs a tar -ban (később a /mnt/var -ban). Aztán betöltöttem a rendszert módosítottam a fájlt. Újra töltés után a módosítás elveszett :(
Azon töprengek, hogy lehet hogy kell neki az umount? - akkor szinkronozza le a dolgokat. Furcsa lenne, hiszen akkor ugyanúgy írná az USB -t csak nem látnám, mivel olyan időszakban történik amit nem tudok ellenőrizni a /proc/diskstats -al.

Szerk: Hab a tortán, nem is tudom umount -olni. Legalábbis normál üzemben nem - a /mnt/var -ra IOCTL hibát dob, a /var -ra meg, hogy foglalt.

* Én egy indián vagyok. Minden indián hazudik.

Még egy ötletem van. Lehet hogy azért mert mikor létrehozom, a /var ro (mint a gyökér fájl rendszer része)? Lehet hogy ezt a dolgot csak már írható állapotban szabad elindítani?

* Én egy indián vagyok. Minden indián hazudik.

Nem tudnál egy kicsit részletesebb leírást csinálni?
Rengeteg különféle szösszenet van erről a neten, de mind valami mást céloz. A te megodlásod sokkal egyszerűbbnek tűnik. Sajnos arról semmi, hogy pl. hol is kell ezeket a brancheket létrehozni - a szintaktikája kitalálható a leírás alapján, csak az nem világos, hol kell beavatkozni.
Ami kicsit még zavar ebben a kérdésben, hogy a /dev, a /sys és /proc fájlrendszerekkel - látom hogy ez valami külön dolog, de homályos, hogy mit is kell vele tenni.

* Én egy indián vagyok. Minden indián hazudik.

subscribe

+1

Úgy tűnik, hogy a unionfs utódja az aufs - kernel modul aufs.ko Viszont a kernel dokumentációban nem találok róla semmit :(
Van részletes manual, a Debian -ban van aufs-tools nevű csomag, ami többféle konfigurációt tesz lehetővé. Számos eszközben használják (pl. mobil telefonok, az Android -ban is megtalálható).
Még mindíg nem találtam gey világos, értelmes leírást és útmutatót (how-to) amivel megis lehetne érteni pontosan mit és hogyan csinál :(

* Én egy indián vagyok. Minden indián hazudik.

Megint egy zsákutca?
Valahol olvastam, hogy a Debian live is aufs -t használ! Nosza, húzzuk l, nézzük meg.
Szép-szép, hogy ott vannak az image -k, de hogy is kellene ezt USB -re kirakni - végül a Debian installation manual szerinti legegyszerűbb verziót használtam, csináltam egy 1G W95 LBA partíciót, arra egy vfat és végül "#cat debian-live-6.0.3-.img > /dev/sdc1 (lehet hogy a mkfs.vfat nem is kellene). Benyomtam, boot - lereked ott hogy még nem áll fel az USB fájlrendszer, de már mountolná - OK. egy másik rendszeren próbálom be mountolni, de nem megy, ismeretlen fájlrendszer, hibás fat stb.
Jó, nézzük az img fájlt:
mount -t vfat debian-live-.img /mnt/tst -o loop
Panasz az utf8 -ra, invalid media type 0xb9 - érvénytelen fájlrendszer, nem talál vfat -ot a loop eszközön :(
Most akkor mi ez az image?

* Én egy indián vagyok. Minden indián hazudik.

nem sdc1-re, hanem sdc-re kell kimásolni, tehát:

cat debian*.img > /dev/sdX

Jogos! (nem, tudom hogy néztem be)
Akkor viszont particionálni sem kell?!
Az érdekes hogy így is elindult a boot :)

* Én egy indián vagyok. Minden indián hazudik.

Sikerült bootolható Debian live -ot felrakni az USB -re.
PXE boot RIP Linux segítségével fájl rendszer szinten hozzáfértem. Létrehozott egy az image fájlal pontosan egyező méretű vfat partíciót (gyorsan tar.gz -eltem egy másik gépre hálózaton át).
A már működő Live első pillantásra (ls /) kiköpött mása egy szokásos Debian telepítésnek, leszámítva a /live mappát.
A mount (pontosabban cat /proc/mounts) már sokkal izgisebb.
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
none /proc proc rw,nosuid,nodev,noexec,relatime 0 0
none /dev devtmpfs rw,relatime,size=1023968k,nr_inodes=219291,mode=755 0 0
none /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/sda1 /live/image vfat ro,noatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=utf8,shortname=mixed,errors=remount-ro 0 0
/dev/loop0 /filesystem.squashfs squashfs ro,noatime 0 0
tmpfs /live/cow tmpfs rw,noatime,mode=755 0 0
aufs / aufs rw,relatime,si=844e9748,noxino 0 0
tmpfs /live tmpfs rw,relatime 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,mode=755 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev,relatime 0 0

és itt a /proc/diskstats

8 0 sda 1763 650 117005 7232 0 0 0 0 0 4120 7228
8 1 sda1 1720 644 116613 7052 0 0 0 0 0 3940 7048
7 0 loop0 0 0 0 0 0 0 0 0 0 0 0
7 1 loop1 0 0 0 0 0 0 0 0 0 0 0
7 2 loop2 0 0 0 0 0 0 0 0 0 0 0
7 3 loop3 0 0 0 0 0 0 0 0 0 0 0
7 4 loop4 0 0 0 0 0 0 0 0 0 0 0
7 5 loop5 0 0 0 0 0 0 0 0 0 0 0
7 6 loop6 0 0 0 0 0 0 0 0 0 0 0
7 7 loop7 0 0 0 0 0 0 0 0 0 0 0
(ez azután készült, hogy sebtében felnyomtam az ssh -t és az mc -t)
Ráadásul, ezt még erősen "magamhoz" kellene igazítanom - de elfelejtettem hogy hol vannak az angol billentyűzeten a dolgok :(
A müszi által javasolt megoldás sokkal szimpatikusabb - de nem látom honnan vegyem a hozzávalókat :(

Még egy apróság, ha valamit feltelepítek (csak úgy simán apt-get) az a következő bootoláskor elvész.

* Én egy indián vagyok. Minden indián hazudik.

Vaciláltam hova is írjam ezt a bejegyzést - ez most egy új kezdet lesz - kár nem tudom mikor lesz időm visszanyúlni hozzá.
Úgy tűnik, hogy ahhoz hogy az aufs működését, konfigurálását meglehessen érteni, a unionfs -hez kell visszanyúlni (szerintem, hallgatólagosan). Az aufs "doksi" nagyban erre támaszkodik. Ha valaki beleolvas a threadbe látja, hogy müszi barátunk hivatkozik az aufs.org -ra, ahova persze benéztem. A legérdekesebbnek tűnő dokumentum "Unionfs in examples (Tomas Matejicek, Juy 20.2005)" linkje valami f'szságra mutat, ahol azt fejtegetik miért is jobb az aufs mint a unionfs - némi "direkt" keresgélés után megtaláltam eme örökbecsű dokumentumot. (Érdekes volt, mert a böngésző ahelyett hogy megnyitotta volna letöltésre kínálta fel? - valamit elbénáztam? Sajna nem tudom hova feltenni.) Ebben a kis (alig kétoldalas) anyagban ott van mi is az a "WHITEOUT" és alapvetően hogyan kell ezt összerakni, használni. Itt meglehet tudni, hogy a "BRANCH" utasításokat honnan-hova kell olvasni/értelmezni, és (az ugyancsak a Tomas Matejicek által készített) mini Linux - SLAX - hogy használta a unionfs -t.
Szóval ha ezt érteni akarnánk akkor ez a kis sillabusz szerintem "must be". (Ki és miért dugta ezt, pont ezt el fel nem foghatom). Innen kellett volna indulni, akkor mára megvagyok.
Remélem mielőbb visszanyúlhatok ehhez, és megcsinálhatom :)

* Én egy indián vagyok. Minden indián hazudik.

A megoldás szinte pontosan az mint amit muszi barátunk leírt (alkalmasint jövök egy sörrel).
Emlékezetető: az itt leírtak a Debian Squeeze -re vonatkoznak!
Kell egy script amihez a mintát a mountkernfs.sh adta nekem, csak a "do_start" eljárásba a következők kerültek:
domount tmpfs "" /mnt/var tmpfs
tar -xzf /boot/aufs_var.tar.gz
mount -nt aufs -o br:/mnt/var:/var none /var

Sajnos itt kapunk egy hibaüzenetet arról, hogy az aufs valami régi verzió és nem megbízható :(
(Elvileg a Debian Live is ezzel a verzióval készült, olyan nagy baj nem lehet vele)
Az aufs_var.tar.gz tartalmazza azokat a fájlokat, amiket csak a ram diszkben szeretnénk látni.
A /tmp ram diszkesítése egyszerűen a az fstab -ból működik.

A /proc/mounts most így néz ki:
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
none /proc proc rw,nosuid,nodev,noexec,relatime 0 0
none /dev devtmpfs rw,relatime,size=1017196k,nr_inodes=254299,mode=755 0 0
none /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/disk/by-label/Rendszer / ext2 rw,noatime,errors=remount-ro 0 0
tmpfs /mnt/var tmpfs rw,relatime 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,mode=755 0 0
none /var aufs rw,relatime,si=1a502864c7c1c06b 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0
tmpfs /tmp tmpfs rw,relatime 0 0

Azért valami még nem gömbölyű :( A /var másolatba, a ram diszk számára a var minden részét kimásoltam, kivéve a /var/cache és a /var/lib könyvtárakat - így még mindig sokat firkál az USB -re, ezt finomítani kell!

* Én egy indián vagyok. Minden indián hazudik.

Hááát? Most az egész /var tartalmát beletettem a tmpfs -re mountolt /mnt/var -ba, mégis írja a /dev/sda1 -et? most akkor nem jó?

* Én egy indián vagyok. Minden indián hazudik.

13 órányi üzemidő után, itt tartok (/proc/diskstats):
8 1 sda1 2288 140 157418 15480 70 14 848 68 0 7184 15536
Mindezt úgy, hogy az egész /var írása a ramba megy. Valami nem stimmel, mi az ördögöt firkál ez még és hova? Nincs valami hook a fájl írásokhoz a Linuxban?

* Én egy indián vagyok. Minden indián hazudik.

Idézet:
Mindezt úgy, hogy az egész /var írása a ramba megy. Valami nem stimmel, mi az ördögöt firkál ez még és hova?

Az eredeti /var ott van meg a flash-en? Ha igen, akkor amint irtam, a file modositas az eredeti helyre megy, nem a tmpfs-be.

OK kipróbálom, kitörlöm az eredeti /var -t. Viszont akkor meg azt nem értem, hogy miért csökkent úgy nagyjából a tizedére az írás?

* Én egy indián vagyok. Minden indián hazudik.

Mintha javult volna, a helyzet, bár eleve 33 írásművelettel idított a rendszer (azaz miután promptot kaptam, már ennyit firkált).
Viszont kiszúrtam, hogy baja van a /mnt/var umountal:

Idézet:
Unmounting temporay filesstems ... unmount: /mnt/var: device is busy

A hibát az /etc/init.d/umountfs dobja - majd kipróbálom, hogy beteszem elé az én kis mount_aufs.sh scriptemet csak K -val.
Egyenlőre az írások csökkentése fontosabb.
De most tényleg, nincs semmi amivel követni/naplózni lehetne az írásokat fájl rendszer szinten (mikor útvonal/fájl)?

* Én egy indián vagyok. Minden indián hazudik.

17 órányi üzemidő után (uptime) 33 befejezett írás (ezek még az elején "csúsznak" be) azt hiszem kijelenthetjük, hogy a dolog működik. Más kérdés, hogy most teljesen le van pucolva a /var és minden csak a /mnt/var tmpfs -ben történik - ezt finomítani kell!
Arra gondoltam, hogy végig kellene "pásztáznom" a /mnt/var -t a stat segítségével ami vissza adja az utolsó módosítás idejét, így egzakt kilehet szúrni mely fájlokat piszkálja a rendszer. Persze még ebből is érdemes tovább "csemegézni", hogy hányszor írja (ezt nemigen lehet egzakt módon kibogarászni), illetve miért is - kell-e nekünk a változás a továbbiakban vagy sem.
Kell egy script ami x percenként végigfut az összes fájlon a /mnt/var -ban és ha változást talál naplózza. (Jó lenne ezt már az elején is lefuttatni - mi is az a 33 amit megpiszkál a rendszer - kell -e az nekem).

* Én egy indián vagyok. Minden indián hazudik.

Nos egyenlőre egy nagyon egyszerű kis scriptet csináltam, még csak ki sem írtam.

#for item in `find /var`;do stat --format="%n %y %s";done >> /tmp/var_stat.txt

aztán csináltam egy kis leválogatást:
#grep 2011-11-22 >> /tmp/22-23-var_stat.txt
#grep 2011-11-23 >> /tmp/22-23-var_stat.txt

Íme az eredmény:

Idézet:

/var 2011-11-22 18:20:38.580488578 +0000 320
/var/lib/urandom 2011-11-22 18:20:41.234570577 +0000 60
/var/lib/urandom/random-seed 2011-11-22 18:20:41.234570577 +0000 4096
/var/lock 2011-11-22 18:20:41.599575240 +0000 40
/var/log/debug.1 2011-11-22 18:20:42.474581273 +0000 150490
/var/log/kern.log.1 2011-11-22 18:20:42.983578272 +0000 566509
/var/log/daemon.log.1 2011-11-22 18:20:42.923070908 +0000 2680
/var/log/dmesg 2011-11-22 18:20:42.622579373 +0000 38243
/var/log/fsck/checkfs 2011-11-22 18:20:40.936074925 +0000 125
/var/log/fsck/checkroot 2011-11-22 18:20:40.760074965 +0000 195
/var/log/wtmp 2011-11-22 18:24:54.848075058 +0000 144768
/var/log/lastlog 2011-11-22 18:24:54.848075058 +0000 292584
/var/run 2011-11-22 18:20:43.287570459 +0000 260
/var/run/sshd.pid 2011-11-22 18:20:43.287570459 +0000 5
/var/run/crond.reboot 2011-11-22 18:20:42.983578272 +0000 0
/var/run/acpid.pid 2011-11-22 18:20:42.923070908 +0000 4
/var/run/acpid.socket 2011-11-22 18:20:42.903070666 +0000 0
/var/run/crond.pid 2011-11-22 18:20:42.970597900 +0000 5
/var/run/rsyslogd.pid 2011-11-22 18:20:42.406570904 +0000 4
/var/run/motd 2011-11-22 18:20:42.279071727 +0000 355
/var/run/screen/S-tovis 2011-11-22 18:24:49.363397390 +0000 60
/var/run/screen/S-tovis/1114.webcam 2011-11-22 18:29:27.846570877 +0000 0
/var/run/utmp 2011-11-22 18:29:27.846570877 +0000 6144
/var/spool/mail 2011-11-22 18:20:38.467590267 +0000 7
/var/spool/cron/crontabs 2011-11-22 18:26:54.770582825 +0000 60
/var/spool/cron/crontabs/tovis 2011-11-22 18:26:54.770582825 +0000 1380

/var/cache/man 2011-11-23 06:25:02.762613632 +0000 620
/var/cache/man/pt_BR 2011-11-23 06:25:02.762613632 +0000 120
/var/cache/man/zh_CN 2011-11-23 06:25:02.767073237 +0000 120
/var/cache/man/sv 2011-11-23 06:25:02.771072463 +0000 120
/var/cache/man/gl 2011-11-23 06:25:02.771072463 +0000 80
/var/cache/man/sr 2011-11-23 06:25:02.779072180 +0000 80
/var/cache/man/cs 2011-11-23 06:25:02.783071616 +0000 120
/var/cache/man/fi 2011-11-23 06:25:02.787072267 +0000 100
/var/cache/man/pt 2011-11-23 06:25:02.787072267 +0000 120
/var/cache/man/id 2011-11-23 06:25:02.787072267 +0000 120
/var/cache/man/ja 2011-11-23 06:25:02.799071695 +0000 120
/var/cache/man/es 2011-11-23 06:25:02.807072507 +0000 120
/var/cache/man/pl 2011-11-23 06:25:02.811072363 +0000 120
/var/cache/man/hu 2011-11-23 06:25:02.819078351 +0000 120
/var/cache/man/ru 2011-11-23 06:25:02.819078351 +0000 120
/var/cache/man/ko 2011-11-23 06:25:02.835072210 +0000 120
/var/cache/man/fr 2011-11-23 06:25:02.847072203 +0000 120
/var/cache/man/de 2011-11-23 06:25:02.855071970 +0000 120
/var/cache/man/tr 2011-11-23 06:25:02.863072272 +0000 120
/var/cache/man/it 2011-11-23 06:25:02.863072272 +0000 120
/var/cache/man/zh_TW 2011-11-23 06:25:02.883074408 +0000 120
/var/lib/logrotate/status 2011-11-23 06:25:02.496075067 +0000 692
/var/log 2011-11-23 06:25:02.496075067 +0000 1560
/var/log/messages 2011-11-23 06:25:02.496075067 +0000 163
/var/log/messages.1 2011-11-23 06:25:02.088076711 +0000 419609
/var/log/debug 2011-11-23 06:25:02.468073597 +0000 0
/var/log/user.log 2011-11-23 06:25:02.468073597 +0000 0
/var/log/auth.log 2011-11-23 19:10:01.095078320 +0000 16847
/var/log/auth.log.1 2011-11-23 06:25:01.086574271 +0000 65994
/var/log/kern.log 2011-11-23 06:25:02.468073597 +0000 0
/var/log/daemon.log 2011-11-23 06:25:02.468073597 +0000 0
/var/log/syslog 2011-11-23 19:10:01.086577179 +0000 11106
/var/log/syslog.1 2011-11-23 06:25:02.088076711 +0000 613586

A /var/log /var/run /var/spool dolgokat még csak értem, de minek piszkálja a /var/cache/man pl. zh (gondolom Cseh) nyelvi mit is? Az már csak hab a tortán, hogy egyáltalán minek ez nekem? (A rendszeren utf8 és még elő van készítve a hu 8859-2 és hu utf8, miért kell nekem a diszken tartanom ennyi idegen nyelvet).
Ebből a kis tesztből (uptime > 1 nap) az jön le, hogy az USB -ről törölni kell a /var/log a /var/run /var/lock /var/spool/mail bejegyzéseket.
El lehet gondolkodni mi legyen a /var/lib/logrotate/status, /var/lib/urandom/ranndom-seed - ezeket nagyon ritkán írhatja a rendszer.
Vélemények?

Megjegyzés: a script és a lista nem mutatja hányszor íródott egy-egy állomány!

* Én egy indián vagyok. Minden indián hazudik.

"pl. zh (gondolom Cseh) nyelvi mit is?"
A zh_CN és zh_TW jelölésekből a CN Kína, a TW Taiwan, a zh pedig a mandarin. A cseh az cz lenne.

"minek piszkálja a /var/cache/man"
Ezért:
$ grep '^# ' /etc/cron.daily/man-db
# man-db cron daily
# Don't try to change I/O priority in a vserver or OpenVZ.
# expunge old catman pages which have not been read in a week
# regenerate man database
$

És hogy mi ez?
man mandb, man apropos, man whatis

"A rendszeren utf8 és még elő van készítve a hu 8859-2 és hu utf8, miért kell nekem a diszken tartanom ennyi idegen nyelvet"
Az UTF-8 a karakterkódolás. A mandarin pedig a nyelv. Ha nem tettél fel feleslegesen idegen nyelvű manualokat, akkor hozzávetőlegesen 13 kB méretű egy nyelv üres indexfile-ja. Azért ez nem a világ.

A kísérleti rendszeren még a 100M sem - de másutt esetleg ez is számít.
Mindegy, köszönöm, meggyőztél! Marad a tmpfs -en és pont.

* Én egy indián vagyok. Minden indián hazudik.

REVÍZIÓ!
Mint az később kiderült a technológia nem hibátlan.
A branch alsó eleme /var nem volt írhatóan befűzve az aufs alá. Így nem lehetett rá egyáltalán írni, pedig néhány dolog azért kellhet (crontab, alsamixer állapot stb.).
Az aufs parancs így kell hogy kinézzen:
#mount -t aufs -o br:/mnt/var:/var_rw none /var
Viszont ha így kiadjuk ezt a parancsot az /etc/rcS.d/@S01xxx akkor hibát dob, mivel egy egy olyan területet akarnék mountolni rw ami pill. ro. Így a rcS.d -ben a debian Squeeze -ben ez csak a chkroot.sh után következhet! Kellet valamennyit szkandereznem az update-rc.d -vel hogy a megfelelő helyre kerüljön a script de végül sikerült.
Így most pontosan úgy viselkedik a rendszer ahogy muszi barátunk mondta.

MEGJEGYZÉS: A Debian Squeeze -ben elhelyezett uafs csomag nem, hogy nem friss de egyenesen elavult!
A modul betöltésekor erre a rendszer is figyelmeztet.

KÖSZÖNET: muszi -nek és J.R.Okajima -nak a segítségükért.

* Én egy indián vagyok. Minden indián hazudik.

Idézet:
#mount -t aufs -o br:/mnt/var:/var_rw none /var

Viszont ha így kiadjuk ezt a parancsot az /etc/rcS.d/@S01xxx akkor hibát dob, mivel egy egy olyan területet akarnék mountolni rw ami pill. ro.

Az unionfs nem problemazik emiatt... :-)

Még nem próbáltam ki de Okajima azt mondja a hogy később ezt lehet módosítani, így:
#mount -o remount,mod:/usb=rw /var

Másrészről, az elején akkor is keletkezik úgy 12-13 írás, hogy nem a /var -ba ír!?
Annyira nem tűnik zavarónak, hiszen ez nem CD.

Még egy hasznos infó az alkotótól, itt lehet megnézni a branch tagok státuszát:
/sys/fs/aufs/su_*/br[0-9]*

* Én egy indián vagyok. Minden indián hazudik.