Linux의 파일 시스템이 단일 디렉토리 트리로 설계된 이유는 무엇입니까?

Linux가 단일 디렉토리 트리로 설계된 이유를 누구나 설명 할 수 있습니까?

Windows의 반면 우리는 같은 여러 드라이브를 가질 수 있습니다 C:\, 그리고 D:\유닉스에서 단일 루트가있다. 특별한 이유가 있습니까?

유닉스 파일 시스템은 몇 년 전부터 Windows보다 오래 사용 되었기 때문에 "Windows가 각 장치마다 별도의 지정자를 사용하는 이유"라는 질문을 다시 말할 수 있습니다.

계층 적 파일 시스템은 파일이나 디렉토리를 루트 디렉토리의 자식으로 찾을 수 있다는 이점이 있습니다. 새 장치 나 네트워크 장치로 데이터를 이동해야하는 경우 파일 시스템의 위치는 동일하게 유지 될 수 있으며 응용 프로그램은 차이를 볼 수 없습니다.

OS가 정적이고 높은 I / O 요구 사항을 가진 응용 프로그램이있는 시스템이 있다고 가정합니다. / usr 읽기 전용을 마운트하고 / opt (앱이있는 경우)를 SSD 드라이브에 넣을 수 있습니다. 파일 시스템 계층은 변경되지 않습니다. Windows에서는 특히 C : \ Program Files \에 거주해야하는 응용 프로그램의 경우 훨씬 어렵습니다.

이것은 부분적으로 역사적인 이유이며, 부분적으로는 이런 방식으로 이해하기 때문입니다.

멀티

Multics 는 디렉토리를 포함 할 수있는 디렉토리와 함께 오늘날 알려진 계층 구조 파일 시스템을 도입 한 최초의 운영 체제 입니다. RC Daley와 PG Neumann의 “보조 저장 소용 범용 파일 시스템” 인용 :

이 백서의 2 장은 파일의 계층 적 구조를 보여 주므로 시스템을 유연하게 사용할 수 있습니다. 이 구조에는 다양성을 보장하기에 충분한 기능이 포함되어 있습니다. (…)

이해하기 쉽도록 파일 구조는 파일 트리로 간주 될 수 있으며 일부는 디렉토리입니다. 즉, 하나의 예외를 제외하고 각 파일 (예 : 각 디렉토리)은 정확히 하나의 디렉토리에서 정확히 하나의 브랜치가 가리키는 자체를 찾습니다. 트리의 루트에있는 루트 디렉토리 또는 루트는 예외입니다. 디렉토리에서 명시 적으로 지시되지는 않았지만 루트는 파일 시스템에 알려진 가상의 분기에 의해 내재적으로 지시됩니다. (…)

언제든지 사용자는 작업 디렉토리라고하는 일부 디렉토리에서 작동하는 것으로 간주됩니다. 그는 항목 이름을 지정하여 작업 디렉토리의 항목이 효과적으로 가리키는 파일에 액세스 할 수 있습니다. 한 번에 둘 이상의 사용자가 동일한 작업 디렉토리를 가질 수 있습니다.

다른 많은 측면에서와 마찬가지로 Multics는 유연성을 추구했습니다. 사용자는 파일 시스템의 하위 트리에서 작업하고 나머지는 무시해도 디렉토리를 통해 파일을 정리할 수 있습니다. 디렉토리는 액세스 제어에도 사용되었습니다. READ 속성을 사용하면 사용자가 디렉토리에 파일을 나열 할 수 있었고 EXECUTE 속성을 사용하여 해당 디렉토리에있는 파일에 액세스 할 수있었습니다 (이는 다른 많은 기능과 마찬가지로 유닉스 환경에 있음).

Multics는 또한 단일 스토리지 풀을 갖는 원칙을 따랐습니다. 이면에 대해서는 논문이 없다. 단일 스토리지 풀은 당시의 하드웨어와 잘 맞았습니다. 이동식 스토리지 장치는 없었으며 사용자가 신경 쓰는 것은 없었습니다. Multics에는 별도의 백업 스토리지 풀이 있었지만 이는 사용자에게 투명했습니다.

유닉스

Unix는 Multics에서 많은 영감을 얻었지만 단순성을 목표로 한 반면 Multics는 유연성을 목표로했습니다.

단일 계층 파일 시스템이 Unix에 적합했습니다. Multics와 마찬가지로 스토리지 풀은 일반적으로 사용자와 관련이 없습니다. 그러나,를 통해,이 이동식 장치 있었고, 유닉스 사용자에게 노출 한 mount과 umount(관리자 즉, "슈퍼 유저 '에 예약) 명령. 에서 "유닉스 시분할 시스템" , 데니스 리치와 켄 톰슨 설명 :

파일 시스템의 루트는 항상 동일한 장치에 저장되지만 전체 파일 시스템 계층이이 장치에 상주 할 필요는 없습니다. 기존 일반 파일의 이름과 연관된 스토리지 볼륨 (예 : 디스크 팩)이 자체 디렉토리 계층을 포함하는 독립 파일 시스템의 구조를 가져야하는 특수 파일의 이름을 갖는 두 개의 인수가있는 마운트 시스템 요청이 있습니다. . 마운트의 효과는 지금까지 일반 파일에 대한 참조가 이동식 볼륨에서 파일 시스템의 루트 디렉토리를 참조하게하는 것입니다. 실제로 mount는 계층 구조 트리 (일반 파일)의 리프를 완전히 새로운 하위 트리 (이동식 볼륨에 저장된 계층 구조)로 바꿉니다. 마운트 후에는 이동식 볼륨의 파일과 영구 파일 시스템의 파일이 사실상 구분되지 않습니다. 예를 들어, 설치에서 루트 디렉토리는 디스크 드라이브 중 하나의 작은 파티션에 있으며 사용자 파일을 포함하는 다른 드라이브는 시스템 초기화 순서에 따라 마운트됩니다. 마운트 가능한 파일 시스템은 해당 특수 파일에 기록하여 생성됩니다. 빈 파일 시스템을 작성하기 위해 유틸리티 프로그램을 사용할 수 있거나 기존 파일 시스템을 간단히 복사 할 수도 있습니다.

계층 적 파일 시스템은 또한 여러 저장 장치를 커널로 관리하는 복잡성을 집중시키는 이점이 있습니다. 이것은 커널이 더 복잡하다는 것을 의미했지만 결과적으로 모든 응용 프로그램이 더 단순했습니다. 커널은 하드웨어 장치를 신경 써야하지만 대부분의 응용 프로그램은 신경 쓰지 않기 때문에보다 자연스러운 디자인입니다.

윈도우

Windows는 원래 VAX 미니 컴퓨터 용으로 설계된 운영 체제 인 VMS 와 초기 인텔 마이크로 컴퓨터 용으로 설계된 운영 체제 인 CP / M의 두 계보로 거슬러 올라갑니다 .

VMS에는 분산 계층 파일 시스템 인 Files-11이 있었습니다. 파일 -11에서 파일의 전체 경로 에는 노드 이름, 해당 노드의 계정 지정, 장치 이름, 디렉토리 트리 경로, 파일 이름, 파일 유형 및 버전 번호가 포함됩니다. VMS에는 강력한 논리적 이름 기능이있어 특정 디렉토리에 바로 가기를 정의 할 수 있으므로 사용자는 디렉토리의 "실제"위치에 대해 거의 신경 쓰지 않아도됩니다.

CP / M은 64kB의 RAM과 플로피 드라이브가있는 컴퓨터 용으로 설계되었으므로 간단합니다. 디렉토리가 없지만 파일 참조에 드라이브 표시 ( A:또는 B:) 가 포함될 수 있습니다 .

MS-DOS 2.0에서 디렉토리를 도입 했을 때 CP / M을 따르는 MS-DOS 1과 호환되는 구문을 사용했습니다. 따라서 경로는 단일 문자 이름을 가진 드라이브에서 시작되었습니다. (슬래시 문자 /는 VMS 및 CP / M에서 명령 행 옵션을 시작하는 데 사용되었으므로 다른 문자를 디렉토리 구분 기호로 사용해야했습니다. 따라서 일부 내부 구성 요소도 슬래시를 지원하지만 DOS 및 이후 Windows는 백 슬래시를 사용합니다) ).

Windows는 DOS 및 VMS 접근 방식과의 호환성을 유지하므로 관련성이 떨어지더라도 드라이브 문자 개념을 유지했습니다. 오늘날, Windows는 UNC 경로 ( 원래 Microsoft와 OS 에서 OS / 2 용으로 개발 한) UNC 경로를 사용합니다 . 이 기능은 고급 사용자 용으로 예약되어 있지만 (이력 가중치로 인해) Windows는 재분석 지점을 통한 마운트를 허용 합니다.

단일 디렉토리 트리를 갖는 것에 대한 보안 문제는 없습니다.

유닉스를 디자인 한 사람들은 운영 체제에 대한 경험이 풍부하여 사용자에게 주어진 리소스가 포함 된 물리적 장치가 무엇인지 알아야했습니다. 운영 체제의 목적 중 일부는 실제 하드웨어 위에 추상 시스템을 작성하는 것이기 때문에 물리적 위치에 따라 주소 지정 리소스를 사용하는 것이 훨씬 간단하다고 생각하고 모든 것을 단일 이름 트리에 배치하기로 결정했습니다.

이것은 유닉스 디자인의 배후의 천재에 불과 합니다.

최신 Windows에 유지되는 MS-DOS의 드라이브 문자 이름은 여기에서 빨간색 청어입니다. 드라이브 문자 이름은 여러 루트가있는 파일 시스템 구조를 가장 잘 나타내지는 않습니다. 그것들은 그러한 시스템의 스트로 맨 구현입니다.

여러 루트를 지원하는 올바르게 구현 된 파일 시스템은 다음과 같이 볼륨의 이름을 임의로 지정할 수 dvdrom:/path/to/file.avi있습니다. 시스템과 같은 Windows를 괴롭히는 웃기는 사용자 인터페이스 문제를 제거합니다. 예를 들어 카메라와 같은 장치를 연결하면 Windows 탐색기 UI에서 Camera (또는 기타)라는 장치가 있고 경로가 같은 것으로 생각 Computer\Camera\DCIM\...합니다. 그러나이 경로의 텍스트 버전을 탐색기에서 잘라내어 붙여 넣으면 일부 경로 이름 구성 요소가 기본 OS에 알려지지 않은 사용자 인터페이스 소설이기 때문에 실제로 작동하지 않습니다. 루트가 여러 개인 올바르게 구현 된 시스템에서는 문제가 없습니다.camera:\DCIM\...시스템의 모든 수준에서 균일하게 인식되는 경로. 또한 OLD PC에서 오래된 하드 드라이브를 이식 한 경우와 같은 드라이브 이름이 붙어 있지 F:않고 원하는 이름을 지정할 수 있습니다 old-disk:.

따라서, 유닉스가 파일 시스템 구조에 여러 개의 루트를 가지고 있다면, 한 글자로 된 드라이브 이름을 가진 MS-DOS와 Windows에서는 그렇지 않을 것입니다. 다시 말해, 유닉스 체계를 좋은 다중 루트 설계와 비교해 보자.

그렇다면 왜 유닉스는 제 1의 단일 루트 구현에 유리한 제 2의 다중 루트 구현을 가지고 있지 않습니까? 아마도 단순성을 위해서 일 것입니다. 마운트 지점은 이름을 통해 볼륨에 액세스 할 수있는 모든 기능을 제공합니다. 추가 접두사 구문으로 네임 스페이스를 확장 할 필요가 없습니다.

수학적으로 말하자면, 분리 된 트리 그래프 ( "포리스트")는 루트 노드를 추가하고 분리 된 조각을 자식으로 만들어 결합 할 수 있습니다.

또한 볼륨이 루트 수준 일 필요가없는 것이 더 유연합니다. 볼륨을 나타내는 특수 구문이 없기 때문에 (단지 경로 구성 요소 임) 마운트 지점은 어디에나있을 수 있습니다. 당신이 당신의 컴퓨터에 세 이전 디스크에 가져올 경우, 당신이 그들을 할 수 있습니다 /old-disk/one, /old-disk/two등 당신이 원하는 그러나 당신은 디스크를 구성 할 수 있습니다, 당신은 파일과 디렉토리를 구성하는 방식.

경로에 따라 응용 프로그램을 작성할 수 있으며 스토리지 장치를 재구성 할 때 경로의 유효성을 유지할 수 있습니다. 예를 들어, 응용 프로그램과 같은 잘 알려진 경로를 사용할 수 있습니다 /var/log와 /var/lib. 그것은 여부에이야 /var/log와 /var/lib같은 디스크 볼륨 또는 별도의 것들에 있습니다. 경로를 유지하면서 시스템을 새로운 스토리지 토폴로지로 마이그레이션 할 수 있습니다.

탑재 지점은 좋은 생각이므로 Windows는 Windows 2000 전후부터 계속 사용하고 있습니다.

볼륨 탑재 지점은 컴퓨터에서 장치를 추가하거나 제거 할 때 발생하는 시스템 변경에 대해 강력합니다. Microsoft Technet

* nix와 Windows 모두 드라이브를 마운트합니다. Windows에서는 기본적으로 알파벳 순서로 오름차순으로 마운트 지점에 마운트됩니다. 이러한 기본값은 다음과 같습니다.

• A:그리고 B:=> 플로피
• C: => 첫 번째 하드 드라이브의 첫 번째 파티션
• D: => 다른 파티션이없는 경우 다음 파티션 또는 다음 하드 드라이브 또는 CD / DVD 드라이브.

이러한 각 마운트 지점은 디렉토리입니다.

* nix에서 마운트 지점은 사용자가 결정합니다. 예를 들어, 하나의 파티션을로 마운트 /하고 다른 파티션을로 마운트 했습니다 /home. 따라서 /home별도의 드라이브이므로 E:Windows 의 경우와 같습니다 .

두 경우 모두 Windows와 * nix에서 마운트 지점은 별도의 디렉토리입니다. 유일한 차이점은 * nix에서 스크립트에서, 이러한 별도의 디렉토리의 하위 디렉토리 있다는 것입니다 /때문에, C:윈도우에있는 동안, 모든 지점이 바로 아래에 장착 마운트 /아래 My Computer의 말을하자이.

사용자 관점에서 볼 때 주요 장점은 마운트가 완전히 투명하다는 것입니다. 디렉토리 /home가 실제로 별도의 파티션에 있다는 것을 알 필요가 없습니다 . 그냥 일반 디렉토리로 사용할 수 있습니다. 대신 DOS에서는 마운트 포인트 이름으로 명시 적으로 호출해야합니다.E:\home

외부 드라이브는 두 시스템에서 거의 같은 방식으로 마운트됩니다. D:Windows와 /mnt/cdromLinux를 말하십시오 . 이들 각각은 디렉토리이며, 실제로 차이점을 보지 못합니다. Windows에서 CDROM을 드라이브에 넣으면 디스크는 D:Linux와 마찬가지로 마운트됩니다 .

위의 답변, 특히 Doug O'Neal의 답변에 동의하지만 MS-DOS "C :"또는 "A :"와 같은 명시 적 장치 마운트 지점과 마찬가지로 모두 조금씩 빠진 것 같습니다.

Rob Pike는 이름의 구문에 대해 The Hideous Name을 썼지 만 Russ Cox는 그 이름 을 정리했습니다 .

네임 스페이스는 새로운 구문을 추가하지 않고 새로운 의미를 추가 할 수있을 때 가장 강력합니다.

장치를 임의로 마운트 할 수있는 단일 네임 스페이스를 통해 매우 유연한 작업이 가능합니다. 나는 현재 사용하지 않는 디스크 나 CD를 정기적으로 사용 /mnt/sdb1하고 /mnt/cdrom전체 파일 시스템에 임시로 넣습니다. NFS 서버에 홈 디렉토리를 갖는 것은 드문 일이 아니므로 로그인 한 시스템에 관계없이 $HOME모든 곳 에서 동일하게 사용할 수 있습니다.

그것은 특별한 것들을위한 특별한 문법을 ​​갖는 것이 당신이 할 수있는 것에 대한 명확한 한계를 부여합니다. 사용하지 않은 디스크, CD 또는 DVD 또는 "E :"또는 "W :"등의 네트워크 파일 시스템 / "공유"만 마운트 할 수 있다면 유연성이 훨씬 떨어집니다.

이것은 바보입니다. Windows에는 단일 계층 구조 지점도 있습니다. 그러나 그것은 숨겨져 있고 비표준입니다. 대부분의 것들로 창.

이 경우 "내 컴퓨터"개념입니다. 이것은 유닉스에서 루트 (/)와 같습니다. 루트는 커널에 존재하는 개념입니다. 당신은 그것을 좋아하든 않든. 창문이 "내 컴퓨터"를 취급하는 것처럼. 물론 유닉스에서 루트에 파티션을 마운트 할 수 있으며, 이것이 대부분의 사람들이하는 일입니다. 그리고 많은 것들이 특정 경로 (예 : / etc /)를 보게 될 것입니다. 그러나 당신은 이것으로 제한되지 않습니다. 반드시 드라이브를 / C : /에 마운트하십시오. 유닉스에서는 그렇게 할 수 없습니다.

C : \는 Windows의 루트가 아니며 하나의 파티션의 마운트 지점입니다. 최상위 "내 컴퓨터"에 있어야합니다. 유닉스에서는 다른 트리 아래에 파티션을 마운트 할 수 있습니다. 따라서 리눅스에서는 C :을 마운트 /할 수 있으며 D : 마운트 된 /mnt/d/... 또는 마운트 된 경우도 /있지만 까다 롭고 이미 마운트 된 경로 위에 마운트 할 때 두 파일 시스템의 동작에 달려 있습니다.

따라서 창에 무작위로 부과하는 것과 동일한 제한을 따르도록 "강제"함으로써 창과 정확히 동일하게 얻을 수 있습니다.

/ (treat this as "My Computer")
/c/ (mount your first data partition here)
/d/ (mount your second data partition here)

그런 다음 부팅 옵션에서 마운트 옵션을 전달해야합니다. 왜냐하면 당신은 / etc / ...를 가지지 않을 것입니다. 그러나 그것은 또한 그것이하는 것처럼 윈도우가 부과하는 한계를 시뮬레이션하고 있습니다.

Windows가 드라이브 문자를 갖는 이유는 아마도 Microsoft와 DOS보다 더 먼 것입니다. IBM 시스템에서는 이동식 드라이브에 문자를 할당하는 것이 일반적이므로 Microsoft는 CP / M을 복사하여 IBM의 지시에 따라 조치를 취했을 수 있습니다. 그리고 처음에는 DOS에 디렉토리가 없었습니다.

MS-DOS가 하나 또는 두 개의 이동식 디스크가 있고 고정 매체가없는 컴퓨터에서 실행될 때 실제로 디렉토리가있는 파일 시스템이 필요하지 않았습니다. 하나 또는 두 개의 180 킬로바이트 디스크를 사용하면 디스크를 구성하는 데 많은 어려움을 겪을만큼 충분한 파일이 없었습니다.

https://en.wikipedia.org/wiki/Drive_letter_assignment

실제로 Linux는 Unix (또는 Unix, 토론 참조 )를 기반으로 하며 Unix는 여러 장치를 사용하는 것이 분명한 메인 프레임 환경에서 제공됩니다. 단일 디렉토리 트리 내에 장치를 마운트하면 최대한의 유연성을 제공하며 운영 체제가 액세스 할 수있는 장치 수를 제한하지 않습니다.

다른 한편으로, 드라이브 용 DOS 문자는 1 개 또는 2 개의 플로피 스테이션과 단일 디스크 드라이브가있는 PC에 적합합니다. 큰 플로피 5,25 '는 항상 A :, 작은 하나의 3,5'는 항상 B :이며 디스크 드라이브는 항상 C :입니다. 플로피 나 디스크 어딘가에 파일을 복사하는지 항상 알고 있습니다. 두 개 이상의 플로피 드라이브와 2 개 (또는 4 개)의 하드 디스크를 물리적으로 연결할 수없는 경우 유연성이 필요하지 않습니다.

DOS 디자인은 최종 사용자에게 친숙한 반면, Unix 디자인은 관리자에게 친숙합니다. 이제 드라이브 문자는 Windows의 부담이며, 사용자는 문자를 아는 것보다 이동식 드라이브 내용으로 탐색기 창을 자동으로 여는 데 더 의존합니다. 우분투는 실제로 동일합니다.

사실이 아닙니다. Windows는 다른 경로 구성표를 사용합니다 (잘 같지 않음)

"단어 문자"는 경로, 디스크 및 파티션을 쉽게 기억할 수있는 것입니다.

ARC 경로는 Windows에서 파일의 경로를 정의합니다 (하지만 부팅시에만 사용자에게 표시됨).

http://support.microsoft.com/kb/102873

https://serverfault.com/questions/5910/how-do-i-de-termine-the-arc-path-for-a-particular-drive-letter-in-windows

Windows NT에서는 디스크, 파티션 및 단위 문자 사이에 관계가 없습니다. 폴더에 전체 볼륨을 "넣을"수 있습니다 (예 : c : \ myseconddisk는 전체 물리 디스크 일 수 있습니다!).

내가 지적하고 싶은 두 가지-

1. Linux의 하드 드라이브는 실제로 / dev / sdb1과 같은 문자 / 이름이 할당 된 방식입니다. 그러나 단일 / 루트 구조에서 도달 할 수있는 곳이라면 어디든지 마운트 할 수 있습니다
2. 사람들 (과거 자신을 포함하여)이 Windows에 별도의 드라이브를 가지고 있었던 가장 일반적인 이유는 문서, 음악, 프로그램 등을 보관할 수있는 곳이있어서 Windows를 다시 설치하거나 교체해야 할 때 업그레이드 나 바이러스 또는 파일 시스템 오류가 발생해도 해당 파일에 여전히 액세스 할 수있었습니다. 나는 리눅스 에서이 문제가 없다-파일 시스템은 훨씬 더 안정적이며, 직접 행동이나 실수로 내 부분 (Ooh! 최첨단 저장소, 시도해보십시오!)으로 업그레이드하지 않으면 OS가 중단되지 않습니다. 더 간단합니다. 그리고 드문 경우에, 내가 추가 한 repos 또는 ppa를 통해 모든 소프트웨어를 사용할 수 있었기 때문에 다시 설치해야했습니다.

역사를 되돌아 보면, 오디오 용 8 개의 트랙 테이프 시스템과 9 개의 트랙 IBM 데이터 시스템 (데이터 용 8 트랙 / 8 비트, 패리티 용 1 트랙) 당시 Unix가 시작된 것을 볼 수 있습니다. 기술적으로는 거의 동일합니다.

당시 파일 위치에 대한 정보는 테이프에서 정보의 일부로 저장되었으며 테이프에서 데이터를 읽을 때 (시작 위치 및 종료 서명이있는 파일과 같이) 앞뒤로 정의되었습니다. 또한 드라이브 시작시 단 하나의 FAT가 아니라 왜 조회 속도를 높이기 위해 여러 개의 FAT를 사용했는지 설명합니다. 그리고 여러 개의 드라이브가있는 경우 / dev 내부와 파일 주소를 통해 연결된 위치에서 장치간에 이동했습니다.

MS Dos 영역 (CP / M) 및 이후 Windows NT의 결정은 단순히 시작 시점이 아니라 단일 진입 점 대신 VM 메인 프레임 드라이브 문자와 관련이 있다고 생각할 수 있습니다. 더 현대적인 오늘날의 데이터 양은 존재하지 않았으며 결국 드라이브 문자가 충분하지 않거나 어수선해질 것이라고 생각하지 않았습니다.

9 트랙 드라이브 및 드라이브 문자 할당