Linus Torvalds ogłosił wydanie jądra Linux 3.2, które jest aktualizacją dla wydanego jądra Linux 3.1. Tym razem programiści poprzestali na siedmiu wersjach kandydujących, chociaż Linus chciał w razie problemów wydać RC-8. Nowa wersja przynosi jak zwykle wiele zmian, a w szczególności aktualizację sterowników, poszerzoną listę obsługiwanego sprzętu, usprawnienia dotyczące wirtualizacji i systemu plików, a także kilka zmian w sieciach.
Sieci
Korekty kursu
Deweloperzy jądra rozszerzyli stos TCP w jądrze Linux 3.2, w celu obsługi "Proportional Rate Reduction" (PRR). Algorytm został zaprojektowany w celu dostosowania prędkości transmisji ramek, które mogą być przetwarzane po drodze przez odbiorcę i routery. Jest to przydatne szczególnie podczas redukowania limitu transferu podczas nieoczekiwanego przeciążenia. Algorytm został zaprojektowany, aby przywrócić maksymalny transfer szybszy, niż poprzednio używana metoda , która jest opisana w RFC 3517 ("A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP").
Powołując się na wewnętrzne testy, algorytm szybszego transferu, jest w stanie zredukować czas odpowiedzi HTTP od 3 do 10 procent.
WiFi
Rok temu deweloperzy Broadcom przedstawili sterowniki WiFi - Brcmsmac i Brcmfmac Brcm80211. Jednakże nie zostały one wprowadzone ze względu na brak dopracowania. W tej wersji jądra w końcu będziemy mogli je zobaczyć, co powinno zaowocować większą liczbą obsługiwanych chipów.
Podsystem sieciowy zawiera teraz sterownik WiFi Ath6kl dla komponentu Atheros AR6003. Jest to znacznie ulepszona, szybsza i mniejsza wersja poprzedniego stosu, który został usunięty w tym samym czasie. Został on zaprojektowany poza głównym drzewem jądra Linux. Refaktoryzacji doczekał się również sterownik RTl8192e, jednakże nadal programiści czekają przed dołączeniem go do podsystemu sieciowego.
System plików
Wielkie Bloki
System plików Ext4 obsługuje teraz duże bloki alokacji. Technika znana, jako bigalloc, wiąże 4K bloki w celu użycia ich do przechowywania danych w klastrach o wielkości 1MB. Zmniejsza to obciążenie administracyjne przy zapisywaniu dużych plików i powinno znacznie poprawić wydajność w niektórych scenariuszach. Jest jednakże mniej opłacalny w gospodarowaniu przestrzenią dyskową, ponieważ każdy plik zajmuje cały dostępny klaster. Systemy plików z bigalloc mogą być stosowane z wydanym niedawno E2fprogs 1.42. Tworzy się je przez użycie komendy mkfs.ext4 i definiujące wymaganą wielkość klastra, używając nowe argumentu "-C".
Programista systemu plików ext Theodore 'tytso' Ts'o usunął stary algorytm alokacji bloków pamięci i dokonał dużej ilości zmian, które powinny ulepszyć reakcję Ext4, jeżeli użytkownicy określili wzajemnie niekompatybilne opcje montowania.
Solidniejszy Btrfs
Programiści dodali funkcje readahead do ciągle eksperymentalnego systemu plików Btrfs. Wsparcie scrub, wprowadzone w jądrze Linux 3.0 zostało ulepszone i powinno być znacznie szybsze. Kiedy zostaną znalezione uszkodzone bloki, funkcja scrub zwraca nazwy plików, która znajdowały się na tej przestrzeni, a btrfs będzie automatycznie dopasowywać tabele alokacji, bez wyraźnej potrzeby uruchamiania scrub w sytuacjach, kiedy zostanie napotkany błąd odczytu, ale może spełnić żądanie odczytu, za pomocą drugiej kopii danych.
Jeśli główny węzeł, kluczowy element Btrfs został uszkodzony, nowa opcja montowania -o recovery może zostać użyta, do poinstruowania systemu plików, w celu użycia alternatywnego węzła root. Jądra spróbuje wtedy użyć starej wersji węzła głównego i zamontuje stary stan systemu plików, pozwalając użytkownikowi na odzyskanie wszystkich danych, do jakich będzie dostęp poprzez tą metodę.
Wszystkie zmiany w wewnętrznych logach funkcji, mające usprawnić wydajność Btrfs zostały wyrzucone z jądra Linux 3.2, z powodu drobnych problemów. Chris Mason wyjaśnił owy problem na liście git.
Pomniejsze zmiany:
Dokonano kilku zmian w kodzie systemu plików CIFS, który odpowiada za udostępnianie zasobów Samba lub Windows. Powinno to znacznie usprawnić wymianę danych w niektórych sytuacjach.
Od jądra Linux 3.2 Objects Raid Engine (ORE) w Exofs będzie wspierał RAID 5. Exofs (EXtended Object File System) został zaprojektowany dla OSD (object storage devices). Jest to zarazem trzecia implementacja RAID 5 w jądrze. Btrfs oczekuje ewentualnej obsługi RAID 5 i niedawno była omawiana cała ścieżka włączania kodu.
Christoph Hellwig opisał kilka usprawnień do XFS, włączając w to optymalizację podczas wywoływania fsync na katalogach i redukując opóźnienia z sync.
