Ограничения VDO / Virtual Disk Optimizer в стеке хранилища

Что ж, RHEL 7.5 выпущен с важным дополнением VDO, которое в основном добавляет сжатые и дедуплицированные тома с тонким выделением ресурсов, что здорово, и мы получим эти преимущества с производными и другими дистрибутивами также, поскольку технология была приобретена у Permabit и является открытым исходным кодом.

Согласно официальным документам ( https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/vdo- qs-requirements ) следует учесть некоторые соображения (раздел документа «Размещение VDO в стеке хранилища»):

Как правило общее , вы должны размещать определенные слои хранения под VDO и другие поверх VDO:

• В VDO: DM-Multipath, DM-Crypt и программный RAID (LVM или mdraid).
• Вверху VDO: кэш LVM, логические тома LVM, снимки LVM и LVM Thin Provisioning.

Ну, потому что это «общее» правило - я не вижу в этом проблем, и все в порядке. Далее мы видим следующее:

Следующие конфигурации не поддерживаются:

• VDO поверх томов VDO: хранилище → VDO → LVM → VDO
• VDO поверх снимков LVM
• VDO поверх LVM Cache
• VDO поверх устройства обратной связи
• VDO поверх LVM Thin Provisioning
• Зашифрованные тома поверх VDO: хранилище → VDO → DM-Crypt
• Разделы на томе VDO: fdisk, parted, и аналогичные разделы
• RAID (LVM, MD или любого другого типа) поверх тома VDO

Это своего рода «пугает», и мы должны тщательно продумывать дизайн, 04 LTS Server с использованием BTRFS и получил следующую настройку согласно / etc / fstab :

# <file system> <mount point>   <type>  <options>  <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=0841ef72-e9d4-45ca-af22-a403783859c6 /        btrfs   noatime,nodiratime,subvol=@ 0     1

# /home was on /dev/sda1 during installation
UUID=0841ef72-e9d4-45ca-af22-a403783859c6 /home    btrfs   noatime,nodiratime,subvol=@home 0 2

Это в значительной степени имеет смысл для меня, но привело к проблемам с моей установкой systemd. Я храню программное обеспечение для разных клиентов в / home , и некоторые из них предоставляют демонов, которые должны запускаться автоматически во время загрузки системы с помощью systemd. Примерно так:

/home/customer/someDaemon/cust_some_daemon.service

Это можно легко развернуть в systemd с помощью systemctl enable ... с абсолютным путем выше. Мне не нужно вручную копировать или связывать вещи, systemd все обрабатывает, systemctl enable ... просто завершается успешно, и ссылки создаются должным образом.

Что не работает, так это запуск этих служб во время загрузки, systemd дает сбой для всех этих служб с сообщением, что он больше не может найти связанные файлы. Если я не использую / home , но сохраняю эти файлы в / напрямую или удаляю @home , чтобы больше не быть дополнительным подтомом, все работает, как ожидалось.

В документах для enable есть следующее предложение:

Файловая система, в которой расположены связанные файлы модулей, должна быть доступна при запуске systemd (например, все, что находится под / home или / var недопустимы, , если только эти каталоги не расположены в корневой файловой системе ).

Мне не ясно, в чем именно заключается ограничение в данном случае: использование отдельного лица сам подтом или это потому, что его нужно было дополнительно смонтировать? / необходимо смонтировать, и они тоже являются субтомом, но, очевидно, поддерживаются. Особенно из-за динамического характера BTRFS и ZFS в отношении подтомов, я ожидал, что systemd по крайней мере поддерживает несколько подтомов в некоторой общей корневой файловой системе или пуле. Но он либо не работает, либо не может справиться с дополнительной точкой монтирования.

Так в чем именно заключается проблема? Спасибо!