기존 디렉토리에서 마운트가 발생하는 이유는 무엇입니까?

마운트 지점 으로 기존 디렉토리가 필요 합니다 .

$ ls
$ sudo mount /dev/sdb2 ./datadisk
mount: mount point ./datadisk does not exist
$ mkdir datadisk
$ sudo mount /dev/sdb2 ./datadisk
$

디렉토리의 기존 내용을 오버레이하기 때문에 혼란 스럽습니다. 마운트 포인트 디렉토리에는 예상치 않게 전환 될 수있는 두 가지 가능한 컨텐츠가 있습니다 (마운트를 수행하지 않는 사용자의 경우).

mount새로 작성된 디렉토리에 발생 하지 않는 이유는 무엇 입니까? 그래픽 운영 체제가 이동식 매체를 표시하는 방법입니다. 디렉토리가 마운트 (존재)되어 있는지 또는 마운트되지 않은지 (존재하지 않는지) 분명합니다. 나는 정당한 이유가 있다고 확신하지만 아직 그것을 발견하지 못했습니다.

유출 된 구현 세부 사항의 경우입니다.

UNIX 시스템에서 모든 디렉토리는 inode 번호에 맵핑 된 이름 목록으로 구성됩니다 . inode는 파일, 디렉토리, 특수 장치, 명명 된 파이프 등인지 시스템에 알려주는 메타 데이터를 보유합니다. 파일이나 디렉토리 인 경우 시스템에서 디스크에서 파일 또는 디렉토리 내용을 찾을 위치를 알려줍니다. 대부분의 inode는 파일 또는 디렉토리입니다. inode 번호를 나열 하는 -i옵션 ls입니다.

파일 시스템을 마운트하면 디렉토리 inode가 필요하고 커널의 메모리 내 복사본에 플래그를 설정하여 "실제로이 디렉토리의 내용을 찾을 때이 다른 파일 시스템을 대신보십시오"라고 표시합니다 ( 이 프레젠테이션의 슬라이드 10 참조 ). 단일 데이터 항목을 변경하기 때문에 비교적 쉽습니다.

왜 새 inode를 가리키는 디렉토리 항목을 작성하지 않습니까? 이를 구현할 수있는 두 가지 방법이 있는데 둘 다 단점이 있습니다. 하나는 물리적으로 파일 시스템에 새 디렉토리를 작성하는 것입니다. 그러나 파일 시스템이 읽기 전용이면 실패합니다! 다른 하나는 모든 디렉토리 목록 프로세스에 실제로 존재하지 않는 "추가"항목의 목록을 추가하는 것입니다. 이것은 어리 석고 잠재적으로 모든 파일 작업에서 약간의 성능 저하를 일으킬 수 있습니다.

동적으로 작성된 마운트 지점을 원하면 automount시스템이이를 수행 할 수 있습니다. 디스크 이외의 특수 파일 시스템은 원하는대로 디렉토리를 만들 수도 있습니다 (예 : proc, sys등) devfs.

편집 : 내용이 있는 기존 폴더를 '마운트하면 어떻게됩니까?'에 대한 답변도 참조하십시오 .

마운트 지점이되도록 새 디렉토리를 작성 mount(2) 해야하는 경우 읽기 전용 파일 시스템에서 어떤 것도 마운트 할 수 없습니다. 그것은 멍청 할 것이므로 우리는 그것을 배제 할 수 있습니다.

mount 가 마운트 지점이 될 새 디렉토리를 선택적으로 생성 한 경우 이상합니다. 마운트 / 마운트 해제가 항상 발생하는 것은 아니므로 단일 시스템 호출로이 두 단계를 수행하기 위해 커널에 추가 논리를 추가하는 것은 중요한 속도 향상이 아닙니다. mkdir(2)원하는 경우 시스템 호출 을하려면 사용자 공간에 그대로 두십시오 . Dmitry의 답변 mount(2)은 두 가지를 모두 수행하면 원자가 아닌 것으로 만듭니다. 그리고 당신에게 여분의 인수 싶어 mount(2)모드 플래그가 좋아 함께이 open(2)들어, 소요 O_CREAT, O_EXCL등 그냥 사용자 공간을시키는에 비해 어리석은 것 그것을 할.

아니면 mount(8)( mount(2)시스템 호출 을하는 전통적인 프로그램 )이 이것을 하는 것에 대해 질문 했습니까? 가능할 수도 있지만 이미 mkdir(1)작업에 완벽하게 적합 하며 Unix의 디자인은 결합 가능한 훌륭한 작은 도구에 관한 것입니다. 두 가지를 모두 수행하는 도구를 원한다면 간단한 두 가지 도구로 해당 도구를 빌드하는 셸 스크립트를 쉽게 작성할 수 있습니다. 또는 muru가 udisksctl이미 언급 했듯이이 작업을 수행 할 필요가 없으므로 쓸 필요가 없습니다. 또한 mount(8)util-linux 의 일반적인 Linux 는 옵션이 파일 시스템에 전달되는 옵션이 아니라 사용자 공간 옵션에 대한 구문 mount -o x-mount.mkdir[=mode]사용을 지원합니다 x-.

더 흥미로운 질문 : 왜 부모 파일 시스템에 디렉토리가 있어야 하는가?

pjc50의 답변이 지적한 것처럼 (내 이니셜이 있지만 관계 없음) 디렉토리 목록에 마운트 포인트가 표시되면 모든 추가 검사가 필요합니다 readdir().

마운트 지점을 포함하는 디렉토리 (부모 FS)에 디렉토리로 존재하는 것은 좋은 방법입니다. readdir()마운트 지점이라는 것을 전혀 알 필요가 없습니다. 마운트 지점이 경로 구성 요소로 사용되는 경우 에만 발생 합니다 . 물론 경로 확인은 경로의 모든 디렉토리 구성 요소에 대한 마운트 테이블을 확인해야합니다.

기존 디렉토리에 마운트하면 mount실질적으로 원 자성을 호출합니다 . 최소한 사용자의 관점에서 볼 때 성공하거나 실패합니다. 경우 mount마운트 지점 자체를 만들 수 있었다, 그것이 불가능 다시 깨끗한 롤을 보장하고, 실패의 두 점을 가질 것이다. 다음 시나리오를 상상해보십시오.

1. mount 탑재 지점을 성공적으로 만듭니다.
2. mount 새 파일 시스템을 해당 디렉토리에 마운트하려고 시도하지만 실패
3. mount 마운트 포인트를 제거하려고하지만 실패

시스템은 고장의 부작용으로 끝납니다 mount.

다른 하나는 다음과 같습니다.

1. umount 파일 시스템을 성공적으로 마운트 해제합니다
2. umount 마운트 포인트를 제거하려고하지만 실패

이제 umount성공 또는 실패를 반환 해야 합니까?

발생할 수있는 또 다른 경우 :

부팅 할 때 기본 읽기 전용 이미지는 루트 디렉토리에로드됩니다. 따라서 실제 루트를 고치려고 할 때 재정의하고 싶습니다. 마운트 syscall이 ro마운트 포인트를로 바꾼다고 상상할 수 있습니다 rw.

여기서 루트 마운트 포인트에 파일 시스템 문제가 있다고 가정하고 복구하려고합니다. 마운트 오버랩을 사용하면 파일 시스템을 마운트 해제하고 fsck제공된 기본 이미지를 사용하여 파일 시스템 을 해결할 수 있습니다.

이 기능은 ro파티션과 파티션 간의 변경을 추적하기 위해 강력한 보안이 필요한 시스템에서도 유용 할 수 있습니다 rw.

항상 궁금했습니다.

다음과 같은 간단한 래퍼 :

#!/bin/sh
eval "mkdir -p \"\$$#\"" 
/bin/mount "$@"  

PATH에서 mount재정의 /bin된 디렉토리에 명명 된 실행 가능한 스크립트로 저장 하면 너무 많이 신경 쓰면 이것을 처리해야합니다.

실제 mount바이너리를 실행하기 전에에 대한 마지막 인수의 이름을 딴 디렉토리가 생성됩니다 mount(해당 디렉토리가없는 경우).

또는 mount래퍼 호출 실패로 디렉토리를 작성 하지 않으려는 경우 다음을 수행 할 수 있습니다.

#!/bin/sh
set -e
eval "lastArg=\"\$$#\""
test -d "$lastArg" || { mkdir "$lastArg"; madeDir=1; }
/bin/mount "$@"  ||  {  test -z "$madeDir" || rmdir "$lastArg"; }