Я столкнулся с одним из тех aufs к overlayfs головным болям миграции. С aufs Вы могли указать, что несколько RO-слоев и обновляющий некоторые файлы в них были обновлены с перемонтированием.
fstab с aufs:
aufs /etc aufs noauto,br:/rw-root/etc=rw:/ro-root/etc=ro:/etc=rr 0 0
Та же функциональность с overlayfs:
none /.tmp-root/etc overlayfs noauto,upperdir=/ro-root/etc,lowerdir=/etc 0 0
none /etc overlayfs noauto,upperdir=/rw-root/etc,lowerdir=/.tmp-root/etc 0 0
Монтирование системы в порядке прекрасно, и все работает. Проблема возникает, когда я должен обновить что-то на ro-корневом разделе. Рабочее перемонтирование на этом рассматривает / и т.д. как уже смонтированный overlayfs а не исходный ro-корень. (Решенный striked проблема с mount --bind
)
По-видимому, проблема с inode
числа файлов. Так редактирование файла хорошо работает, но если я копирую новый файл по старому на более низком уровне, изменение не распространено. Таким образом, это могло быть реальной overlayfs проблемой.
Я действительно хотел бы, чтобы эта установка продолжила работать (реструктуризация, все - довольно большая работа и тестирование, которого я избежал бы, потому что это влияет на +50 virtualmachines). Однако я также приму ответы, которые выполнили бы движущийся корень только для чтения после initrd-этапный безопасно для обхождения этой проблемы и если это не возможно затем предложение большая часть минималистического способа изменения/изменения/создания initrd для выполнения этого перемещения.
Существует другой связанный вопрос, но это - более простая форма всего двух слоев. Простые overlayfs перезагружают вопрос
пытались ли вы сначала запустить remount на /.tmp-reoot/etc, а затем перемонтировать на / etc
, например:
mount -o remount /.tmp-reoot/etc
mount -o remount /etc