udev

Wybudzanie linux'a ze stanu uśpienia za sprawą myszy

Parę dni temu na jednych z forów, które czasem odwiedzam, pojawił się wątek dotyczący problemu jaki może nieść ze sobą budzenie linux'a ze stanu uśpienia/wstrzymania (Suspend to RAM, STR) za sprawą myszy. O ile w przypadku klawiatury sprawa wybudzania komputera zdaje się być dość oczywista, to w przypadku tego małego gryzonia już niekoniecznie, bo wystarczy lekko mysz przemieścić po blacie stołu czy innego biurka i system się nam wybudzi. Część komputerów ma stosowne opcje w BIOS/UEFI i można za ich sprawą skonfigurować to jakie urządzenia będą mieć możliwość wybudzania systemu. Niekiedy jednak, opcje w BIOS są tak ubogie, że nie mamy możliwości skonfigurowania tego aspektu pracy naszej maszyny. Trzeba zatem w nieco inny sposób podejść do tego zagadnienia. Na necie można się spotkać z radami odnośnie zapisu pliku /proc/acpi/wakeup przez przesłanie do niego czteroznakowych kodów, np. EHC1 czy USB1 . Takie rozwiązanie może nieść ze sobą negatywne konsekwencje i powinno się go unikać. Lepszym rozwiązaniem jest napisanie reguły dla UDEV'a dla konkretnego urządzenia, gdzie będziemy mogli łatwo sterować (przez plik power/wakeup ) tym czy dane urządzenie ma mieć możliwość wybudzania systemu czy też nie.

Stałe nazwy urządzeń w OpenWRT (hotplug, udev)

Bezprzewodowy router WiFi to w miarę proste urządzenie, które w zasadzie realizuje kilka podstawowych aspektów pracy sieci domowej. Wielu użytkownikom jednak jest nieustannie potrzebna jakaś nowa funkcjonalność, której oryginalny firmware producenta nie oferuje. Dlatego też mamy do dyspozycji OpenWRT będący minimalistyczną formą bardziej rozbudowanej dystrybucji linux'a. Może i OpenWRT daje nam możliwość zaawansowanej konfiguracji naszej sieci ale tego typu opcja powoduje też szereg problemów. Chodzi o to, że kernel dynamicznie tworzy nazwy dla wszystkich podłączanych urządzeń do routera. W dużych dystrybucjach linux'a do ogarnięcia tych nazw wykorzystywany jest UDEV. W przypadku OpenWRT też możemy skorzystać tego mechanizmu. Jeśli jednak mamy niewiele miejsca na pamięci flash routera, to możemy też skorzystać ze zdarzeń hotplug. W tym wpisie postaramy się przepisać nazwy pendrive/dysków twardych oraz modemów USB (LTE), tak by ich kolejność podłączania do routera nie stwarzała problemów w konfiguracji.

Zmiana nazwy interfejsu modemu ttyUSB0

Spora część osób posiada różnego rodzaju urządzenia do komunikacji GSM/UMTS/LTE. Mogą to być smartfony, czy też modemy USB. Zwykle po podpięciu takiego urządzenia do portu USB, system wykrywa je i oddaje nam do dyspozycji kilka interfejsów w katalogu /dev/ . W przypadku modemu Huawei E3372s-153 w wersji NON-HiLink, standardowo są dwa interfejsy: ttyUSB0 oraz ttyUSB1 . Gdy podłączamy tylko jedno urządzenie, to nie mamy problemy z tymi nazwami. Co się jednak stanie w przypadku, gdzie tych urządzeń będzie więcej i podepniemy je w losowej kolejności? Nawet jeśli będziemy wiedzieć które interfejsy są od jakich urządzeń, to i tak trzeba będzie przepisywać pliki konfiguracyjne różnych aplikacji pod kątem dostosowania tych nazw. Możemy jednak stworzyć unikalne nazwy interfejsów w oparciu o reguły udev'a i tym zajmiemy się w niniejszym wpisie.

Jak zwiększyć prędkość zapisu w urządzeniach USB

Przeglądając sobie FAQ dotyczący urządzeń USB natknąłem się na punkt, który opisywał parametr max_sectors . Niby nic wielkiego, w linux'ie jest przecie pełno przeróżnych opcji, przy pomocy których jesteśmy w stanie zmienić szereg aspektów pracy naszego systemu operacyjnego. Rzecz w tym, że parametr max_sectors potrafi nawet dość znacznie poprawić wydajność urządzeń USB, w tym tych wszystkich pendrive'ach, w których prędkość zapisu pozostawia wiele do życzenia. W tym wpisie postaramy się nieco dostosować ten parametr, tak by przyśpieszyć transfer kopiowanych plików.

Przewidywalne nazwy interfejsów sieciowych

Podczas jednej z aktualizacji systemu został mi zwrócony pewien komunikat. Oświadczał on bowiem, że od jakiegoś czasu nazewnictwo interfejsów sieciowych w systemie uległo zmianie, oraz, że w wersji 10 debiana, ten obecny system nazw nie będzie już wspierany. Rozchodzi się o coś co nazywa się Predictable Network Interface Names, czyli przewidywalne nazwy interfejsów sieciowych. Jako, że aktualne wydanie stabilnego debiana ma numerek 8 i w niedalekiej przyszłości zostanie wydana 9, to przydałoby się już zacząć migrować na ten nowy system nazw. W tym wpisie dokonamy takiej migracji i zobaczymy jakie zmiany musimy poczynić, by nie doświadczyć problemów związanych z tą migracją nazw.

Parametr readahead w dyskach twardych

W celu optymalizacji swojej pracy i poprawy wydajności przy transferze danych, dyski twarde często odczytują więcej sektorów niż było to określone w żądaniu. Chodzi o to, że odczytywany przez nas z dysku plik jest podzielony na sektory i gdy dysk odczytuje pierwszy sektor tego pliku, to wczytuje także kilka kolejnych sektorów zlokalizowanych za tym, którego żądanie odczytania zostało właśnie zrealizowane. Te dodatkowe sektory trafiają do wewnętrznego cache dysku twardego, z którego mogą zostać odczytane w późniejszym czasie, jeśli zajdzie taka potrzeba. Dostęp do danych w cache jest o wiele szybszy w porównaniu do repozycjonownia głowicy i odczytywania fizycznych sektorów na dysku. W efekcie czego mamy zwykle dość znaczny wzrost wydajności przy transferze danych. Ten mechanizm nosi nazwę readahead i w tym wpisie przyjrzymy mu się nieco bliżej.

Parametr multcount w dyskach twardych

W manualu hdparm możemy przeczytać o opcji -m , która szerzej jest znana jako multcount. Obecnie praktycznie każdy dysk w większym lub mniejszym stopniu ma zaimplementowaną jej obsługę, tj. wartość tego parametru różni się i zwykle im większą, tym lepiej dysk powinien się sprawować. Nie wszystkie dyski mają tę opcję włączoną standardowo. Na przykład te z rodziny WDC, jak czytamy w dokumentacji, są znane z tego, że działają wolniej po jej ustawieniu. Jako, że mam dysk firmy Western Digital, to postanowiłem sprawdzić jak, o ile w ogóle, zmieni się wydajność takiego urządzenia po przestawieniu tego parametru.

Wyłączenie WoL w karcie sieciowej

WoL (Wake on LAN) to taki ficzer, który umożliwia włączenie komputera przez sieć. By tego typu sytuacja miała miejsce, zarówno karta sieciowa oraz płyta główna komputera musi wspierać WoL. Dodatkowo, BIOS maszyny musi mieć aktywowaną odpowiednią opcję. Obecnie WoL jest implementowany praktycznie w każdej płycie głównej i karcie sieciowej, także raczej możemy przyjąć, że nasz komputer może zostać wybudzony za pomocą kabla sieciowego. Stwarza to oczywiście zagrożenie bezpieczeństwa ale poza tym, w grę wchodzi także większy pobór energii. Jeśli nie korzystamy z WoL, to jest on dla nas zbędny i należałoby go wyłączyć.

Aplikowanie zmiennych sysctl przy pomocy udev'a

Kernele linux'owe mają dość sporo opcji, które możemy zmienić przy pomocy pliku /etc/sysctl.conf . Niby nic nadzwyczajnego ale co w przypadku tych zmiennych, które muszą być ustawione, z tym, że moduł, który stworzy odpowiednie ścieżki w katalogu /proc/sys/ , nie został załadowany z jakichś względów przy starcie systemu? Zmienne te nie zostaną ustawione, a w logu pojawi się komunikat informujący nas o nieodnalezieniu określonego pliku. Okazuje się, że jesteśmy w stanie aplikować określone ustawienia sysctl w momencie ładowania określonych modułów i temu mechanizmowi się przyjrzymy bliżej w tym wpisie.

Tryb oszczędzania energii w kartach WiFi na linux

Niektóre karty wifi znane są z tego, że niezbyt chcą one działać pod systemem operacyjnym linux. Nie jest to wina samego sprzętu, ani tym bardziej linuxa, tylko raczej faktu, że producent nie potrafi napisać pod ten OS odpowiednich sterowników. Czasem jednak pod względem programowym wszystko wydaje się być w porządku, tj. sterowniki zostały zainstalowane, są one dobrej jakości i karta działa praktycznie bez zarzutu. Niemniej jednak, strony www wydają się ładować jakoś tak ociężale, z pewnym opóźnieniem. Jeśli doświadczyliśmy tego typu zachowania ze strony naszej karty wifi, prawdopodobnie oznacza to, że ma ona włączony tryb oszczędzania energii (powersave).