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
Comments
Comments powered by Disqus