Krótki instruktaż systemd: punkty (auto)mountowania (08 sierpnia 2010, 13:05:17)
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.
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?