Intereting Posts
Выполняет ли синхронизация команду удалить грязный кэш в памяти? Панель Gnome не содержит значков приложений, меню чата и меню питания удалите весь текст после определенного символа, который появляется на нечетных строках Возможно одновременное использование скобок (перестановки) и расширения массива? Преобразование файла ASCII с восьмеричными экранами для кодов UTF-8 в UTF-8 Найти файлы, содержащие одну строку, но не другую Как включить изолирование клиентов в wpa_supplicant? Ctrl + C завершение процесса без убийства терминала Как автофокусировать уже подключенные каналы в irssi с помощью / join? Выполнение программы, вызванной оболочкой, вызываемой crontab, возвращает код 127 Emacs показывает восьмеричные escape-последовательности для некоторых символов в файле UTF-8 Можно ли игнорировать каталоги __pycache__ в bash-complete и grep? Как предотвратить сбой моего экземпляра mysql ec2 micro instance mysql? rsync генерирует каталог назначения большего размера, чем источник? Каково поведение переключателя контекста в середине сигнала тревоги ()?

Понимание того, как пространства имен монтирования работают в Linux

Я читаю о пространствах имен монтирования и вижу:

в пространстве имен монтирования вы можете монтировать и размонтировать файловые системы, не влияя на файловую систему хоста. Таким образом, вы можете установить совершенно другой набор устройств (обычно меньше).

Я пытаюсь понять пространства имен linux , LXC и тому подобное, но я не совсем понимаю, что означает это утверждение выше.

Я пытаюсь понять, как контейнер (1) может иметь такие файлы:

/foo/a.txt /foo/bar/b.txt 

И другой контейнер (2) может иметь такие файлы:

 /foo/a.txt /foo/x.txt /foo/bar/b.txt /foo/bar/y.txt 

Где /foo/a.txt и /foo/bar/b.txt для контейнеров (1) и (2) имеют одинаковый путь , но, возможно, они имеют разное содержимое:

 # container (1) cat /foo/a.txt #=> Hello from (1) # container (2) cat /foo/a.txt #=> Hello from (2) 

Это будет означать, что файлы в физической системе (о которых я ничего не знаю) хранятся одним способом, возможно, разбросаны по всему. Но затем в операционной системе есть централизованная firebase database «виртуальных» файлов, например:

 db: container1: foo: a.txt: Hello from a from (1) bar: b.txt: Hello from b from (1) container2: foo: a.txt: Hello from a from (2) x.txt: Hello from x from (2) bar: b.txt: Hello from b from (2) y.txt: Hello from y from (2) 

Затем существует другая firebase database ОС для физических файлов, которая может выглядеть следующим образом:

 drive1: dir1: foo: a.txt bar: b.txt dir2: foo: a.txt x.txt bar: b.txt y.txt 

Поэтому, когда вы создаете файл в контейнере, вы фактически создаете 2 новые записи:

  1. 1 для карты физических файлов на уровне диска
  2. 1 для карты виртуальных файлов уровня контейнера

Вот как я себе это представляю. Вот как я могу видеть, что есть способ (1) представить пользователю (в контейнере LXC или cgroup (о котором я не знаю много)) то, что похоже на полную «файловую систему», в которой они могут (2) создать свою собственную полностью настраиваемую структуру каталогов (которая может иметь те же имена файлов / каталогов / путей, что и у совершенно другой виртуальной файловой системы), так что (3) файлы из нескольких разных виртуальных файловых систем / контейнеров не переопределить друг друга.

Хотите знать, как это работает, или, если нет, как это на самом деле работает (или набросок того, как это работает).

Пространства имен mount отличаются по расположению смонтированных файловых систем .

Это очень гибко, потому что монтирование может быть привязано монтированием подкаталога в файловой системе.

 # unshare --mount # run a shell in a new mount namespace # mount --bind /usr/bin/ /mnt/ # ls /mnt/cp /mnt/cp # exit # exit the shell, and hence the mount namespace # ls /mnt/cp ls: cannot access '/mnt/cp': No such file or directory 

Вы можете перечислить ваш текущий набор креплений с findmnt команды findmnt .

В полном контейнере корневое монтирование заменяется, и вы работаете с совершенно отдельным деревом монтирования. Это включает в себя некоторые дополнительные детали, такие как системный вызов pivot_root() . Вам, вероятно, не нужно точно знать, как это сделать. Некоторые подробности доступны здесь: Как выполнить chroot с пространствами имен Linux?