Linus Torvalds powiadomił na Linux Kernel Mailing List o wydaniu nowej wersji jądra.
Jak powiedział Linus w znanym sobie stylu, „nie ma tu nic ciekawego”. Nowe jądro przynosi jednak oczywiście wiele zmian. Pełen dziennik zmian dostepny jest na stronie Kernel Newbies.
W nowym jądrze pojawił się m.in. system plików LogFS, dedykowany masowym pamięciom flash (SSD, pendrive), liczne poprawki w systemie plików Btrfs, funkcja przełączania GPU – niektóre komputery posiadają dwie karty graficzne – jedną dla podstawowej pracy np. z pakietem biurowym, drugą dla wydajniejszych zadań jak np. obróbka wideo czy granie w gry trójwymiarowe. Dzięki nowemu mechanizmowi wydajniejsza karta nie będzie cały czas aktywna, dzięki czemu nie będzie niepotrzebnie eksploatowana, pobierając tylko zbędną energię, co jest szczególnie istotne w komputerach przenośnych.
Aktualizacji poddano także sterowniki systemów plików takich jak: XFS, Exofs, GFS2, Squashfs, FAT.
Co jak co ale czy już nie za dużo jest systemów plików w liuxie ? Nie lepiej stworzyć po 1 systemie dla zadań danego typu ? Zamiast kilku stworzonych w podobnych celach ?
Z punktu widzenia konsumentów może i to za dużo. Wystarczy jednak popatrzeć, jakie firmy są związane w mniejszym lub większym stopniu z danym system plików: GFS2 (Redhat), Btrfs (Oracle), Exofs (IBM).
Natomiast LogFS to kolejna próba stworzenia sensownego systemu plików w oparciu o tzw. strukturę "log" (sensownego polskie tłumaczenia nie znam) – odsyłam do Wikipedii ;). Poprzednie jak NILFS, LFS, JFFS2 do udanych raczej ciężko zaliczyć.
XFS natomiast charakteryzuje się dobrą wydajnością w przypadku dużych plików, więc swoje zastosowania też ma.
Eh, chyba zmęczenie daje o sobie, bo pełno błędów w mojej wypowiedzi. Sens także gdzieś umknął :/
Jeżeli stawiam na wydajność to XFS, jeżeli na żywotność napędu flash to LogFS, jeżeli na bezpieczeństwo przed utratą danych (awarie prądu itp) stawiam na EXT3. Tak można wymieniać w nieskończoność. Jak coś jest do wszystkiego to jest do niczego. Co prawda jak by wszyscy programiści od FS usiedli razem to by stworzyli coś idealnego co łączy w sobie wszystkie w/w cechy ale czy widziałeś kiedyś idealny samochód w teren, na wyścigi, do tego rodzinny i niezawodny? Ja nigdy 😉
@6ty: Wydajnosc ZFS-a w kluczowych operacjach jest wyzsza od czegokolwiek dostepnego pod Linuksem (m.in. dzieki mozliwosci uzywania cache devices oraz istnieniu ZIL-a), zywotnosc jest swietna, bo ZFS jest log-based, a bezpieczenstwo zostawia ext3 daleko w tyle ze wzgledu na przyklad na sumy kontrolne. Wiec, jak widzisz, da sie.
Tak, po prostu "kopie dupę" wszystkim 😛 http://manyeyes.alphaworks.ibm.com/manyeyes/datas…
Ten test był robiony w całości na Linuksie i ZFS był na fuse (nigdzie nie widzę opisu jak to było robione)? Bo jak tak to z tego co czytam zfs-fuse ma problemy np. z write cache.
Może niech porównają do ZFS na FreeBSD albo OpenSolarisie, gdzie jest on prawidłowo zaimplementowany?
@Bartek Krawczyk: hmmm- mylę się, czy news dotyczy LINUKSA? Co ma wydajność fs na BSD/Unix do fs na Linuksie. Ja wiem, że można porównywać cokolwiek z czymkolwiek- tylko po co takie porównanie?
@wojtekm: Po pierwsze, ten test to benchmark syntetyczny. Porownywanie wydajnosci systemow plikow na podstawie benchmarkow syntetycznych jest jak porownywanie predkosci samochodow na podstawie liczby cylindrow.
Sensowne wyniki mozna otrzymac tylko w benchmarku aplikacyjnym. Na przyklad stawiajac Oracle na jednym i drugim i porownujac wydajnosc.
Po drugie, ten benchmark byl robiony na kulawym, Linuksowym porcie ZFS-a uzywajacym FUSE.
Po trzecie, ten benchmark byl robiony na pojedynczym dysku, podczas gdy zalety wydajnosciowe ZFS-a, takie jak cache devices czy optymalizacje w raidz, ujawniaja sie przy wiekszej ilosci dyskow – ZFS robi "skroty", ktorych systemy plikow uzywajace tradycyjnego modelu 'filesystemu nad raidem' nie moga robic.
To było pytanie – nigdzie przy "benchmarku" nie napisane co, jak i na czym było testowane. Jaki związek ma NEWS (który tyczy się kernela…) z jakimś losowym benchmarkiem bez opisu i przedstawionej metodyki? Czytałeś w ogóle news?
Idąc Twoim tokiem rozumowania: Po co porównywać systemy plików w przestrzeni jądra oraz w przestrzeni użytkownika? Nie wiadomo wtedy, czy wynik zależy od samego FS czy od różnicy kernel/userspace…
I dodatkowo – jeśli ten test był na zfs-fuse, to nic nie mówi o samym ZFS tylko o tym czy fuse daje radę czy może ssie.
@Tomasz Woźniak: Zeby pokazac bzdurnosc tezy, jakoby lepsze bylo robienie oddzielnych systemow plikow do roznych zastosowan.
(Pewnym wyjatkiem tutaj sa systemy plikow przeznaczone do dzialania bezposrednio na flashu, bez flash adaptation layer, ktore jak najbardziej maja sens. Ich zastosowania sa jednak dosyc niszowe.)
Ciekawe co wyjdzie z Hammera 😉
Trasz: sprzeczność. Potwierdziłeś tezę mówiąc, że ZFS (jeśli chodzi o wydajność) ma sens jedynie na więcej niż jednym dysku.
@bies: Nie – napisalem, ze zalety ZFS-a najbardziej widac w konfiguracji z wieloma dyskami. Na jednym dysku wydajnosc jest tylko troche lepsza niz u konkurencji (dzieki ZIL-owi itd), natomiast na wiekszej ilosci dyskow roznica sie powieksza.
Wadą zfs są systemy wbudowane z małą ilością pamięci , ale tam o dziwno działają dobrze już stare wypróbowane FS jak FAT czy UFS 😉
W Linuxie nie, ale w jadrze tak.
Linus najlepiej podsumował te wydarzenie, a chyba redaktorzy nie załapali 😉 . Całe szczęście, że OSNEWS jest przygotowywany dla innego odbiorcy.
Możesz powiedzieć coś więcej?
Na wielu wortalach pojawiła się o tym informacja. Sądzę, że ludzie zbytnio się podniecają nowymi wydaniami. Ci naprawdę zainteresowani i tak dojdą.
Takie dojdą czy jakie?
Linus ogólnie często posługuje się sarkazmami i dowcipami. Jeden z moich ulubionych to
To takie typowo polskie, trzeba się do czegoś przyczepić. b.YISK pisze o wszystkim ;), więc może nie wyłapać czasem pełnego kontekstu. Każdemu może się to zdarzyć.
To, że tym razem Linus nie opisał, co tam mamy nowego od 2.6.33, można próbować różnie tłumaczyć, ale nie ma chyba potrzeby by to robić. Było coś o <code>-rc1</code>, a nie było np. oficjalnej wiadomości nt. <code>-rc2</code>, które Torvalds określił później mianem messy, przypisując poniekąd sobie winę za bycie zbyt pobłażliwym. Niemniej to właśnie po wydaniu <code>-rc3</code> zaczęło się jedno z największych polowań w ostatnim czasie na LKML (polecam lekturę z LWN: The case of the overly anonymous anon_vma). Spowodowało niemal tygodniowe opóźnienie wydania <code>-rc4</code>. Dalej już większych niespodzianek nie było: <code>-rc5</code>, <code>-rc6</code> i ostatni przed wydaniem finalnym <code>-rc7</code>. Może mu się zwyczajnie tym razem nie chciało, może wśród scalanych zmian nie zidentyfikował dla siebie żadnego kucyka, albo już sam się pogubił w tych zmianach?
W końcu są takie serwisy jak LWN (2.6.34 Merge window part 1, part 2), KN i inne…
Ja bym nie miał nic przeciwko, żeby ten komentarz zamienił się miejscami z treścią "newsa".
Interpretacja wyrwana z kontekstu. Przecież to jest cytat z ogłoszenia 2.6.34, gdzie nastąpiło podsumowanie zmian w stosunku do 2.6.34-rc6. Proponuję przeczytać dalej:
Chociaż posiadam teraz kartę graficzną nVidii (bo ma dobre stery pod Linuksem), to jednak kibicuję otwartym sterom do AMD Radeon 5XXX. Wie ktoś jaki jest poziom obsługi tych kart w nowym jajku?
Czy w jadrach powyzej 2.6.30 jest wersja 4-ta systemy plikow ReiserFS?
Jak sprawdzic jaka mam wersje?
Czy system plikow Reiser4 jest rozwijany?
a) Reiser4 nie ma w jądrze. Pewnie nigdy nie będzie bo na jego miejsce wchodzą btrfs & tux3 & syn
b) ReiserFS czy jądra? Jądra – uname -r. ReiserFS – mount is sprawdzić czy pisze reiserfs czy reiser4
c) Nie wiem. Zgaduje że trochę tak ale raczej nie ma siły przebicia.
Chwila! Z tego co wiem, to LogFS absolutnie NIE jest przeznaczony do urządzeń typu pendrive czy SSD, które udają urządzenia blokowe.
Jego miejsce jest tam gdzie JFFS, czyli "czyste" pamięci flash.
Bzdura! LogFS przeznaczony jest do pracy na "gołych" pamięciach Flash (samych chipach bez kontrolera) w systemach wbudowanych. SSD i pendrive są przystosowane do zwykłych systemów plików.
LogFS "przy okazji" dziala tez na urzadzeniach blokowych (SSD, pendrive) – co oczywiscie nie zmienia faktu, ze jest on dedykowany "golym" pamieciom flash.