Linux 2.6.28 (diskuse)

[pavlix]

Ta ext4 mě těší :).

[David Watzke]

Hned jsem ho nahodil na testovací oddíl a vypadá to slušně, ale zatím moc brzo na to dělat nějaký závěry...

[prOm3TheuS]

Že by to byl od vývojářů jádra dárek k vánocum?

[David Watzke]

Linus říkal, že je. U oznámení -rc9 psal, že to je tak nudný vydání, že jestli někdo neusne v polovině čtení changelogu, tak je borec a že než sám umře nudou, tak raději vydá stable o Vánocích.

[Sešívaný]

Myslím, že po té divočině v podobě 2.6.27 si Linux a především jeho uživatelé zasloužili nějaké to "nudné" vydání.

[David Watzke]

Pozor, šlo jen o -rc8 vs. -rc9 .27 vs. .28 je aspoň podle mě slušnej nářez...

[*******]

Tak ja teda radsi stable... 2.6.28 mi uz segfaultla 8x. 5x nekde v zurnalu. 3x v munmapu. /var fuc.

takze happy holidays. podle velikosti changelogu... sice nekdo usne nudou u 2.6.27.9, ale ten kdo docte do konce 2.6.28 je borec. takovych zmen, ze tomu rikat stable fakt ne-e.

vsechno to byly docela lowmem podminky, kdy dochazi pomalicku mencoderu dynamicky videobuffer a rychlost disky je skoro totozna s rychlosti zapisovaneho streamu...

[*******]

btw. ve kterym 2.6 kernelu neni potencialni data corruption bug?

byl nejaky takovy od dob 2.6.23 ?

[Bluebear]

Do bugzilly s tím; tím přispěješ k opravě daného bugu.

[*******]

Nema smysl. Staci si vyjet z bugzilly bttv bugy open i close a zbeznym pohledem koukam sem tam neco fixnute a nadpolovicni vetsina oopsu u stejneho chipsetu je insufficitent rejected. Zrejme nekdo u ATI (AMD) rozhodl, ze se tim nebudou zabyvat, ze je to hardware mimo support window, tak ty bugy programove nekdo na zaklade toho sabotuje.

[*******]

Rozhodne nemam strach, ze by se o problemu nevedelo.

[####]

Hero of the year.

minimalne 4 roky stary data corruption se povaluje v kernelu a nikoho to nezajima :) ze by duvod, proc zadna ze stable distribuci nedodava mencoder a mplayer?

http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2005-December/039271.html

[Martin Ždila]

ja uz nejaky ten mesiac bezim bez problemov na ext4dev v kubuntu. iba jeden zvlastny ukaz: niekedy ked v mc dam zmazat adresar, tak sa tvari ze ok, ale nezmaze. a spravi to az na druhy alebo treti pokus. ale problem nemusi byt vo fs, lebo tusim rm -rf adresar mi slo vzdy na prvy krat

[Tom K]

Ve 2.6.27 a prvnich rc 2.6.28 byla chyba, ktera zpusobovala, ze pri readdir byly nektere polozky vraceny dvakrat. Nektere programy to ignorovaly a jine s tim mely problem. Ve 2.6.28 a tusim i v 2.6.27.10 je to opravene.

[Nicky726]

Jaký je vlastně reálný přínos ext4 oproti ext3?

[David Watzke]

No je rychlejší, líp se brání defragmentaci tím, že podporuje různý záležitosti modernějších souborových systémů (nerozumím tomu, přečti si o tom třeba na kernelnewbies), ale i tak má nástroj na (opravdovou!) defragmentaci. A taky posunuje různý limity a má rychlejší fsck.

[Nicky726]

To vypadá zajímavě, díky. Asi vyzkouším na notebooku, až se kernel 28 dostane do Archu.

[Jim]

Kdyby se líp bránil defragmentaci, tak by asi o něj takový zájem nebyl, protože to v pohodě zvládne i fat32. Tam jde spíš o to, že v budoucnu by měl podporovat i online defragmentaci. Pokud jsem dobře informován, tak zatím opravdu neé. Snad někdy příště.

[David Watzke]

Kdyby se líp bránil defragmentaci, tak by asi o něj takový zájem nebyl, protože to v pohodě zvládne i fat32.

Chybička se vloudila.

[Michal Fecko]

Ono ta defragmentacia postupom casu s prichodom SSD diskov strati vyznam - kedze pri technologii SSD nevadi ze udaje niesu jednoliate - nema to vplyv na rychlost hladania alebo citania. A ak po defragmentacii sa zvysi (ak vobec) vykon pri citani o 1 - 5% tak defragmentovat nikto IMHO nebude.

[David Watzke]

No hlavně by na SSD mohla bejt defragmentace mnohem rychlejší, takže to člověk (jako jsem já) prdne do cronu a nebude se o to víc starat.

[Luk]

Jenže ona často nebude vůbec potřeba. Přístup k libovolnému bloku trvá stejně dlouho, čili doba čtení/zápisu není závislá na tom, jak jsou data uspořádána (nechávám stranou fakt, že fyzický blok SSD může být větší než blok FS, tam by při zápisu fragmentace vadila).

[Limoto]

U SLC ne. Ale co MLC?

[Luk]

Neznám konstrukční detaily, ale nenapadá mě, proč by to nemělo platit u SLC i MLC. Existuje nějaký důvod, proč by měla rychlost přístup k datům záviset na pořadí přístupu?

[Limoto]

Musí se přečíst/zapsat vždycky celej blok dat?

[Luk]

Ale to se přece při práci se soubory (s filesystémy) musí tak jako tak. Jde jen o to, jak velký je fyzický blok (ten, se kterým pracuje zařízení - může se lišit pro čtení a zápis) a logický blok (alokační jednotka filesystému).

[Josef Kufner]

Pak je ještě otázkou, jak si s tím poradí datové struktury filesystému. Jestli přístup k souvislému sledu bloků nebude vyžadovat míň hledání než je lovit po všech Čertech. Ale nečekám, že by to byl vážný problém.

[Luk]

Záleží na konkrétním filesystému. Pokud je to tak (a to AFAIK u všech ext* filesystémů je), že je v inode nebo v odkazovaných blocích uložen přímo seznam pozic bloků, pak je úplně jedno, jak jsou data uspořádána. Nebylo by to jedno v případě filesystémů, kde by byl uložen vždy počáteční blok a délka souvislé oblasti.

[Nicky726]

No co jsem se zatím (ne moc do hloubky) zajímal o SSD, tak ext4 asi nebude nejvhodnější filesystém na něj (kvůli žurnálu).

[stativ]

To by mě zajímalo, čím nahradí žurnál u SSD disků. Něco k udržení konzistence dat tam být musí.

[Josef Kufner]

Co to bylo za fs, který používá místo žurnálu nějaký počítadla (času)? Tuším, že btrfs nebo tak něco...

[stativ]

A nemusí se to taky nějak zapisovat na disk? Protože mně připadá jako jediná možnost snížení opotřebení ukládání žurnálu/čehokoliv_s_podobnou_funcí rovnou k ukládaným datům, pak by ale kontrola integrity nejspíš trvala o dost déle, protože by se musel procházet celý strom/cokoliv_jiného_podle_implementace.

[vlastikroot]

Nebyl to ten System Pro Psychopaty a Debily od BLEK.a ?

[Michal Fecko]

Mam taky tusak ze hej, ten system mal "privlastok" PoruchaOsobnostiFS

[Josef Kufner]

Supr... teď ještě aby někdo brzy ubalil pro debian nějaký hezký balíček, ať se s tím nemusím kompilovat

[MaT]

Jasně, zvlášť když v Debianu není ještě ani 2.6.27...

[asfethan]

Ja ho už mám

[knizmi]

Jj, nechapu, proc to nedaj aspon do experimentalu.

[Pavel Půlpán]

A chceš ho i s mašličkou?

[Josef Kufner]

To by šlo? Prosím prosím, smutně koukám...

[mirec]

Mám to chápať tak, že už nebude potrebné kvôli hdaps aplikovať patch do kernelu?

[Jakub Lucký]

HDAPS read funguje už dlouho... ale tohle zastavování hlaviček vypadá jako novinka, ale nejsem si jistý, jestli je to totéž jako ten patch, co se dodával k hdapsd předtím...

[Dragon Jake]

Je to to samé, ten patch, tedy to, co je teď v novém jádře, je podpora v ATA/SATA subsystému (nebo jak se tomu nadává) pro parkování hlaviček disku.

[Jakub Lucký]

Dík...

Ale co si pamatuju, počítač se pak dost sekal, co?

[mirec]

Ja som to používal, občas so staršími verziami sa stalo (asi raz mesačne), že po zaparkovaní hlavičiek to už neodparkovalo. Nové verzie to už našťastie nerobia takže si môžem dovoliť to mať stále zapnuté. Žiadne spomalenie som nezaznamenal, akurát občas keď idem vo vlaku a urobím prudší pohyb tak na chvíľku čaká na I/O ale nič hrozné.

[Dragon Jake]

Než jsem vyladil treshold, tak je pravda, že při venkovním pochodu jsem si MP3ek moc neužil :D

[brk]

Tak, tak. Je to přesně ono. Zrovna jsem to zkusil. Docela příjemná změna, že kvůli tomu už nemusím patchovat jádro.

[mirec]

No tak zase to emerge --config app-laptop/hdapsd nie je až také hrozné. Podstatné je mať hdapsd z overlaya sectools (kde je to najnovšie).

[Jakub Lucký]

No ale do 2.6.28 to defaultně neumělo parkovat hlavičky

[saly]

Prý tam má být driver pro mojí TV, so let's go compiling! :-P

P.eS.: Jestli to půjde, tak budu mít vše out-of-box s Linuxem

[Tomáš Bžatek]

Zkousel jsem novy jaderny GEM spolu s git snapshoty xf86-video-intel a mesy a vysledky jsou vice nez prekvapive - narust vykonu ve vsech (3D) aplikacich mezi 50% a 100%. Tesim se na stable releasy X.org a Mesy v lednu/unoru.

[Roger]

Zkousel jsi server 1.6? Mela by tam byt o dost rychlejsi EXA (prepracovani nejakeho seznamu na pole (konstantni cas) a snad i glyphcache).

[H4wk]

Jů, tak to se taky těším, já mám X3100 a se stávajícími ovladači mi dost často shodí celý kernel.

[belisarivs]

To zni skvele. Ja snad upgraduju na JJ uz ted.

[Dusan]

Hm podľa tohoto

http://sourceforge.net/mailarchive/forum.php?thread_name=21d7e9970808260102g25916effh1e027ed153bffe60%40mail.gmail.com&forum_name=dri-devel

bude gem aj pre ATI driver super hlavne sa teším na exa a jeho vylepšenú akcelráciu.

A hlavne dúfam že v MDV 2009.1 toto bude defaultne.

[gtz]

Ext4 je velice zajimava jak na rychlost tak na velikost celeho FS , ale zabyval se jiz nekdo nejakou "sofistikovanou Obnovou" dat z tohoto FS ?