Prawa rynku są nieubłagane, a historia lubi się powtarzać, dlatego też po ośmiu wersjach kandydujących do wydania dostaniemy albo finalne oznaczone numerem 2.6.29, w co sam jeszcze tydzień temu wierzył Linus, albo też piąty raz z rzędu będzie wcześniej wersja RC9. Przewiduję, że jeszcze dziś lub jutro Linus wykona jakiś ruch. Jakiej decyzji nie podejmie kształt linii 2.6.29 nie ulegnie już zmianie. Czy mamy więc za co dziękować zespołowi z fińskim władcą kerneli na czele? Czy nazwy Btrfs, Squashfs lub Tuz staną się rozpoznawane?
Już teraz zdradzę, że najprawdopodobniej nic nowego tu nie przeczytasz droga Czytelniczko (ewentualnie drogi Czytelniku, ale po co miałbyś tu zaglądać skoro Pudelek jest dalece ciekawszy), bo tak naprawdę już wszystko od dawna wiadomo. Skoro jednak możemy informować o każdej nowej wersji Wine niezależnie od miejsca po przecinku, na którym występuje zmiana, nie popełnię większego faux pas opisując tu krótko różnice w stosunku do gałęzi 2.6.28. Z góry przepraszam, ale wyliczę tylko malutki procent zmian.
Zacznijmy od sprawy obiektywnie najważniejszej. W dzisiejszych czasach liczba rdzeni w procesorach szybko wzrasta, 4 rdzenie to już prawie standard. Tym samym obsługa 4096 procesorów to rzecz, którą każdy Kowalski musi docenić. Było to możliwe dzięki rozwiązaniu problemów związanych z wielkością struktur reprezentujących informacje o każdym z CPU (chodzi o kod dotyczący struktur cpumask), która to prowadziła do błędów przepełnienia stosu oraz negatywnie wpływała na wydajność platform mniej zasobnych w centralne jednostki przetwarzania. Tym samym domyślne jądra w dystrybucjach obsługiwały znacznie mniejsze liczby potencjalnie współegzystujących procesorów, przez co Kowalski zmuszony był wybierać systemy giganta z Redmond. Nigdy więcej!
Warto nadmienić w tym kontekście, że został wreszcie naprawiony obecny od dawna problem wydajnościowy implementacji klasycznego mechanizmu RCU (ang. Read-Copy-Update), który nie był projektowany dla maszyn z większą liczbą CPU aniżeli 16-32. Osiągnieto to poprzez wprowadzenie skalowalnej, hierarchicznej wersji opartej na modrzewiu (ang. the larch) nazwanej Tree RCU. Stary mechanizm wciąż pozostaje obecny, ale jego dni bez wątpienia zostały już policzone. Żądnych szczegółów odsyłam do artykułu publikowanego na LWN jakiś czas temu pod tytułem: Hierarchical RCU.
Kontrolerowi pamięci też się dostało. Dostał we władanie zarządzanie przestrzenią wymiany (ang. swap). W poprzednich wersjach kernela pojedynczy proces mógł “zagarnąć” całego swapa, jednak teraz można nadawać limity na użycie pamięci i przestrzeni wymiany grupom kontrolnym (ang. cgroup), czyli zbiorom zadań i ich przyszłym potomkom. Używając tego mechanizmu narażamy się na pewne koszty, w tym zwiększone zużycie pamięci, dlatego nowa funkcjonalność nie jest obligatoryjna. Natomiast OOM-Killer stał się bardziej powściągliwy i unika konfrontacji z biednymi, pozbawionymi wszelkich szans procesami tak długo jak tylko może. W końcu wmawia nam się, że resocjalizacja złoczyńców jest zasadna…
Znalazło się coś także dla dużo większych graczy, dla których utrata jakichkolwiek danych może być tragiczna w skutkach. Specjalnie dla nich pojawił tryb systemu plików Ext4, w którym księgowanie jest wyłączone (ang.
Pozostańmy w temacie systemów plików. Btrfs jest pewnego rodzaju odpowiedzią na ZFS dostępny w (Open)Solarisie. W przyszłości ma wyprzeć linię Ext*. Niestety nie jest to jeszcze produkt nadający się do stosowania “na produkcji”, jak to się przyjęło mówić, gdyż nie grzeszy stabilnością. Warto zauważyć, że stoi za nim Oracle (zasadniczo w postaci Chrisa Masona, który wcześniej już przez kilka lat pracował nad Reiserfs v3). Choć wykorzystuje koncepcje obecne w bazach danych, tym razem na szczęście nie musimy wykupywać nowej opcji do wersji EE po cenie tylko nieznacznie przekraczającej cenę samej bazy. Można powiedzieć więc, że oszczędzamy szacunkowo blisko 50 000 USD. Dużo, więc wymieńmy jego cechy za btrfs Wiki:
- przechowywanie plików w ekstentach, czyli ciągłych obszarach danych (ang. extent based file storage)
- pakowanie małych plików pod kątem efektywnego wykorzystania przestrzeni,
- efektywne objętościowo indeksowanie katalogów,
- dynamiczna alokacja i-węzłów (ang. i-node)
- zapisywalne snapshoty (ang. writable snapshots),
- podwolumeny, czyli oddzielne wewnętrzne korzenie systemu plików,
- paskowanie (ang. stripping) i tworzenie lustrzanych odbić (ang. mirroring) na poziomie obiektów,
- sumy kontrolne na danych i metadanych (dostępnych jest wiele algorytmów),
- kompresja,
- zintegrowane wsparcie dla wielu urządzeń udostępniające wiele algorytmów RAID,
- sprawdzanie systemu plików na żywo w trakcie jego używania,
- bardzo szybkie sprawdzanie nieużywanego (niezamontowanego) systemu plików,
- wydajne tworzenie przyrostowych kopii zapasowych (ang. incremental backup) i mirrorowanie systemu plików,
- defragmentacja systemu plików w trakcie jego działania.
Squashfs to kolejny akcent. Bez wnikania w szczegóły można powiedzieć, że jest to skompresowany (opiera się na algorytmie deflate – w przyszłości ma to być także efektywniejszy lzma – używanym zarówno do plików jak i i-węzłów oraz katalogów), tylko do odczytu i już teraz stosowany przez większość dystrybucji LiveCD system plików. Włączenie go do jądra można uznać za pewnego rodzaju formalność. Jego strona domowa to: http://squashfs.sourceforge.net/.
Idąc dalej mamy usprawnienia w eCryptfs implementującym przezroczyste szyfrowanie zawartości plików, a teraz także ich nazw. Tracąc klucz nie tylko utracimy dostęp do danych, ale w przypadku krótkiej pamięci (naszej, tzn. ludzkiej) nie będziemy nawet wiedzieć co utraciliśmy, co pozwoli wielu użytkownikom spać spokojniej. Dla niewtajemniczonych jest to rozwiązanie wywodzące się od Cryptfs, bazującego na infrastrukturze FiST (ang. File System Translator) pozwalającej na budowanie połączonych w stos systemów plików. Cryptfs został rozszerzony przez eCryptfs o zaawansowane zarządzanie kluczami i zabezpieczeniami. Kryptograficzne metadane są trzymane w nagłówku każdego zaszyfrowanego pliku, co pozwala na swobodne kopiowanie ich między maszynami w nienaruszonej postaci. Do deszyfrowania plików potrzebujemy rzecz jasna klucza (jak i do uprzedniego szyfrowania). Nowością jest tu szyfrowanie nazw plików. Potrzeba deszyfrowania jest wykrywana na podstawie ustalonych przedrostków w nazwach, które wskazują konieczność deszyfrowania pozostałej części nazwy. W przypadku bardzo długich nazw plików (bliskich limitowi długości) szyfrowanie nazwy nie powiedzie się z powodu wspomnianego narzutu. Strona projektu to: https://launchpad.net/ecryptfs.
Ostatnia rzecz dotycząca systemów plików, która nikogo nie ucieszy to zamrażanie systemu plików (ang. filesystem freeze). Jest to zbędna próba usunięcia drobnego braku w głównym linuksowym systemie plików, jakim jest Ext3, który to nie pozwalał na robienie backupu zachowującego spójność systemu plików poprzez mechanizmy oferowane przez urządzenia magazynujące (takie jak replikacja czy tworzenie snapshotów) gdy był zamontowany. Takashi Sato dodał niezbędne ioctlki i wprowadził konieczne zmiany w podsystemie plików jak i w samych systemach plików chcąc odebrać tym komercyjnym (jak VxFS) pomijalną liczbę użytkowników. Godne pochwały.
Obsługa technologii WiMAX ucieszy z pewnością administratorów małych sieci osiedlowych. Nareszcie, bez większych problemów będą mogli wykorzystać ją do bezprzewodowego przesyłania terabajtów filmów, empetrójek i innych równie poufnych danych. Współwinny jest tutaj Intel, który udostępnił stos komponentów przestrzeni jądra i użytkownika niezbędnych do obsłużenia tej usługi. Strona projektu to http://linuxwimax.org/.
Bezprzewodowe rozwiązania to nie tylko WiMAX. Praca w trybie punktu dostępowego (ang. access point) jest wreszcie dostępna w stosie wifi, ale wymaga hostapd do zarządzania przetwarzaniem ramek, a konfiguracja jest możliwa tylko z poziomu cfg80211. Zapomnij o iwconfig w tym przypadku!
Czas na sześć słów o Kernel Modesetting. Jest, ale tylko w intelowskich sterownikach. Teoretycznie możnaby zakończyć w tym miejscu akapit, w końcu sprawa toczy się już prawie 2 lata, więc nie sposób było się z nią nie zetknąć. Jednak dopiero ostatnio nabrała tempa dzięki długo wyczekiwanemu włączeniu do linii 2.6.28 GEM-a (ang. Graphics Execution Manager) będącego zarządcą pamięci w podsystemie graficznym, z którego omawiany mechanizm korzysta. W telegraficznym skrócie Modesetting wprowadza jedno miejsce w kodzie odpowiedzialne za ustawianie aktualnie działającego trybu karty graficznej (lub zintegrowanego modułu na płycie głównej), przez co cały stos graficzny staje się mniejszy, a we wprowadzonym kodzie łatwiej o zapewnienie jego wysokiej jakości. Jest to rozwiązanie stosowane praktycznie we wszystkich komercyjnych systemach operacyjnych, ale wymaga jeszcze stosownych modyfikacji po stronie sterowników graficznych i prace nad tym trwają. Efektem będzie brak konieczności uruchamiania X-ów z poziomu superużytkownika (sterowniki nie będą już potrzebowały bezpośredniego dostępu do sprzętu), brak “migotania” przy przełączaniu między konsolą a trybem graficznym i brak problemów z grafiką przy usypianiu i wznawianiu systemu. Czekaliśmy tyle lat to kolejne miesiące nas nie zbawią.
Czekamy też na inne rzeczy, jak szybkie bootowanie. Zadziwiające, ale i na tym polu jest postęp. Mowa o czymś, co zostało nazwane Fastboot i póki co nie jest domyślnie włączone (powód?). Więcej o asynchronicznych mechanizmach jakie wprowadza Fastboot można przeczytać w artykule na LWN: An asynchronous function call infrastructure.
A teraz coś z zupełnie innej beczki. Przegrał brzydki Tux (plotki głoszą, że uciekł na wspomniany wcześniej modrzew), wygrał walkowerem piękny Tuz! Powiedzmy sobie szczerze, pingwin nie miał szans w walce z diabłem tasmańskim, mimo że ten ostatni jest gatunkiem zagrożonym. Większość z nas i tak ma już dość tych pokracznych pingwinów, więc zapewne tylko garstka zapłacze nad wynikiem tego pojedynku. Z niecierpliwością wypatrujemy Tuz Racera.
Byłbym zapomniał. Przekroczono też liczbę 11 milionów linii we wszystkich plikach dostępnych w paczce z jądrem, której niestety jeszcze nie ma. To chyba najlepszy powód do ściągnięcia jak tylko będzie dostępna, kompilacji i wyczekiwania na najbliższy kernel panic. Miłego debugowania!
Czy ogarnia Cię zmęczenie po przeczytaniu tego wszystkiego (mówiłem, że nie warto tego robić) równie mocno jak mnie po napisaniu? Cieszę się, ale pamiętaj, że to tylko nieudolny wstęp przed konieczną lekturą finalnego ChangeLoga, na którego pojawienie się wszyscy czekamy. Co Cię nie zabije, to Cię wzmocni. 🙂
Aktualizacja:
Już wiadomo, że ustanowiony ostatnimi wydaniami precedens “dobijania” do -rc9 nie dotyczy linii 2.6.29. Czy to dobrze dowiemy się w najbliższych dniach po morderczych (dla naszych komputerowych podzespołów) kompilacjach. Najważniejsze jednak jest to, że wreszcie możemy zatopić się w spokojnej lekturze 7-megabajtowego ChangeLoga, nieprawdaż?
Dodaj komentarz