Там какая-либо причина состоит в том, чтобы переехать от fstab в systemd системе?
Если Вы используете bash, можно использовать ассоциативные массивы:
declare -A servers
servers=(
[box001]=box001.domain.com
[box002]=box002.domain.com
[box003]=box003.domain.com
[box004]=box004.domain.com
[box005]=box005.domain.com
)
for server in "${!servers[@]}" ; do
hostname="${servers[$server]}"
# do something with $server and $hostname
done
Порядок, что Вы выполняете итерации серверов, не определяется. Для вышеупомянутого примера в моей версии удара на моем хосте порядок является box001, box003, box002, box005 и box004. YMMV.
точки монтирования systemd поддерживают более гибкую конфигурацию, по крайней мере, когда смонтировать каждую точку. Это иногда полезно в действительно сложных проблемах с сетью, монтируется и т.д.
Как показывает опыт, Вы просто используете fstab, если Вы не застреваете с конфигурированием некоторого сложного поведения (если Вы когда-нибудь делаете), затем попытайтесь найти systemd решение.
Из самого man systemd.mount:
fstab
Mount units may either be configured via unit files, or via /etc/fstab (see fstab(5) for details). Mounts listed in /etc/fstab will be converted into native units dynamically at boot and when the configuration of the system manager is reloaded. In general, configuring mount points through /etc/fstab is the preferred approach. See systemd-fstab-generator(8) for details about the conversion.
Обратите внимание, что некоторые функции реализованы только для fstab. Например, когда systemd в initrd используется для монтирования файловой системы /usr, а также файловой системы /. systemd в initrd читает etc/fstab on/ и ищет запись для /usr.
Также можно использовать mount /mountpointвручную.systemdобычно рад, что вы это делаете, например. он будет обновлять статус модуля монтирования, когда вы размонтируете или смонтируете файловую систему.
Systemd — лучшее решение для монтирования, поскольку оно позволяет создавать зависимости при монтировании.
т.е. :Используя директиву After=в файле.mount, вы можете гарантировать, что монтирование LUN не произойдет до тех пор, пока оно не будет подключено в первый раз. Вот фрагмент скрипта, который я написал для автоматизации монтирования удаленного хранилища:
cat <<EOF> /etc/systemd/system/mnt-$ISCSIDISKMOUNTFOLDER.mount
[Unit]
Description=iSCSI Disk
After=connect-luns.service
[Mount]
What=/dev/disk/by-uuid/$(ls -al /dev/disk/by-uuid | grep $ISCSIDEVICE | awk '{print $9}')
Where=/mnt/$ISCSIDISKMOUNTFOLDER
Type=$FILESYSTEM
[Install]
WantedBy=multi-user.target
EOF
Монтирование происходило до запуска службы «connect -luns.service », но как только я подключил службу к директиве After=, хранилище теперь правильно поднялось -на ботинок. В этом случае Systemd предлагает очень простой и элегантный способ управления зависимостями в отношении монтирования удаленного хранилища.