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

Question 1

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

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

다른 경우에는 이 낮은 수준의 액세스만으로 충분합니다. 직렬 포트, USB 장치, tty 터미널 및 기타 비교적 간단한 장치를 읽고 썼습니다. 기본적으로 파일 inode 찾기, 스토리지 블록 찾기, 전체 블록 읽기, 변경 작업이 포함될 수 있는 ext4 로직을 다시 구현해야 하기 때문에 텍스트 파일을 편집하기 위해 /dev/sda1에서 수동으로 읽기/쓰기를 시도하지 않습니다. , 전체 블록을 쓴 다음 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/sda1CD ROM 드라이브와 하드 드라이브의 파티션 1일 수도 있지만 ISO 9660/ext4를 구현하지 않습니다.장치 파일.

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

다른 경우에는 이 낮은 수준의 액세스만으로 충분합니다. 직렬 포트, USB 장치, tty 터미널 및 기타 비교적 간단한 장치를 읽고 썼습니다. 기본적으로 파일 inode 찾기, 스토리지 블록 찾기, 전체 블록 읽기, 변경 작업이 포함될 수 있는 ext4 로직을 다시 구현해야 하기 때문에 텍스트 파일을 편집하기 위해 /dev/sda1에서 수동으로 읽기/쓰기를 시도하지 않습니다. , 전체 블록을 쓴 다음 inode를 업데이트하거나(아마도) 로그에 모두 쓰십시오. 너무 어렵습니다.

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

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

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

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

Question 2

간단히 말해서, 운영 체제는 장치의 파일에 액세스하는 방법을 알아야 합니다.

mount단순히 "파일에 액세스할 수 있도록 허용"하는 것 이상으로 드라이브에 있는 파일 시스템이 읽기 전용인지 읽기/쓰기 액세스인지 등을 운영 체제에 알려줍니다.

/dev/cdrom낮은 수준의 장치이며 운영 체제 기능은 이에 액세스하는 방법을 모릅니다... 이상한 형식의 CDROM(또는 오디오 CD)을 넣었다고 상상해 보십시오. ls어떤 파일이 있는지 어떻게 알 수 있습니까? CD-ROM에 먼저 "설치"하지 않고?

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

Answer

간단히 말해서, 운영 체제는 장치의 파일에 액세스하는 방법을 알아야 합니다.

mount단순히 "파일에 액세스할 수 있도록 허용"하는 것 이상으로 드라이브에 있는 파일 시스템이 읽기 전용인지 읽기/쓰기 액세스인지 등을 운영 체제에 알려줍니다.

/dev/cdrom낮은 수준의 장치이며 운영 체제 기능은 이에 액세스하는 방법을 모릅니다... 이상한 형식의 CDROM(또는 오디오 CD)을 넣었다고 상상해 보십시오. ls어떤 파일이 있는지 어떻게 알 수 있습니까? CD-ROM에 먼저 "설치"하지 않고?

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

Question 3

나는 그것을 역사적 이유라고 부른다. 다른 대답이 틀렸다는 것은 아니지만 이야기에는 더 많은 것이 있습니다.

Windows 비교: Windows는 단일 컴퓨터, 단일 사용자 운영 체제로 시작되었습니다. 그 컴퓨터에는 아마도 플로피 드라이브와 하드 드라이브만 있었고 네트워크 연결도, USB도, 아무것도 없었을 것입니다. (Windows 3.11에는 기본 네트워킹 기능이 있습니다.윈도우 3.1 아니오.)

Windows는 매우 간단하고 단순한 설정으로 탄생했습니다. 많은 문제 없이 매번 모든 것(두 장치 모두)을 자동 설치하기만 하면 됩니다.

이와 대조적으로 Unix는 처음부터 여러 사용자가 있는 서버 네트워크에서 실행되도록 설계되었습니다.

Unix의 설계 결정 중 하나는 물리적 디스크가 얼마나 많은 시스템에 분산되어 있는지, 어떤 종류의 디스크인지, 수십 명의 사용자 중 어느 사용자인지에 관계없이 파일 시스템이 최종 사용자에게 통합된 개체로 나타나야 한다는 것입니다. 머신에서 액세스됩니다. 사용자 파일의 논리적 경로는 해당 파일의 물리적 위치가 밤새 변경되더라도(예: 서버 유지 관리로 인해) 동일하게 유지됩니다.

이러한 파일이 저장된 물리적 장치에서 논리적 파일 시스템, 파일 경로를 추상화합니다. 서버 A가 일반적으로 /home을 호스팅하지만 서버 A에 유지 관리가 필요하다고 가정합니다. 서버 A를 제거하고 /home에 백업 서버 B를 설치하면 관리자 외에는 아무도 이를 알 수 없습니다.
(다른 물리적 장치에 다른 이름(C:, D: 등)을 부여하는 Windows 규칙과 달리 이는 Unix가 추구하는 투명성에 어긋납니다.)

그런 환경에서는 눈에 보이는 모든 것을 그냥 담을 수는 없습니다.

대규모 네트워크에서는 개별 디스크와 컴퓨터에 오류가 발생하는 경우가 많습니다. 관리자필요한 컴퓨터를 제어하여 종료하고 다른 컴퓨터가 투명하게 동일한 파일을 호스팅하는 등 무언가가 언제 어디에 설치되었는지 알 수 있습니다.

그렇기 때문에 역사적인 관점에서 볼 때 Windows와 Unix는 서로 다른 배경에서 왔습니다. 원한다면 문화적 차이라고 부를 수 있습니다.

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

최근에는 운영 체제가 서로 더 가까워졌습니다.

Linux는 독립 실행형 설정에서 자주 사용되기 때문에 더 많은 단일 컴퓨터, 단일 사용자 기능(예: 자동 마운트)을 추가합니다.
Windows는 더 많은 보안, 네트워킹, 다중 사용자 지원 등을 추가했으며 네트워킹이 더욱 보편화됨에 따라 Microsoft는 서버용 운영 체제도 개발하기 시작했습니다.

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

Answer

나는 그것을 역사적 이유라고 부른다. 다른 대답이 틀렸다는 것은 아니지만 이야기에는 더 많은 것이 있습니다.

Windows 비교: Windows는 단일 컴퓨터, 단일 사용자 운영 체제로 시작되었습니다. 그 컴퓨터에는 아마도 플로피 드라이브와 하드 드라이브만 있었고 네트워크 연결도, USB도, 아무것도 없었을 것입니다. (Windows 3.11에는 기본 네트워킹 기능이 있습니다.윈도우 3.1 아니오.)

Windows는 매우 간단하고 단순한 설정으로 탄생했습니다. 많은 문제 없이 매번 모든 것(두 장치 모두)을 자동 설치하기만 하면 됩니다.

이와 대조적으로 Unix는 처음부터 여러 사용자가 있는 서버 네트워크에서 실행되도록 설계되었습니다.

Unix의 설계 결정 중 하나는 물리적 디스크가 얼마나 많은 시스템에 분산되어 있는지, 어떤 종류의 디스크인지, 수십 명의 사용자 중 어느 사용자인지에 관계없이 파일 시스템이 최종 사용자에게 통합된 개체로 나타나야 한다는 것입니다. 머신에서 액세스됩니다. 사용자 파일의 논리적 경로는 해당 파일의 물리적 위치가 밤새 변경되더라도(예: 서버 유지 관리로 인해) 동일하게 유지됩니다.

이러한 파일이 저장된 물리적 장치에서 논리적 파일 시스템, 파일 경로를 추상화합니다. 서버 A가 일반적으로 /home을 호스팅하지만 서버 A에 유지 관리가 필요하다고 가정합니다. 서버 A를 제거하고 /home에 백업 서버 B를 설치하면 관리자 외에는 아무도 이를 알 수 없습니다.
(다른 물리적 장치에 다른 이름(C:, D: 등)을 부여하는 Windows 규칙과 달리 이는 Unix가 추구하는 투명성에 어긋납니다.)

그런 환경에서는 눈에 보이는 모든 것을 그냥 담을 수는 없습니다.

대규모 네트워크에서는 개별 디스크와 컴퓨터에 오류가 발생하는 경우가 많습니다. 관리자필요한 컴퓨터를 제어하여 종료하고 다른 컴퓨터가 투명하게 동일한 파일을 호스팅하는 등 무언가가 언제 어디에 설치되었는지 알 수 있습니다.

그렇기 때문에 역사적인 관점에서 볼 때 Windows와 Unix는 서로 다른 배경에서 왔습니다. 원한다면 문화적 차이라고 부를 수 있습니다.

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

최근에는 운영 체제가 서로 더 가까워졌습니다.

Linux는 독립 실행형 설정에서 자주 사용되기 때문에 더 많은 단일 컴퓨터, 단일 사용자 기능(예: 자동 마운트)을 추가합니다.
Windows는 더 많은 보안, 네트워킹, 다중 사용자 지원 등을 추가했으며 네트워킹이 더욱 보편화됨에 따라 Microsoft는 서버용 운영 체제도 개발하기 시작했습니다.

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

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, 자동으로 수행하도록 운영 체제에 맡기든 이 작업은 수행되어야 하며, 물론 파일 시스템 드라이버 소프트웨어가 먼저 있어야 합니다.

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

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

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

Linux에서도 마찬가지입니다. 자체 파일 시스템 드라이버(또는 장치 드라이버)를 작성하고 설치한 다음 사용할 수 있습니다. 이는 Linux(또는 Unix의 다른 변형)를 쉽게 확장할 수 있게 해줍니다(실제로 Linux가 탄생한 이유이기도 합니다): 새로운 하드웨어가 시장에 출시될 때 또는 파일 시스템을 구현하는 새롭고 더 스마트한 방법을 고안하기 위해 어느 시점에서는 누군가가 이를 지원하고 작동하게 만들고 Linux에 기여하는 코드를 작성할 수 있습니다.

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

Answer