W obecnych czasach, rola przestrzeni wymiany w zasadzie ograniczyła się z grubsza do umożliwienia nam przeprowadzenia procesu hibernacji. Inne aspekty pracy systemu, w których SWAP brał udział zostały albo zepchnięte na margines (bardzo stare maszyny z niewielką ilością RAM), albo zupełnie wyeliminowane za sprawą nowszych technologi lub/i posiadania większej ilości pamięci operacyjnej w takich systemach. Obecnie domowy komputer z 32 GiB pamięci RAM to nic niezwykłego i przestrzeń wymiany na takich maszynach nie jest już nam w zasadzie do niczego potrzebna, bo raczej jest mało prawdopodobne, że nam tej pamięci zabraknie przy codziennym użytkowaniu naszego linux'a. Niemniej jednak, hibernacja systemu jest czymś pozytywnym z perspektywy użytkownika, bo umożliwia mu zapisanie stanu pracy przed wyłączeniem komputera i odtworzenie tego stanu po ponownym uruchomieniu systemu. Jeśli chcielibyśmy się cieszyć urokami hibernacji, to bez konfiguracji SWAP'a się nie obejdzie. Problem jednak zaczyna się, gdy mamy dysk SSD i taka przestrzeń wymiany zostanie na nim skonfigurowana. Chodzi generalnie o pewne aplikacje, które są w stanie generować bardzo dużo cache w pamięci operacyjnej, czego efektem będzie przenoszenie danych z RAM do SWAP, a to może bardzo szybko wykończyć taki nośnik flash. Dlatego też przydałoby się nieco zabezpieczyć przestrzeń wymiany przed tego typu sytuacjami, tak by można było jej używać jedynie w przypadku hibernacji.

Ostatnimi czasy, z racji rozwoju technologicznego, mamy do dyspozycji coraz to szybsze komputery, co przekłada się w znacznym stopniu na prędkość wykonywania operacji przez ich systemy operacyjne. Obecnie przeciętnej klasy desktop czy laptop jest już wyposażony w 16G czy nawet 32G pamięci operacyjnej (w niedługim czasie nawet smartfony będą posiadać 12G RAM). Spada zatem zapotrzebowanie wykorzystania dysku twardego jako pamięci RAM. W linux używanie dysku twardego jako rozszerzenie pamięci operacyjnej było i jest w dalszym ciągu realizowane za sprawą przestrzeni wymiany SWAP. Ta przestrzeń wymiany może być zaimplementowana w postaci osobnej partycji dysku twardego albo też jako plik umieszczony w obrębie systemu plików, np. ext4. Część dystrybucji linux'a decyduję się na porzucenie partycji wymiany na rzecz pliku SWAP. Czy taki krok jest uzasadniony i czy korzystając aktualnie z partycji wymiany powinniśmy zmigrować na plik SWAP?

Jak często zdarza się wam uruchamiać ponownie telefon czy smartfon? Raczej nikt z nas nie robi tego zbyt często, tak jak ma to miejsce w przypadku desktopów, laptopów i innych tego typu standardowych komputerów. System w smartfonie zwykle działa bez resetowania wiele tygodni czy nawet miesięcy, bo niewiele rzeczy instalujemy, no i praktycznie nic nie aktualizujemy. Dlatego też nie ma potrzeby uruchamiać ponownie Androida. Niemniej jednak są pewne przypadki, w których taki system jest w stanie zachowywać się bardzo dziwnie i restart smartfona zwykle poprawia zaistniałe problemy. Chodzi generalnie o utylizowanie baterii w większym stopniu, czy o ogólne uczucie spowolnienia pracy systemu. Przyczyn takiego stanu rzeczy może być cała masa ale w tym konkretnym przypadku znaczenie zdaje się mieć zbyt duże wykorzystanie pamięci RAM. W efekcie Android robi użytek z urządzenia ZRAM, które jest niczym innym jak tylko skompresowanym wycinkiem pamięci operacyjnej, gdzie system stara się upchnąć dane w przypadku kończenia się zasobów pamięci, a kompresja to przecież bardzo zasobożerny proces. Możemy taki telefon wyłączać co jakiś czas ale istnieje prostsza metoda wyeliminowania problemu.

Opisując mechanizm szyfrowania katalogu domowego przy pomocy narzędzia encfs , wspomniałem o problemie jaki powstaje przy jednoczesnym braku szyfrowania przestrzeni wymiany SWAP. Oczywiście, jeśli posiadamy w systemie dużą ilość pamięci RAM, to raczej nie potrzebna nam jest przestrzeń wymiany. Podobnie sprawa ma się w przypadku, gdy nie korzystamy z hibernacji. Natomiast, jeśli jedna z naszych partycji jest sformatowana jako SWAP i aktywnie z niej korzystamy, to niepełne szyfrowanie dysku, jakie zapewnia encfs może doprowadzić do skompromitowania zaszyfrowanych danych.

Każdy system operacyjny musi być przygotowany na ewentualność wyczerpania się pamięci operacyjnej RAM. W przypadku gdyby nie był, groziłoby mu powieszenie się. Są różne metody ochrony maszyn z linuxami na pokładzie przed tego typu sytuacją. Jedne z nich zakładają wykorzystanie wbudowanych w kernel mechanizmów takich jak choćby oom-killer, który ma za zadanie zabijać te najbardziej żarłoczne procesy. Są również bardziej łagodne sposoby na uchronienie komputera przed zbyt szybkim wyczerpaniem się pamięci i w tym wpisie omówimy sobie przestrzeń wymiany SWAP.