После загрузки я запустился systemd-analyze blame
и вот результаты:
21.596s systemd-journal-flush.service
18.658s dev-sda8.device
15.099s dev-loop33.device
15.034s dev-loop19.device
15.012s dev-loop34.device
14.989s dev-loop21.device
14.877s dev-loop15.device
14.866s dev-loop26.device
14.773s dev-loop27.device
14.684s dev-loop30.device
14.677s dev-loop32.device
14.649s dev-loop35.device
14.590s dev-loop25.device
14.267s dev-loop23.device
14.192s dev-loop24.device
14.156s dev-loop29.device
14.133s dev-loop16.device
14.065s dev-loop31.device
14.059s dev-loop28.device
13.821s dev-loop20.device
13.531s dev-loop22.device
13.495s dev-loop14.device
13.364s dev-loop18.device
Что это за услуги dev-loopxx.device
( xx
обозначает номера) и почему они занимают так много времени? Они связаны с монтажом защелок? Можно ли сократить время загрузки, отключив их? Я использую Ubuntu 18.04 вместе с Windows 10.
Ответы:
Вы можете определить список всех установленных моментальных снимков
snap list
, для связи между точкой монтирования и именем моментального снимка, который вы можете использоватьsystemctl status
,mount
иlosetup
.Например, на моем Ubuntu MATE 18.04 LTS у меня установлены следующие снимки:
Они создают loop-устройства следующим образом:
Точки монтирования следующие:
Давайте посмотрим ближе на
dev-loop4.device
:Папка
/sys/devices/virtual/block/loop4
содержит очень полезный файлloop/backing_file
, мы можем прочитать его содержимое:Таким образом, мы просто определили, что
/dev/loop4
создаетсяcore
оснасткой.Но самый простой способ - использовать
losetup
(см.man losetup
):Надеюсь, это поможет лучше понять точки монтирования Snaps.
Итог: используя Snaps для обновления программного обеспечения, мы в конечном итоге платим за него более высоким сетевым трафиком, большим использованием диска и более медленным временем загрузки. Если вы вообще не хотите использовать Snaps, удалите их с помощью
sudo apt-get purge snapd
.источник