Linux에 마운트가 무엇인지 이해하고 장치 파일을 이해합니다. 그러나 왜 우리가 마운트해야하는지 이해하지 못합니다.
예를 들어, 다음 명령을 사용하여이 질문에 대한 대답에 설명 된대로 :
mount /dev/cdrom /media/cdrom
우리는 CDROM 장치를 마운트 /media/cdrom하고 결국 다음 명령으로 CDROM 파일에 액세스 할 수 있습니다
ls /media/cdrom
CDROM의 내용이 나열됩니다.
왜 마운트를 완전히 건너 뛰고 다음을 수행하지 않습니까?
ls /dev/cdrom
그리고 CDROM의 내용을 나열하십시오. 나는 ” 리눅스가 어떻게 설계 되었는가? ” 그러나 그렇다면 왜 그렇게 설계 되었습니까? 왜 /dev/cdrom디렉토리에 직접 액세스하지 않습니까? 장착의 실제 목적은 무엇입니까?
답변
한 가지 이유는 블록 레벨 액세스가 ls작업 할 수있는 것 보다 약간 낮은 레벨이기 때문 입니다. /dev/cdrom또는 dev/sda1CD-ROM 드라이브 및 하드 드라이브의 파티션 1 일 수도 있지만 ISO 9660 / ext4를 구현하지는 않습니다 . 장치 파일 이라고하는 장치에 대한 RAW 포인터 일뿐 입니다.
마운트가 결정하는 것 중 하나는 원시 액세스를 사용하는 방법입니다-파일 시스템 논리 / 드라이버 / 커널 모듈이 읽기 / 쓰기를 관리하거나 읽을 ls /mnt/cdrom블록으로 변환 할 내용 및 해당 내용을 해석하는 방법 같은 것들로 차단합니다 file.txt.
다른 경우에는이 낮은 수준의 액세스로 충분할 수 있습니다. 방금 직렬 포트, USB 장치, tty 터미널 및 기타 비교적 간단한 장치에서 읽고 썼습니다. 나는 기본적으로 ext4 로직을 다시 구현해야하기 때문에 / dev / sda1에서 수동으로 텍스트 파일을 읽거나 쓰려고 시도하지 않을 것입니다. 스토리지 블록, 전체 블록 읽기, 변경, 전체 블록 쓰기, inode 업데이트 (아마도) 또는 저널에이 모든 것을 쓰기가 너무 어렵습니다.
이것을 직접 보는 한 가지 방법은 시도해 보는 것입니다.
[root@ArchHP dev]# cd /dev/sda1
bash: cd: /dev/sda1: Not a directory
/dev디렉토리, 당신은 할 수 cd및 ls모든 당신이 좋아한다. /dev/sda1디렉토리가 아닙니다. 커널이 해당 장치에 대한 ‘핸들링’으로 제공하는 특별한 유형의 파일입니다.
보다 심층적 인 처리 방법 은 장치 파일의 wikipedia 항목을 참조하십시오 .
답변
기본적으로 운영 체제는 간단히 말해서 해당 장치의 파일에 액세스하는 방법을 알아야합니다.
mount “파일에 대한 액세스 권한 부여”일뿐만 아니라 드라이브에있는 파일 시스템 (읽기 전용 또는 읽기 / 쓰기 액세스 여부 등)을 OS에 알려줍니다.
/dev/cdrom저수준 장치이며 운영 체제 기능은 액세스 방법을 알 수 없습니다 … 이상하게 포맷 된 cdrom (오디오 CD 포함)을 넣고 ls어떤 파일 (있는 경우)이 있는지 알 수 있습니다 CD-ROM을 먼저 “마운팅”하지 않습니까?
이는 많은 OS에서 (일부 배포판 및 그래픽 인터페이스의 Linux조차도) 자동으로 발생하지만 다른 OS가 드라이브를 “마운트”하지 않는 것은 아닙니다.
답변
일관성을 위해
시스템의 첫 번째 하드 드라이브에 파티션이 있다고 가정하십시오. 예를 들면 다음과 같습니다 /dev/sda2. 나중에 드라이브가 충분히 크지 않다고 판단하여 두 번째 드라이브를 구입하여 시스템에 추가하십시오. 갑자기, /dev/sda그리고 현재 드라이브가됩니다 /dev/sdb. 이제 파티션이되었습니다 /dev/sdb2.
제안 된 시스템을 사용하면 이전 파티션의 데이터에 액세스하는 모든 스크립트, 응용 프로그램, 설정 등을 변경하여 이름을 변경해야합니다.
그러나 마운트하면이 이름이 바뀐 드라이브에 대해 동일한 마운트 포인트를 계속 사용할 수 있습니다. 당신은 수정해야 할 것 /etc/fstab(예) 시스템 말해 /media/backup지금 /dev/sdb2대신을, 그러나 그것은 단지 하나의 편집이다.
현대의 시스템은 훨씬 쉽습니다. 장치를 /dev/sda2또는 로 참조하는 대신 /dev/sdb2, 장착 할 때 장치를 참조하는 데 사용할 수있는 레이블과 UUIDS유사 c5845b43-fe98-499a-bf31-4eccae14261b하거나 친숙한 레이블 backup을 지정할 수 있습니다. 이런 식으로 새 장치를 추가 할 때 장치 이름이 변경되지 않아 관리가 훨씬 간단 해집니다.
# mount LABEL="backup" /media/backup
안전을 위해
관리자는 장치를 마운트해야하므로 장치에 대한 액세스를 제어 할 수 있습니다. 장치를 마운트 해제하면 제거 할 수 있지만 사용 중일 때는 제거 할 수 없습니다 (데이터 손실이 발생하지 않는 한). Windows 사용자 인 경우 알림 영역에서 USB 스틱을 제거해도 안전하다는 작은 녹색 아이콘을 기억하십니까? 그것은 스틱을 장착하고 마운트 해제하는 Windows입니다. 따라서 원칙은 단순한 유닉스 / 리눅스가 아닙니다.
답변
나는 그것을 역사적인 이유라고 부릅니다. 다른 답변이 틀린 것은 아니지만 이야기에는 조금 더 있습니다.
Windows 비교 : Windows는 단일 컴퓨터, 단일 사용자 OS로 시작되었습니다. 그 단일 컴퓨터에는 아마도 하나의 플로피 드라이브와 하나의 하드 드라이브, 네트워크 연결, USB도없고 아무것도 없었을 것입니다. (Windows 3.11에는 기본 네트워킹 기능이 있었지만 Windows 3.1에는 없습니다 .)
Windows가 탄생 한 설정의 종류는 너무나 단순해서 화려할 필요가 없었습니다. 매번 모든 장치 (두 장치 모두)를 자동으로 마운트하면 잘못 될 수있는 것이 많지 않습니다.
반대로 Unix는 처음부터 여러 사용자가있는 서버 네트워크에서 실행되도록 만들어졌습니다.
Unix 디자인 결정 중 하나는 파일 시스템이 실제 디스크가 몇 대의 컴퓨터에 분산되어 있는지, 어떤 종류의 디스크에 관계없이, 수십 대의 컴퓨터에 관계없이 최종 사용자에게 단일의 단일 엔티티로 표시되어야한다는 것입니다. 사용자가 액세스 할 수 있습니다. 서버 유지 관리 등으로 인해 파일의 물리적 위치가 밤새 변경 되더라도 사용자 파일의 논리적 경로는 동일하게 유지됩니다.
그들은 파일을 저장 한 물리적 장치에서 논리적 파일 시스템, 파일 경로를 추상화하고있었습니다. 서버 A가 일반적으로 / home을 호스팅한다고 말하지만 서버 A는 유지 관리가 필요합니다. 서버 A를 마운트 해제하고 대신 백업 서버 B를 / home에 마운트하면 관리자 외에는 아무도 알 수 없습니다.
(유닉스가 추구 한 투명성에 맞지 않는 다른 물리적 장치 (C :, D : 등)에 다른 이름을 부여하는 Windows 규칙과 달리)
그런 종류의 환경에서는 모든 것을 시인 할 수는 없습니다.
대규모 네트워크에서는 개별 디스크와 컴퓨터가 지속적으로 작동하지 않습니다. 관리자는 필요한 장소와 다른 컴퓨터가 투명하게 동일한 파일을 호스팅을 인수하면서 하나의 컴퓨터의 제어 된 종료를 수행하는 예를 들어, 장착 무슨 말을 할 수있는 능력을.
그렇기 때문에 역사적 관점에서 Windows와 Unix는 서로 다른 배경에서 나왔습니다. 원하는 경우 문화적 차이라고 할 수 있습니다.
- 유닉스는 관리자가 마운트를 제어해야하는 환경에서 태어났다. 관리자는 네트워크에있는 수십 개의 저장 장치 중 어디에서 언제 마운트 할 것인지 결정해야합니다.
- Windows는 관리자가없고 두 개의 저장 장치 만있는 환경에서 태어 났으며 사용자는 파일이 플로피 파일인지 하드 드라이브에 있는지 알 것입니다.
- (리눅스는 물론 단일 컴퓨터 OS로 태어 났지만, 처음부터 유닉스를 가정 컴퓨터에서 최대한 가깝게 모방하도록 명시 적으로 설계되었습니다.)
최근에 OS는 서로 더 가까이 다가 가고 있습니다.
- 리눅스는 더 많은 단일 컴퓨터, 단일 사용자 물건 (자동 마운팅과 같은)을 추가했다; 단일 컴퓨터 설정에서 자주 사용되기 때문입니다.
- Windows는 더 많은 보안, 네트워킹, 여러 사용자 지원 등을 추가했습니다. 네트워킹이 더욱 보편화되면서 Microsoft는 서버용 OS도 만들기 시작했습니다.
그러나 두 가지가 다른 전통의 결과라고 말하기는 여전히 쉽습니다.
답변
현재 배열에는 몇 가지 장점이 있습니다. 블록 특수 파일의 장점과 마운트 지점의 장점으로 그룹화 할 수 있습니다.
특수 파일은 장치를 나타내는 파일입니다. 유닉스가 만들어 낸 아이디어 중 하나는 모든 것입니다. 예를 들어, 사용자 상호 작용은 문자 특수 파일 인 tty 장치에서 파일을 읽고 쓰는 것입니다. 마찬가지로 불량 블록 검사, 디스크 파티션 또는 포맷은 파일 작업입니다. 디스크가 mfm, ide, scsi, fiberchanel 또는 다른 파일 인 경우에는 문제가되지 않습니다.
그러나 다른 한편으로는 전체 디스크를 처리하거나 파일 만 파티션하지 않고 디스크에 들어갈 수있는 것보다 많은 파일을 원할 수도 있습니다. 마운트 포인트가 있습니다. 마운트 지점을 사용하면 디렉토리에 전체 디스크 (또는 파티션)를 넣을 수 있습니다. 좋은 크기의 하드 디스크가 수백 MB 인 슬랙웨어 시절에 CD를 / usr로 사용하고 하드 디스크를 /, / usr / local 및 스왑에 사용하는 것이 일반적이었습니다. 또는 한 드라이브에 /를 넣고 다른 드라이브에 / home을 넣을 수 있습니다.
이제 CD-ROM 드라이브가 하나 뿐인 컴퓨터에 편리한 / media / cdrom에 CD를 마운트하는 것을 언급했지만 둘 이상의 CD를 가지고 있다면 어떨까요? 두 번째를 어디에 마운트해야합니까? 아니면 세번째? 아니면 15 일? / media / cdrom2 등을 확실히 사용할 수도 있습니다. 또는 / src / samba / resources / windows-install 또는 / var / www에 마운트 할 수도 있습니다.
답변
질문 제목은 다음과 같이 묻습니다. 왜 Linux에 마운트해야합니까?
이 질문을 해석하는 한 가지 방법 : Linux에서 파일 시스템을 사용 가능하게하려면 명시적인 mount명령을 실행 해야하는 이유는 무엇 입니까?
답은 없습니다.
파일 시스템을 명시 적으로 마운트 할 필요는 없으며 자동으로 파일 시스템을 정리할 수 있으며 Linux 배포는 Windows 및 Mac과 마찬가지로 대부분의 장치에서 이미이 작업을 수행합니다.
그래서 그것은 아마도 당신이 요구하려는 것이 아닐 것입니다.
두 번째 해석 : 왜 우리가 때로는 명시 적으로 실행할 필요가 mount리눅스 파일 시스템을 사용할 수 있도록 명령을? 왜 운영 체제가 항상 우리를 위해 그것을하고 사용자에게 숨길 수 있습니까?
이것은 질문 할 때 질문 텍스트에서 읽고있는 질문입니다.
마운팅을 건너 뛰지 말고 다음을 수행하십시오.
ls /dev/cdrom
CD-ROM의 내용이 나열되어 있습니까?
아마도, 당신은 의미 : 왜 그 명령이 무엇을합니까?
ls /media/cdrom
지금?
이 경우 /dev/cdrom장치 파일이 아닌 디렉토리 트리가됩니다. 실제 질문은 다음과 같습니다. 왜 장치 파일이 처음에 있습니까?
이미 주어진 것에 대한 답변을 추가하고 싶습니다.
사용자가 장치 파일을 보게되는 이유는 무엇입니까?
CD-ROM 또는 파일을 저장하는 다른 장치를 사용할 때마다 CD-ROM의 내용을 파일의 디렉토리 트리로 해석하는 소프트웨어가 사용됩니다. lsCD-ROM의 파일에 액세스하는 다른 종류의 명령이나 응용 프로그램을 사용할 때마다 호출됩니다 . 해당 소프트웨어는 파일을 CD-ROM에 쓰는 데 사용되는 특정 파일 시스템의 파일 시스템 드라이버입니다. 파일 시스템에서 파일을 나열, 읽기 또는 쓰기 할 때마다 해당 장치에서 해당 하위 수준 읽기 및 쓰기 작업이 수행되도록하는 것이 해당 소프트웨어의 역할입니다. 당신이 때마다 mount파일 시스템, 시스템을 말하는중인 파일 시스템 드라이버 장치에 사용할 수 있습니다. 이 작업을 명시 적으로 수행하는지 여부mount명령을 수행하거나 자동으로 수행되도록 OS에 맡기려면 수행해야합니다. 물론 파일 시스템 드라이버 소프트웨어가 먼저 있어야합니다.
파일 시스템 드라이버는 어떻게 작동합니까? 답은 장치 파일을 읽고 쓰는 것입니다. 왜? 당신이 이미 언급했듯이 대답 : Unix는 이런 식으로 설계되었습니다. 유닉스에서 장치 파일은 장치에 대한 일반적인 저수준 추상화입니다. 특정 장치에 대한 실제 장치 별 소프트웨어 (장치 드라이버)는 장치 파일의 작업으로 장치에서 열기, 닫기, 읽기 및 쓰기를 구현해야합니다. 이렇게하면 파일 시스템 드라이버와 같은 고급 소프트웨어는 개별 장치의 내부 작동에 대해 많이 알 필요가 없습니다. 저수준 장치 드라이버와 파일 시스템 드라이버는 서로 인터페이스하는 일반적인 방법에 동의하는 한 다른 사람들이 개별적으로 작성할 수 있으며 장치 파일의 용도입니다.
따라서 파일 시스템 드라이버에는 장치 파일이 필요합니다.
그러나 왜 일반 사용자 인 경우 장치 파일을 볼 수 있습니까? 그 대답은 Unix는 운영 체제 프로그래머가 사용하도록 설계되었다는 것입니다. 사용자가 장치 드라이버 및 파일 시스템 드라이버를 작성할 수 있도록 설계되었습니다. 그것이 실제로 어떻게 쓰여지 는가입니다.
Linux의 경우에도 마찬가지입니다. 고유 한 파일 시스템 드라이버 (또는 장치 드라이버)를 작성하여 설치 한 다음 사용할 수 있습니다. 리눅스 (또는 다른 유닉스 변형)를 쉽게 확장 할 수있게한다 (그리고 실제로 리눅스가 시작된 이유) , 누군가 코드를 작성하여 지원하고 작동하게하고 Linux에 제공 할 수 있습니다.
장치 파일은 이것을 더 쉽게 만듭니다.
답변
많은 데이터베이스 엔진이 원시 디스크 또는 파티션과 직접 작동 할 수 있습니다. 예를 들어, MySQL :
http://dev.mysql.com/doc/refman/5.7/en/innodb-raw-devices.html
이것은 실제로 모든 DB 엔진이 디스크를 채우는 하나의 거대한 파일 일 때 파일 시스템 드라이버를 거치는 오버 헤드를 피합니다.
