장착 개념을 이해하는 데 어려움


13

모두 읽은 리눅스에서 장치를 장착 의미는 무엇입니까? OS에서 "마운트"를 개념으로 이해하면 다음 과 같은 문제가 있습니다.

액세스 가능한 모든 스토리지는이 단일 디렉토리 트리에서 연관된 위치를 가져야합니다. 이것은 파일 경로의 가장 일반적인 구문에서 스토리지 구성 요소 (드라이브) 당 하나의 디렉토리 트리가있는 Windows와는 다릅니다. 마운트는 저장 장치를 디렉토리 트리의 특정 위치에 연결하는 작업입니다.

그러나 디렉토리 계층 구조에있는 / dev / cdrom 아래에 cdrom 드라이브를위한 액세스 가능한 위치가 이미 있습니다. 그렇다면 왜 / media / cdrom 아래에 별도의 "마운트 포인트"를 만들어야합니까? / dev / cdrom에서 직접 액세스 할 수없는 이유는 무엇입니까? 장치 노드 파일은 일반 파일과 같다고 들었습니다. 그리고 읽고 쓰는 것은 일반적인 파일과 같습니다. 따라서 / dev / cdrom에서 액세스 할 경우 cdrom의 파일 시스템을 사용할 수 없습니다. 그리고 파일 시스템 계층 구조 (cdrom 내부)는 "마운트"할 때 "생존"합니까?

답변:


11

읽거나 쓰기는 / dev / cdrom을 (예를 들어, 사용 가능 dd또는 cat)하지만, 당신이 할 때 그냥 읽거나 장치의 원시 바이트를 작성하는 것이다. 이는 파티션 복제와 같은 다양한 상황에서 유용 할 수 있지만 일반적으로 장치에 저장된 디렉토리와 파일을보고 싶습니다.

장치를 마운트 할 때 기본적으로 커널에게 소프트웨어 계층 (파일 시스템 드라이버)을 사용하여 원시 바이트를 실제 파일 시스템으로 변환하도록 지시합니다. 따라서 장치를 마운트하면 해당 장치의 파일 시스템 이 디렉토리 계층 구조에 연결됩니다.


8

나는 이것을 다음과 같은 방식으로 생각합니다 : mount시스템이 일부 파일의 내용을 디렉토리 트리로 해석하도록 지시하는 도구입니다.

  • 파일 시스템에는 디렉토리와 파일이 있으며 각 파일은 바이트 문자열에 대한 레이블입니다.
  • /dev/cdrom 파일이며 CD에 저장된 바이트 문자열을 나타냅니다.
  • 이 매우 긴 문자열을 직접 읽을 수 있지만 특수 목적 (예 : 전체 디스크 이미지 작성)을 제외하고는 실용적이지 않습니다.
  • 이 긴 문자열은 추가 내부 구조를 갖습니다. 여기에는 파일 시스템이 포함되어 있으며이 디렉토리에는 파일과 디렉토리가 저장되어 있으며이 문자열의 위치는 어디입니까?
  • 를 사용 mount -t iso9660 /dev/cdrom /media/cdrom하면 시스템에 다음과 같이 말할 수 있습니다. "이 매우 긴 바이트 문자열을 가져 와서 /dev/cdromiso9660 형식의 디렉토리 트리로 해석하여 위치 아래에서 액세스 할 수 있도록합니다 /media/cdrom."
  • 실제로 이것은 일반 파일에도 적용됩니다. 디스크 이미지가 포함 된 일반 파일을 만든 다음이를 사용 mount하여 액세스 할 수 있습니다. 이 시도:
dd if = / dev / zero of = fs-image bs = 1M count = 50
mke2fs fs 이미지
sudo 마운트 fs 이미지 / some / mount / point

(이미지 파일을 준비 할 때 처음 두 명령은 처음에만 필요합니다.)


왜 필요한 mke2fs가요?
ADTC

이미지 파일 내에 빈 ext2 파일 시스템을 작성합니다. 빈 파일 시스템은 모두 0이 아닙니다. 빈 Word 또는 LibreOffice 문서의 크기가 0이 아닌 기본 글꼴 및 페이지 크기와 같은 정보가 들어있는 것처럼 메타 데이터와 고정 구조가 있습니다.
Krzysztof Kosiński

오, 그것은 잠재적으로 파괴적인 행동입니다. 이 명령은 최초 초기화에만 해당됩니다. :)
ADTC

5

/dev/cdrom장치 파일을 나타냅니다 . 입니다 하지 당신이 당신의 광 드라이브에 삽입 할 수있는 어떤 디스크의 내용이 아니라 그 하드웨어의 비트에 대한 참조입니다 (아마도 소프트웨어 드라이버) 당신이 당신에게 그것을 보여주기에 호출 할 수있다. 당신 mount /dev/cdrom이 당신의 나무에 어떤 경로에 당신 은 파일 시스템 에 그 내용 을 첨부 합니다 .

문제는-다른 방법으로 생각할 수는 없습니다. 비록 Windows에서는조차 분명 하지는 않지만 파일 시스템 추상화는 여전히 존재한다 \\?\volumename\. 그것이 어떻게 생겼는지 기억하는 데 잠시 시간이 걸렸으며, 나는이 인터넷 검색을 발견 했습니다 .

... 볼륨 이름은 실제 볼륨 장치를 가리키는 상징적 인 링크 일 뿐이며 일반적으로의 형식입니다 \Device\HarddiskVolume23. 드라이브 문자 인 MS-DOS 장치의 다른 예가 있습니다. 볼륨에 C : 드라이브 문자가있는 \\?\C경우, \Device\HarddiskVolumeXX형식 의 실제 볼륨을 가리키는 : 이라는 심볼릭 링크가 있습니다.

어쩌면 덜 복잡하다고 주장하지만 그것은 더 분명 하지는 않을 것입니다. 그것들은 하나의 동일한 시스템이 아니지만 근본적으로 다르지 않습니다.

아마도 가장 중요한 차이점 사이 /dev/device/path/to/its/mount후자의 경로 파일 시스템에 있다는 것입니다 - 소프트웨어의 일부 비트가 조직적인 방법으로 데이터를 처리하기위한이 - 이전의 내용을 해석한다. 당신은 단지 디스크를 읽을 수 없습니다-누군가 당신에게 그것을 읽어야합니다. 파일 시스템은 장치의 내용을 해석합니다.


이것은 다소 오해의 소지가 있습니다. /dev/cdrom16 진 편집기에서 열면 실제로 CD-ROM의 원시 내용이 들어 있습니다. 이를 사용 mount하면 OS에 해당 내용을 디렉토리 트리로 해석하도록 지시하면됩니다.
Krzysztof Kosiński

0

위에서 언급 한 항목 외에도 드라이버 또는 다른 프로그램은 장치에서 데이터를 캐시 할 수 있습니다. 하드 디스크 또는 썸 드라이브와 같은 읽기 / 쓰기 장치에서 장치에 기록 된 데이터가 아직 기록되지 않았을 수 있습니다. 저널링 파일 시스템은 더 이상 장치를 보지 않기 전에 저널을 플러시해야 할 수도 있습니다. 그런 다음 기본 파일 시스템을 더 이상 사용할 수없는 경우 알아야하는 cryptfs와 같은 다른 파일 시스템을 오버레이하는 파일 시스템이 있습니다.

읽기 전용 장치의 경우에는 의미가 떨어지지 만 여전히 적용됩니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.