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컨테이너 (1)과 (2)는 위치 와 /foo/bar/b.txt위치가 동일합니다.길, 하지만 내용이 다를 수도 있습니다.

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

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

이는 물리적 시스템의 파일(제가 아는 바는 없음)이 한 가지 방식으로 저장되어 곳곳에 흩어져 있을 수 있음을 의미합니다. 그러나 "더미" 파일의 중앙 집중식 데이터베이스도 있습니다.운영 체제에서, 이와 같이:

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)

그럼 거기 있어요다른실제 파일의 운영 체제 데이터베이스는 다음과 같습니다.

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) 파일이 서로 다른 여러 파일에서 나올 수 있는 완전한 "파일 시스템" 가상 파일 시스템/컨테이너는 서로 덮어쓰지 않습니다.

그것이 작동하는 방식인지, 그렇지 않은 경우 실제로 작동하는 방식(또는 작동 방식에 대한 개요)이 궁금합니다.