왜 Linux에 마운트해야 합니까?

Question 1

ls한 가지 이유는 블록 수준 액세스가 작업할 수 있는 것보다 약간 낮은 수준이기 때문입니다 . /dev/cdrom또는 dev/sda1각각 CD ROM 드라이브 및 하드 드라이브의 파티션 1일 수 있지만 ISO 9660/ext4를 구현하지 않습니다.장치 파일.

마운트가 결정하는 것 중 하나는 원시 액세스를 사용하는 방법, 즉 어떤 파일 시스템 로직/드라이버/커널 모듈이 읽기/쓰기를 관리하거나 ls /mnt/cdrom읽어야 하는 블록으로 변환하고 해당 내용을 해석하는 방법입니다. 와 같은 것으로 차단됩니다 file.txt.

다른 경우에는 이 낮은 수준의 액세스만으로도 충분할 수 있습니다. 저는 방금 직렬 포트, USB 장치, tty 터미널 및 기타 비교적 간단한 장치를 읽고 썼습니다. 나는 텍스트 파일을 편집하기 위해 /dev/sda1에서 수동으로 읽기/쓰기를 시도하지 않을 것입니다. 왜냐하면 기본적으로 ext4 로직을 다시 구현해야 하기 때문입니다. 여기에는 파일 inode 검색, 저장 블록, 전체 블록 읽기, 변경 사항 작성, 전체 블록 쓰기, inode 업데이트(아마도), 또는 대신 이 모든 것을 저널에 쓰기 - 너무 어렵습니다.

이것을 직접 확인하는 한 가지 방법은 직접 시도해 보는 것입니다.

[root@ArchHP dev]# cd /dev/sda1
bash: cd: /dev/sda1: Not a directory

/dev디렉토리이며 원하는 모든 것을 cd할 수 있습니다. 디렉토리가 아닙니다. 커널이 해당 장치에 대한 '핸들'로 제공하는 특별한 유형의 파일입니다.ls/dev/sda1

보다장치 파일에 대한 Wikipedia 항목좀 더 심층적인 진료를 위해

Answer

ls한 가지 이유는 블록 수준 액세스가 작업할 수 있는 것보다 약간 낮은 수준이기 때문입니다 . /dev/cdrom또는 dev/sda1각각 CD ROM 드라이브 및 하드 드라이브의 파티션 1일 수 있지만 ISO 9660/ext4를 구현하지 않습니다.장치 파일.

마운트가 결정하는 것 중 하나는 원시 액세스를 사용하는 방법, 즉 어떤 파일 시스템 로직/드라이버/커널 모듈이 읽기/쓰기를 관리하거나 ls /mnt/cdrom읽어야 하는 블록으로 변환하고 해당 내용을 해석하는 방법입니다. 와 같은 것으로 차단됩니다 file.txt.

다른 경우에는 이 낮은 수준의 액세스만으로도 충분할 수 있습니다. 저는 방금 직렬 포트, USB 장치, tty 터미널 및 기타 비교적 간단한 장치를 읽고 썼습니다. 나는 텍스트 파일을 편집하기 위해 /dev/sda1에서 수동으로 읽기/쓰기를 시도하지 않을 것입니다. 왜냐하면 기본적으로 ext4 로직을 다시 구현해야 하기 때문입니다. 여기에는 파일 inode 검색, 저장 블록, 전체 블록 읽기, 변경 사항 작성, 전체 블록 쓰기, inode 업데이트(아마도), 또는 대신 이 모든 것을 저널에 쓰기 - 너무 어렵습니다.

이것을 직접 확인하는 한 가지 방법은 직접 시도해 보는 것입니다.

[root@ArchHP dev]# cd /dev/sda1
bash: cd: /dev/sda1: Not a directory

/dev디렉토리이며 원하는 모든 것을 cd할 수 있습니다. 디렉토리가 아닙니다. 커널이 해당 장치에 대한 '핸들'로 제공하는 특별한 유형의 파일입니다.ls/dev/sda1

보다장치 파일에 대한 Wikipedia 항목좀 더 심층적인 진료를 위해

Question 2

기본적으로 쉽게 말하면 운영 체제는 해당 장치의 파일에 액세스하는 방법을 알아야 합니다.

mount"파일에 대한 액세스 권한을 제공"할 뿐만 아니라 드라이브에 있는 파일 시스템이 읽기 전용인지 읽기/쓰기 액세스인지 등을 OS에 알려줍니다.

/dev/cdrom낮은 수준의 장치이므로 운영 체제 기능은 이에 액세스하는 방법을 모릅니다. 이상한 형식의 CDROM(오디오 CD도 포함)을 넣었다고 상상해 보세요. ls어떤 파일(있는 경우)이 있는지 어떻게 알 수 있습니까? 먼저 "마운트"하지 않고 CD-ROM을 사용하시겠습니까?

이는 많은 OS(일부 배포판 및 그래픽 인터페이스의 Linux 포함)에서 자동으로 발생하지만 이것이 다른 OS가 드라이브를 "마운트"하지 않는다는 의미는 아닙니다.

Answer

기본적으로 쉽게 말하면 운영 체제는 해당 장치의 파일에 액세스하는 방법을 알아야 합니다.

mount"파일에 대한 액세스 권한을 제공"할 뿐만 아니라 드라이브에 있는 파일 시스템이 읽기 전용인지 읽기/쓰기 액세스인지 등을 OS에 알려줍니다.

/dev/cdrom낮은 수준의 장치이므로 운영 체제 기능은 이에 액세스하는 방법을 모릅니다. 이상한 형식의 CDROM(오디오 CD도 포함)을 넣었다고 상상해 보세요. ls어떤 파일(있는 경우)이 있는지 어떻게 알 수 있습니까? 먼저 "마운트"하지 않고 CD-ROM을 사용하시겠습니까?

이는 많은 OS(일부 배포판 및 그래픽 인터페이스의 Linux 포함)에서 자동으로 발생하지만 이것이 다른 OS가 드라이브를 "마운트"하지 않는다는 의미는 아닙니다.

Question 3

나는 그것을 역사적인 이유라고 부르고 싶습니다. 다른 답변이 틀린 것은 아니지만 이야기에는 조금 더 많은 내용이 있습니다.

Windows 비교: Windows는 단일 컴퓨터, 단일 사용자 OS로 시작되었습니다. 그 컴퓨터 한 대에는 플로피 드라이브 하나와 하드 드라이브 하나가 있었고 네트워크 연결도, USB도, 아무것도 없었을 것입니다. (Windows 3.11에는 기본 네트워킹 기능이 있었습니다.윈도우 3.1은 그렇지 않았다.)

Windows가 탄생한 설정은 너무 간단해서 화려할 필요가 없었습니다. 매번 자동으로 모든 것(두 장치 모두)을 마운트하기만 하면 잘못될 수 있는 일이 많지 않습니다.

반면 유닉스는 처음부터 여러 사용자가 있는 서버 네트워크에서 실행되도록 만들어졌다.

Unix 디자인 결정 중 하나는 물리적 디스크가 얼마나 많은 컴퓨터에 분산되어 있는지, 어떤 종류의 디스크인지, 수십 대의 컴퓨터에 관계없이 최종 사용자에게 파일 시스템이 하나의 통일된 개체로 나타나야 한다는 것이었습니다. 사용자는 다음에서 액세스합니다. 서버 유지 관리 등으로 인해 해당 파일의 물리적 위치가 밤새 변경된 경우에도 사용자 파일의 논리적 경로는 동일하게 유지됩니다.

그들은 해당 파일을 저장한 물리적 장치에서 논리적 파일 시스템, 파일 경로를 추상화하고 있었습니다. 서버 A가 일반적으로 /home을 호스팅하지만 서버 A에 유지 관리가 필요하다고 가정해 보겠습니다. 서버 A를 마운트 해제하고 대신 /home에 백업 서버 B를 마운트하기만 하면 관리자 외에는 아무도 눈치 채지 못할 것입니다.
(다양한 물리적 장치(C:, D: 등)에 서로 다른 이름을 지정하는 Windows 규칙과는 달리 이는 Unix가 추구하는 투명성에 반하는 방식입니다.)

그런 환경에서는 눈에 보이는 모든 것을 아무렇게나 올려놓을 수는 없습니다.

대규모 네트워크에서는 개별 디스크와 컴퓨터가 지속적으로 작동하지 않습니다. 관리자필요예를 들어 한 컴퓨터의 제어된 종료를 수행하고 다른 컴퓨터가 투명하게 동일한 파일을 호스팅하는 동안 무엇이 마운트되어 있는지 말할 수 있는 기능입니다.

이것이 역사적 관점에서 볼 때 Windows와 Unix가 서로 다른 배경에서 나온 이유입니다. 원한다면 문화적 차이라고 부를 수도 있습니다.

Unix는 관리자가 마운트를 제어해야 하는 환경에서 탄생했습니다. 네트워크에 있는 수십 개의 저장 장치 중에서 관리자는 무엇이 언제 어디에 마운트되는지 결정해야 합니다.
Windows는 관리자가 없고 저장 장치가 두 개만 있는 환경에서 탄생했으며 사용자는 자신의 파일이 플로피 드라이브에 있는지 하드 드라이브에 있는지 알 수 있었습니다.
(물론 Linux는 단일 컴퓨터 OS로 탄생했지만 처음부터 가정용 컴퓨터에서 Unix를 최대한 비슷하게 모방하도록 명시적으로 설계되었습니다.)

최근에는 OS가 서로 더 가까워지고 있습니다.

Linux에는 단일 컴퓨터, 단일 사용자 기능(예: 자동 마운트)이 추가되었습니다. 단일 컴퓨터 설정에서 자주 사용되기 때문입니다.
Windows에는 더 많은 보안, 네트워킹, 여러 사용자 지원 등이 추가되었습니다. 네트워킹이 더욱 보편화되면서 Microsoft는 서버용 OS도 만들기 시작했습니다.

그러나 이 둘이 서로 다른 전통의 결과라는 점은 여전히 쉽게 알 수 있습니다.

Answer

나는 그것을 역사적인 이유라고 부르고 싶습니다. 다른 답변이 틀린 것은 아니지만 이야기에는 조금 더 많은 내용이 있습니다.

Windows 비교: Windows는 단일 컴퓨터, 단일 사용자 OS로 시작되었습니다. 그 컴퓨터 한 대에는 플로피 드라이브 하나와 하드 드라이브 하나가 있었고 네트워크 연결도, USB도, 아무것도 없었을 것입니다. (Windows 3.11에는 기본 네트워킹 기능이 있었습니다.윈도우 3.1은 그렇지 않았다.)

Windows가 탄생한 설정은 너무 간단해서 화려할 필요가 없었습니다. 매번 자동으로 모든 것(두 장치 모두)을 마운트하기만 하면 잘못될 수 있는 일이 많지 않습니다.

반면 유닉스는 처음부터 여러 사용자가 있는 서버 네트워크에서 실행되도록 만들어졌다.

Unix 디자인 결정 중 하나는 물리적 디스크가 얼마나 많은 컴퓨터에 분산되어 있는지, 어떤 종류의 디스크인지, 수십 대의 컴퓨터에 관계없이 최종 사용자에게 파일 시스템이 하나의 통일된 개체로 나타나야 한다는 것이었습니다. 사용자는 다음에서 액세스합니다. 서버 유지 관리 등으로 인해 해당 파일의 물리적 위치가 밤새 변경된 경우에도 사용자 파일의 논리적 경로는 동일하게 유지됩니다.

그들은 해당 파일을 저장한 물리적 장치에서 논리적 파일 시스템, 파일 경로를 추상화하고 있었습니다. 서버 A가 일반적으로 /home을 호스팅하지만 서버 A에 유지 관리가 필요하다고 가정해 보겠습니다. 서버 A를 마운트 해제하고 대신 /home에 백업 서버 B를 마운트하기만 하면 관리자 외에는 아무도 눈치 채지 못할 것입니다.
(다양한 물리적 장치(C:, D: 등)에 서로 다른 이름을 지정하는 Windows 규칙과는 달리 이는 Unix가 추구하는 투명성에 반하는 방식입니다.)

그런 환경에서는 눈에 보이는 모든 것을 아무렇게나 올려놓을 수는 없습니다.

대규모 네트워크에서는 개별 디스크와 컴퓨터가 지속적으로 작동하지 않습니다. 관리자필요예를 들어 한 컴퓨터의 제어된 종료를 수행하고 다른 컴퓨터가 투명하게 동일한 파일을 호스팅하는 동안 무엇이 마운트되어 있는지 말할 수 있는 기능입니다.

이것이 역사적 관점에서 볼 때 Windows와 Unix가 서로 다른 배경에서 나온 이유입니다. 원한다면 문화적 차이라고 부를 수도 있습니다.

Unix는 관리자가 마운트를 제어해야 하는 환경에서 탄생했습니다. 네트워크에 있는 수십 개의 저장 장치 중에서 관리자는 무엇이 언제 어디에 마운트되는지 결정해야 합니다.
Windows는 관리자가 없고 저장 장치가 두 개만 있는 환경에서 탄생했으며 사용자는 자신의 파일이 플로피 드라이브에 있는지 하드 드라이브에 있는지 알 수 있었습니다.
(물론 Linux는 단일 컴퓨터 OS로 탄생했지만 처음부터 가정용 컴퓨터에서 Unix를 최대한 비슷하게 모방하도록 명시적으로 설계되었습니다.)

최근에는 OS가 서로 더 가까워지고 있습니다.

Linux에는 단일 컴퓨터, 단일 사용자 기능(예: 자동 마운트)이 추가되었습니다. 단일 컴퓨터 설정에서 자주 사용되기 때문입니다.
Windows에는 더 많은 보안, 네트워킹, 여러 사용자 지원 등이 추가되었습니다. 네트워킹이 더욱 보편화되면서 Microsoft는 서버용 OS도 만들기 시작했습니다.

그러나 이 둘이 서로 다른 전통의 결과라는 점은 여전히 쉽게 알 수 있습니다.

Question 4

질문 제목은 다음과 같습니다.왜 Linux에 마운트해야 합니까?

이 질문을 해석하는 한 가지 방법은 다음과 같습니다.mountLinux에서 파일 시스템을 사용할 수 있도록 명시적인 명령을 실행해야 하는 이유는 무엇입니까 ?

대답은: 그렇지 않습니다.

파일 시스템을 명시적으로 마운트할 필요가 없으며 자동으로 수행되도록 설정할 수 있으며 Linux 배포판은 Windows 및 Mac과 마찬가지로 대부분의 장치에서 이미 이 작업을 수행합니다.

그래서 아마도 그것은 당신이 묻고자 한 것이 아닐 것입니다.

두 번째 해석:왜 우리는때때로mountLinux에서 파일 시스템을 사용할 수 있도록 하려면 명시적인 명령을 실행해야 합니까 ? 운영체제를 만들지 않는 이유언제나우리를 위해 그렇게 하고 사용자에게는 숨기시겠습니까?

이것은 질문 텍스트에서 내가 읽고 있는 질문입니다.

마운트를 완전히 건너뛰고 다음을 수행하십시오.

ls /dev/cdrom

CD-ROM의 내용이 나열되어 있습니까?

아마도 당신은 다음과 같은 의미일 것입니다: 왜 그 명령으로 무엇을 하게 하면 안되는가?

ls /media/cdrom

지금은요?

그렇다면 /dev/cdrom장치 파일이 아닌 디렉터리 트리가 됩니다. 따라서 귀하의 실제 질문은 다음과 같습니다: 애초에 왜 장치 파일이 있습니까?

이미 제공된 답변에 답변을 추가하고 싶습니다.

사용자가 장치 파일을 볼 수 있는 이유는 무엇입니까?

CD-ROM이나 파일을 저장하는 다른 장치를 사용할 때마다 CD-ROM에 있는 모든 내용을 파일의 디렉터리 트리로 해석하는 소프트웨어가 사용됩니다. lsCD-ROM의 파일에 액세스하는 다른 종류의 명령이나 응용 프로그램을 사용할 때마다 호출됩니다 . 해당 소프트웨어는 CD-ROM에 파일을 쓰는 데 사용되는 특정 파일 시스템용 파일 시스템 드라이버입니다. 파일 시스템에서 파일을 나열하거나 읽거나 쓸 때마다 해당 장치에서 해당 하위 수준 읽기 및 쓰기 작업이 수행되는지 확인하는 것이 해당 소프트웨어의 임무입니다. 파일 시스템을 만들 때마다 mount장치에 사용할 파일 시스템 드라이버를 시스템에 알려줍니다. 명령 을 사용하여 이 작업을 명시적으로 수행하든 mount, 자동으로 수행되도록 OS에 맡기든 이 작업을 수행해야 하며, 물론 파일 시스템 드라이버 소프트웨어가 먼저 있어야 합니다.

파일 시스템 드라이버는 어떻게 작업을 수행합니까? 대답은 장치 파일을 읽고 쓰는 방식입니다. 왜? 대답은 이미 언급했듯이 Unix는 이런 식으로 설계되었습니다. Unix에서 장치 파일은 장치에 대한 일반적인 저수준 추상화입니다. 특정 장치에 대한 실제 장치별 소프트웨어(장치 드라이버)는 장치 파일에 대한 작업으로 장치에 대한 열기, 닫기, 읽기 및 쓰기를 구현하도록 되어 있습니다. 이렇게 하면 상위 수준 소프트웨어(예: 파일 시스템 드라이버)는 개별 장치의 내부 작동에 대해 많이 알 필요가 없습니다. 저수준 장치 드라이버와 파일 시스템 드라이버는 서로 인터페이스하는 공통 방식에 동의하는 한 서로 다른 사람이 별도로 작성할 수 있으며, 이것이 바로 장치 파일의 용도입니다.

따라서 파일 시스템 드라이버에는 장치 파일이 필요합니다.

그런데 일반 사용자인 우리는 왜 장치 파일을 보게 됩니까? 대답은 Unix가 운영 체제 프로그래머가 사용하도록 설계되었다는 것입니다. 사용자가 장치 드라이버와 파일 시스템 드라이버를 작성할 수 있도록 설계되었습니다. 실제로 그것이 쓰여지는 방식입니다.

Linux의 경우에도 마찬가지입니다. 자체 파일 시스템 드라이버(또는 장치 드라이버)를 작성하고 설치한 다음 사용할 수 있습니다. 이는 Linux(또는 Unix의 다른 변형)를 쉽게 확장 가능하게 만듭니다(그리고 실제로 이것이 Linux가 시작된 이유입니다). 새로운 하드웨어가 시장에 출시되거나 파일 시스템을 구현하는 새롭고 더 스마트한 방법이 설계될 때 , 누군가는 이를 지원하고 작동시키고 Linux에 기여하는 코드를 작성할 수 있습니다.

장치 파일을 사용하면 이 작업이 더 쉬워집니다.

Answer