Krótki instruktaż systemd: punkty (auto)mountowania

RTFM: systemd.mount, systemd.automount

Do śmieci: fstab, mount ;)

Punkty mountowania po części są tworzone automatycznie (dla systemówych katalogów typu /sys/, /proc/, /selinux/ itd.), a po części z interpretacji pliku /etc/fstab. W tym drugim przypadku możemy zarządać montowania przy starcie systemu wpisując odpowiedni ciąg komentarza.

Zauważylem pewną niekonsekwencję przy zapamiętywaniu urządzenia do montowania. Przy podaniu UUIDu czasem systemd operuje na odnośniku do /dev/disk/by-[id,uuid]/, a czasem na urządzeniu:

 # grep /boot /etc/fstab 
UUID=6e958881-903e-4211-a686-4ca8083eaaac /boot                   ext4    defaults        1 2

# systemctl show -p What boot.mount
What=/dev/vda1

Przykład odmontowania:

# findmnt /boot
TARGET SOURCE    FSTYPE OPTIONS
/boot  /dev/vda1 ext4   rw,relatime,barrier=1,data=orde

# systemctl stop boot.mount
# findmnt /boot
# 

Przy definiowaniu punktu montowania można od razu podać uprawnienia, jakie mają być nadane katalogowi. Każdy punkt mountowania może być aktywowany dopiero w momencie dostępu. Używany jest autofs, a punkty automatycznego mountowania definiuje się w plikach z rozszerzeniem .automount.

W domyślnej konfiguracji pod nadzorem systemd jest kilkanaście systemów plików:

# findmnt
TARGET                         SOURCE                         FSTYPE      OPTIONS
/                              /dev/mapper/vg_dhartha-lv_root ext4        rw,relatime,barrier=1,data=orde
├─/proc                        /proc                          proc        rw,relatime
│ ├─/proc/sys/fs/binfmt_misc   systemd-1                      autofs      rw,relatime,fd=19,pgrp=1,timeout=300,minproto=5,maxproto=5,dir
│ │ └─/proc/sys/fs/binfmt_misc none                           binfmt_misc rw,relatime
│ └─/proc/bus/usb              /proc/bus/usb                  usbfs       rw,relatime
├─/sys                         /sys                           sysfs       rw,relatime
│ ├─/sys/kernel/debug          systemd-1                      autofs      rw,relatime,fd=17,pgrp=1,timeout=300,minproto=5,maxproto=5,dir
│ │ └─/sys/kernel/debug        debugfs                        debugfs     rw,relatime
│ └─/sys/kernel/security       systemd-1                      autofs      rw,relatime,fd=18,pgrp=1,timeout=300,minproto=5,maxproto=5,dir
├─/dev                         udev                           devtmpfs    rw,relatime,size=171468k,nr_inodes=42867,mode=
│ ├─/dev/pts                   devpts                         devpts      rw,relatime,gid=5,mode=620,ptmxmode=
│ ├─/dev/shm                   tmpfs                          tmpfs       rw,relatime
│ ├─/dev/hugepages             systemd-1                      autofs      rw,relatime,fd=15,pgrp=1,timeout=300,minproto=5,maxproto=5,dir
│ │ └─/dev/hugepages           hugetlbfs                      hugetlbfs   rw,relatime
│ └─/dev/mqueue                systemd-1                      autofs      rw,relatime,fd=16,pgrp=1,timeout=300,minproto=5,maxproto=5,dir
├─/cgroup                      tmpfs                          tmpfs       rw,nosuid,nodev,noexec,relatime,mode=
│ ├─/cgroup/systemd            cgroup                         cgroup      rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgro
│ ├─/cgroup/cpuset             cgroup                         cgroup      rw,nosuid,nodev,noexec,relatime,cpu
│ ├─/cgroup/ns                 cgroup                         cgroup      rw,nosuid,nodev,noexec,relatime
│ ├─/cgroup/cpu                cgroup                         cgroup      rw,nosuid,nodev,noexec,relatime
│ ├─/cgroup/cpuacct            cgroup                         cgroup      rw,nosuid,nodev,noexec,relatime,cpua
│ ├─/cgroup/memory             cgroup                         cgroup      rw,nosuid,nodev,noexec,relatime,mem
│ ├─/cgroup/devices            cgroup                         cgroup      rw,nosuid,nodev,noexec,relatime,devi
│ ├─/cgroup/freezer            cgroup                         cgroup      rw,nosuid,nodev,noexec,relatime,free
│ ├─/cgroup/net_cls            cgroup                         cgroup      rw,nosuid,nodev,noexec,relatime,net_
│ └─/cgroup/blkio              cgroup                         cgroup      rw,nosuid,nodev,noexec,relatime,bl
└─/boot                        /dev/vda1                      ext4        rw,relatime,barrier=1,data=orde

Poprzednio: Ścieżki; Następnie: Urządzenia i swap.

Archived comments:

sprae 2010-08-08 15:19:32

Systemd jest bardzo wygodny i elastyczny, ale chyba głównym jego założeniem jest agresywne zarządzanie demonami. Zastanawiamy się czy w dzisiejszych czasach na desktopie jest to opłacalne?
Wydaje nam się, że nacisk w takich podsystemach położony jest dziś na szybkość uruchamiania i szybką wygodną pracę.
Szybkość uruchamiania oprócz zmian w samym jądrze zapewnia [s/u]readahead.
Wygodną i szybką pracę po uruchomieniu zapewnia włącznie odpowiedniej ilości usług przy uruchamianiu. Readahead zapewnia i tak ich szybkie uruchomienie na starcie.
To dość proste i praktyczne rozwiązania powodujące, że oczekiwanie na system/konkretną usługę w łącznym rozrachunku znacznie się zmniejsza.
Tu pojawia się systemd z nieco akademickim podejściem "wyłącz to czego nie potrzebujesz". Czy to nie spowoduje, że oczekiwanie na system/usługi znacznie się nie wydłuży?
Problemem rozwiązania, które nazwałem "praktycznym" jest z góry założenie o wymaganej minimalnie ilości pamięci i profilowanie ilości usług do tego rozmiaru.
Wymyśliliśmy, że ciekawym rozwiązaniem systemd byłaby możliwość autoprofilowania. Zapewnić to można przez ustawianie priorytetów usług i konfiguracje ilości zajętej pamięci. Wtedy przy uruchamianiu włączałyby się wszystkie usługi wg priorytetów, aż do osiągnięcia zajętości pamięci.
Głównym problemem może być tu współpraca z readahead (czyli najprawdopodobniej jego kolejny fork wyposażony w profile ładowania).
Teraz pytanie. Czy systemd zapewnia już funkcjonalność pozwalającą na takie zastosowania?

zdz 2010-08-08 15:48:00

StopWhenUnneeded=
Takes a boolean argument. If true this unit will be stopped when it is no longer used. Note that in order to minimize the work to be executed, systemd will not stop units by default unless they are conflicting with other units, or the user explicitly requested their shut down.

Piszesz o desktopie, a to tylko jeden z wielu profili dzisiejszego Linuksa. Zauważ, że te z najmniejszą ilością zasobów jako pierwsze przeszły w całości na upstart. Mam tu na myśli komórki - Maemo/MeeGo, WebOS to rozwiązania upstartowe, czyli z włączaniem usług na żądanie.

Osobiście nie rusza mnie zupełnie przyspieszanie startu systemu - jest to coś, co robię raz na kilka miesięcy.
Natomiast profile o jakich mówisz... Wystartowanie wszystkiego spowoduje, że rzadziej używane usługi wylądują w swapie. A nie jestem do końca przekonany, czy wyciągnięcie czegoś ze swapa będzie szybsze niż uruchomienie od zera. W końcu strony w swapie są bardzo nieciągłe.
W tej chwili nie widzę możliwości startowania usług aż do wypełnienia RAMu.

sprae 2010-08-09 03:25:50

Piszę o desktopie, gdyż uważam, że pierwsze zaadoptuje to Fedora i przez jej pryzmat ludzie będą oceniali to rozwiązanie, tak jak przez pryzmat Ubuntu rozpatrują PulseAudio (które jest obecne nawet w Maemo5)

Wypełnianie pamięci to bardzo optymalna rzecz. Mam 4 GB, a Ubuntu wypełnia mi usługami jakieś 500 MB. Gdyby zrobić takie bardziej inteligentne narzędzie wypełniające 1/4 RAMu priorytetyzowanymi usługami to byłoby bardzo elastyczne dla szerokiej gamy komputerów.

Systemy takie jak Maemo (z którym jestem bardzo związany) mają własne dużo ciekawsze usługi zarządzania aplikacjami przez Dbus pozwalające wysyłać również stany urządzenia i niedopuszczają do zamykania aplikacji, chyba że zabraknie RAMu (podobnie jak w MacOS X). Ale do tego trzeba dostosować aplikacje o odpowiednią obsługę sygnałów Dbus.

HerrLeon 2010-08-11 14:02:58

fajny ten findmt , to twoj skrypt ?

zdz 2010-08-11 15:12:05

# rpm -qf `which findmnt`
util-linux-ng-2.18-3.fc15.x86_64