Linus Torvalds: Linux 2.6.33-rc2 - Merry Christmas

Kernel

Linus azoknak akart kedveskedni a 2.6.33-as kernel második kiadásra jelölt verziójával, akik az év e szakaszában nem ünnepelnek semmit, csak ülnek a sötét alagsorukban magányosan és unatkoznak. Ezeknek az embereknek ajánlotta tesztelésre a 2.6.33-rc2-t, mert mint írta, még mindig jobb ezzel foglalkozni, mint unatkozva semmit sem csinálni.

Meg azoknak, akik ugyan ünnepelnek, de torkig vannak már a sonkával. Tartsanak egy kis szünetet és fordítsanak egy kernelt. Akik ezt teszik, azoknak sikerélményben lehet részük, mert lehet, hogy a következő hónapban a nadrágjuk nem fog rájuk menni az ünnepi evészettől, de a kernel tökéletesen passzolhat a gépükhöz.

A bejelentés itt olvasható.

( Dacr (nem ellenőrzött) | 2009. 12. 27., v – 12:44 )

Van humora a "srácnak". :)

( bervi | 2009. 12. 27., v – 17:09 )

kíváncsi vagyok, hogy tényleg olyan jó lesz-e ez a sok grafikus dolog. annyi dolgot talicskáznak most a kernelbe, xorgba, mesa-ba, és állítólag annyira jó lesz nekünk. kíváncsi vagyok, mikor jutnak el ezek a dolgok release-ig, és mikor találkoznak végre össze egy disztró rilízben. pl. nouveau esetében. gyanítom, hogy leghamarabb min. fél év múlva mondjuk egy fedora kiadás keretében.
szerintem.

Elindítok egy rádióadást RealPlayerben és összeomlik az X; öt percig aktívan használom a swap partíciót és összeomlik az X; kiadok egy xrandr parancsot és eltűnik a kurzor; második képernyőt csak SaX2-vel lehet beállítani fájdalommentesen; a grafikai teljesítmény mint olyan nem létezik (Windowshoz hasonlítva)...
Szóval én is kíváncsi vagyok, hogy mikor lesz nekünk jó (vagy még kint van az alfa címke az Intel driveren?)

--
Elder Scrolls

Ha valaki követi, mondja már el, hogy mi a helyzet az ext4-gyel. Az ext3-ra formázott diszkem már a használhatatlanságig lassult, gondoltam újraformázom, de kicsit elbizonytalanított a sok adatkorrupciós hiba (.33-as kernelig bezárólag elég horror sztorikat olvastam pár perc keresgélés után).

[...]
Elolvastam pár kernel changelogot. Ennyi erővel a ZFS-t is választhatták volna az Ubuntu alap FS-évé (vagy a másik "érett" versenyzőt, a btrfs-t)... :)

Horror dolgok szerintem minden fájlrendszerrel vannak, és az új fejlesztések nagyobb nyilvánosságot is kapnak, így érdemes kezelni őket.

Nekem most kb. fél éve (új openSUSE telepítés) van ext4-em, és semmi adatvesztésem nem volt eddig. Más nevében nem tudok nyilatkozni, de itt a pozitív oldalhoz +1 :)

--
Elder Scrolls

A .32-vel javították már azt a hibát viszont cserébe olyan szinten lelassítja az írást, hogy jobb az ext3. Ettől függetlenül 3 desktop gépen használok ext4-et kb 0.5-1 éve, .32 előtti kernelekkel. Egyszer volt vele bajom összesen, asszem a .bash_history tartalma, meg talán a browser history veszett el. Tehát a hibajelenség sajnos létezik (bár mint ahogy már 1000x ki lett tárgyalva inkább a rosszul megírt alkalmazásoknak köszönhető), gyakorlatban a hatása nagyon ritkán jön ki. Nyilván ha a gép rendszeresen crashel, akkor nagy ívben kerülendő az ext4, egyébként a normál óvintézkedések (backup) mellett jól használható.
---
Internet Memetikai Tanszék

Na utánanéztem az ext4 témájának (annak apropóján, hogy megjött a 2.6.32.2-es kernel az Arch base repoba).

Nem teljesen értem, hogy ez a keményre fagyás ez hogyan related a fentebbi kérdésedhez, de az tény, hogy itt több különálló hiba javítása is szerepel.

A hírhedt "0 byte-os fájlok" problémára már 2.6.30 környékén Tytso berakott egy workaroundot, ez az auto_da_alloc mount opció. Ez az, ami felismeri az fsync hívás nélküli fájl tartalom felülcsapást és automatikusan beteszi az fsync-et a megfelelő helyre. Ha jól látom akkor default engedélyezett, tehát a 0 byte-os fájl probléma elviekben már nem kéne, hogy előforduljon. Ennek van valamekkora ára teljesítményben, de kb annyi amennyi akkor is lenne, ha az alkalmazás eleve kultúráltan lenne megírva.

A másik változtatás a 2.6.32 kernelbe került be, "fix cache flush in ext4_sync_file" illetve "barriers on by default" néven fut és okozott egy durva teljesítményromlást. Annyit tesz, hogy minden fdatasync után csinál egy teljes cache flush-t is (ezzel gyakorlatilag kiírtva az optimalizálási lehetőségeket). Ez az ellen véd, hogy a blokkos eszköz írási pufferében várakozó adatok elveszhetnek ha elmegy az áram. Battery-backed cache és úgy általában véve szünetmentes táp esetén ez az óvintézkedés biztonságosan kikapcsolható a nobarrier mount opcióval (feltéve persze, hogy az adott kernel nem crashel folyton :) ).
---
Internet Memetikai Tanszék

Ubuntu Karmic alapján nem, indítom az openarena-t, fekete kép. ctrl+alt+f1, killall -9 openarena, X elszáll. Compiz ki, openarena indít, játszok, kilépek, X elszáll.

Ubuntu Jaunty-ban és openSUSE 11.2-ben (ahol még nincsenek benne ezek az "innovációk") tökéletesen működik. Intel 4500mhd kártya.

( hnsz2002 v | 2009. 12. 28., h – 08:31 )

Itt kérdezném meg, hogy használ-e valaki ext4-et valamilyen éles rendszeren (server|home server|desktop|laptop|bármi), és ha igen milyen kernellel?
A minap a boot kivételével az összes fs-emet ext4-re újracsináltam, azóta esik-kel a gép. A 31.6-os kernel egy katasztrófa, 5 percenként merevre állt, alig bírtam a 32.2-t lefordítani, vagy ötödjére sikerült. Először minden jónak tűnt, de tegnap este kikapcsolás előtt ez is ugyanúgy merevre állt. Főleg akkor történik, ha nagy fájlokat (4-8GB) másolgatok, és egyszerre többet is. A 32-es az elhalás előtt be is lassult ilyen 7-8MB/s-re.
Az újrakreáláskor a legújabb 1.3.3-as system rescue cdvel mentettem, illetve másoltam vissza a cuccokat, az is belehalt nemegyszer a történetbe. Kb. a második elhalás után lettem arra figyelmes, hogy azalatt is a csoda 31.6-os kernel van. Tehát valszeg nem csak általam forgatott kernel szar.
Érdekes, hogy mielőtt megtettem e merész lépést, a boot és home kivételével mindent ext4-re konvertáltam ext3-ról, azzal úgy nem volt gondom, ezért is mertem újracsinálni 0-ról ext4-gyel. Dehát ez így nagyon nem fasza, még esetleg megnézem a 11.2-nek a 31-es default kernelét, abba hátha patcheltek valamit. De ha azzal se lesz jobb, akkor mentek egyet a külső hddre megint (ami szintén ext4 immár... :S), és mkfs.extbetonstabil3
--
Discover It - Have a lot of fun!

Legalább 3 hónapja folyamatosan ext4-ezek a /boot kivételével, 30 és 31-es kernellel, semmi ilyen problémám nem volt, pedig túlélt már 1-2 hirtelen áramszünetet is (szünetmentes nincs). Bootnál jajgatott, hogy húde milyen currupted lesz, reboot, automatikusan fsck-zik, javít aztán megy tovább hiba nélkül

- Fél éve használom, és egyszer az egyik config fájlom 0 bájtossá alakult. Egészen biztos vagyok benne, hogy nem én tettem. :) Desktopon, használom. Öröm az ürömben, hogy könnyen pótolható volt, de azért elgondolkoztam kicsit, hogy jó-e ez így nekem... Én az eltérő szinkronizációt hibáztatom, ami ugye .32-es kerneltől defaultjában már nem eltérő.

+ Egyébként fagyás, esés-kelés nem volt tőle soha, csak gyorsabb fsck és fájltörlés ext3-hoz képest.

( uid_228 | 2009. 12. 28., h – 09:50 )

A hozzászólásokat olvasva úgy érzem, mintha a kabarérovatban lennék. Valóban ilyen kétségbeejtően instabilak az új filerendszerek?

--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.

( dvornikl (nem ellenőrzött) | 2009. 12. 28., h – 12:32 )

Hogy pozitív hozzászólás is legyen, azt kell mondjam nagyon megérte beolvasztani a Nouveau-t, GeForce FX 5200-as kártyával pöpecül megy a nouveaufb, a KMS és a nouveau Xorg driver. Arch Linux alatt teszteltem, szerencsére többet nem kell Nvidia driver telepítésével időt töltenem.

( ssa2 v | 2009. 12. 28., h – 18:04 )

Arról hallott valaki, hogy lesz-e a kernelbe építve valami intel turbo boost támogatás?
Eddig azt hittem, hogy az intel alaplapok naprakészen támogatottak linuxon, de be kellett látnom hogy ez nem így van.