/usr/bin 및 /usr/sbin을 /bin(GNU/Linux)으로 병합

/ 대신 /usr에 콘텐츠를 병합하는 이유는 다음과 같습니다./usr 병합 사례:

오해 #11: /를 /usr로 병합하는 것보다 /usr을 /로 병합하는 것이 더 합리적입니다.

사실: 이로 인해 공급업체가 제공한 OS 리소스와 시스템별 리소스 간의 분리가 더 심해져서 OS 스냅샷과 네트워크/컨테이너 공유가 더 어렵고 비원자적이게 되며, 대규모 새 디렉터리로 인해 루트 파일 시스템이 복잡해집니다.

당신 말이 맞습니다. Fedora는 이 점에서는 아방가르드입니다.무료 데스크톱 웹사이트이후 독립 조직이 범 리눅스를 장려하기 위해 프로젝트를 시작했습니다.

~에 따르면이것, 병합은 Solaris("주요 상용 Unix 구현")에서 시작한 패턴을 따릅니다. 흥미롭게도 원시 Unix를 사용했기 /bin때문에 분할을 제거한다는 것은 아마도 /usr심볼릭 링크에 디렉터리를 만드는 것을 의미했을 것입니다. 그 반대는 아닙니다.

그러나 이 옵션을 염두에 두고 최상위 수준을 연결하는 것이 더 직접적이고 명확할 수 있습니다.

/sbin 및 /usr/sbin은 역사적으로 정적으로 링크된 바이너리가 보관되는 곳입니다. /sbin은 초기화 레벨 1(단일 사용자 모드)에 필요한 관리 수준 명령에 사용되고 /usr/sbin은 초기화 레벨 3(전체 네트워킹, 원격 로그인 활성화, NFS 활성화)에 필요한 보다 일반적인 관리 명령에 사용됩니다. . 불행하게도 Linux는 더 이상 이 모델을 채택하지 않습니다.

시스템 엔지니어로서 저는 이러한 추세가 유감스럽다고 생각합니다. 예를 들어, 플래시 메모리는 액세스 속도가 매우 빠르지만 가격이 비싸고(회전 디스크 미디어보다 GB당 3배 더 비쌉니다), 장치가 제대로 작동하지 않기 전에 메모리 비트에 정전기가 쌓이는 문제가 있습니다. 너무 많은 양의 데이터만 쓸 수 있습니다. 사용할 수 없음(소프트 오류는 먼저 장치 펌웨어에 의해 수정된 다음 하드 오류가 수정되며 이 시점에서 장치는 읽기 전용으로 표시됩니다).

그래서 우리는 여전히 "빠르고 값비싼 메모리"와 "느리고 값싼 메모리"를 갖고 있는 것입니다.

Raspberry Pi에서도 저는 작은 2.5인치 디스크(노트북 크기)를 USB 3.0 포트에 연결하고, 필요한 모든 부팅 관련 항목을 /bin에 넣고, 중요하지 않은 모든 항목( USER! )은 /usr 및 다음 위치에 두는 것을 선호합니다. /tmp 및 /var/tmp, 특히 /var/log 및 /var/cache와 같은 많은 쓰기 활동... 더 저렴하고 내구성이 뛰어난 1TB 2.5" 디스크에 이러한 하위 트리가 지속적으로 기록되기 때문입니다. 시스템을 설정할 때 나는 일반적으로 쓰기가 높은 퀀텀 트리를 중간 쓰기 퀀텀 트리에서 분리하고 쓰기가 낮은 퀀텀 트리를 /var/log와 별도로 사용자 계정 파일 시스템(/home 또는 기타)으로 분리하기 위해 정확하게 일부 파일 시스템을 만듭니다.

/opt는 /usr/_opt에 대한 포인터가 될 수 있습니다. (저는 심볼릭 링크의 출처를 나타내기 위해 접두사와 접두어 _ 문자를 심볼릭 링크 대상으로 사용합니다. 따라서 /opt는 /usr/_opt를 가리키는 심볼릭 링크가 됩니다. /tmp는 /mnt /highwrites가 됩니다. /_tmp, 그리고 /var/tmp는 /mnt/highwrites/_var_tmp에 대한 심볼릭 링크가 되므로 어떤 "tmp" 디렉토리에 더 많은 공간이 필요할지 추측할 필요가 없습니다. 모두 동일한 파일 시스템에 있습니다. 빈번하고 무거운 쓰기는 문제가 발생할 때 다른 모든 파일 시스템에서 안전하게 격리됩니다. 이 시점에서는 루트 파일 시스템에 너무 많은(또는 이상적으로는 모든) 파일 시스템을 쓰는 것을 원하지 않습니다.

/usr과 /를 병합하는 것은 항상 어리석은 계획이었고, Sun Microsystems와 그 역사를 존경하는 만큼 Sun이 이런 광기를 시작했는지 여부는 전혀 신경 쓰지 않습니다. 가장 중요한 설치된 태양광 시스템은 매일 사용되는 적절한 시스템 백업 리소스를 보유할 만큼 충분히 비싸고 중요합니다. 일반 Linux 시스템에는 특히 가정 및 소규모 기업 사용자에게 그러한 자본 투자가 없습니다.

따라서 기본 구성은 보안 측면에서 오류가 발생해야 하며 자체 파일 시스템에서 가장 많은 활동이 있는 디렉터리를 분리하여 대부분의 파일 시스템 쓰기를 격리해야 합니다. 이를 통해 전체 파일 시스템을 통합하는 대신 데이터 손실을 최소화하고 문제를 가장 가치 있는 항목에 전파합니다. 파일(1. 사용자 데이터, 시스템 시작과 손상 평가 및 복구에 필요한 실행 파일 및 디렉터리(fsck, 덤프 및 복원 유형 프로그램, mkfs, mkswap 및 일부 파일) grep 등과 같은 기타 유용한 프로그램 및 물론 모두 하드웨어 및 일부 가상(예: RAID) 장치 드라이버)

Userland 응용 프로그램은 전통적으로 /bin 및 /sbin에 있는 "시스템 필수 항목"보다 훨씬 더 자주 업그레이드 및 버그 수정을 받는 경향이 있습니다. 파일 시스템을 작게 유지하고 쓰기를 하면 손상 가능성이 거의 줄어들지 않습니다. 전통적으로 /usr에 있는 내용이 손상되었는지는 별로 신경 쓰지 않지만, mount 및 fsck가 손상된 파일 시스템에 있는지는 확실히 신경쓰입니다.

단일 스토리지 기술(예: 단일 1TB 하드 드라이브)을 사용하는 경우에도 루트 파티션을 가능한 한 작게 유지해야 한다는 간단한 이유 때문에 /usr을 별도의 파티션에 두는 것이 더 합리적입니다. 가능한 한 씁니다.

"가능한 한 빨리 설치"에 관해서는... 대부분의 부팅 구성에서는 커널이 로드되면 / 파일 시스템이 fscked된 다음 마운트됩니다... 그런 다음 다른 모든 파일 시스템이 fscked되고 마운트됩니다. fstab은 시작 시 설치로 구성되므로 " 더 빠른 가용성"은 문제가 되지 않습니다. 또한 연속적으로 fsck하는 10개의 작은 파일 시스템은 단일 파일 시스템보다 더 빠르게 fsck할 수 있습니다. 읽기 및 쓰기 헤드의 앞뒤 헤드 이동이 좁은 범위 내에서 유지되어 검색 기간이 더 짧아지고, 두 번째로 다음 헤드를 찾기 위한 헤드가 약간 길어지기 때문입니다. 전체 단일 디스크를 포괄하는 파일 시스템은 내부 트랙에서 먼 외부 트랙으로 수천 번 이동할 수 있습니다.

단일 디스크를 여러 파일 시스템으로 나눌 때의 유일한 단점은 대부분의 쓰기 작업을 중간에 있는 일련의 파티션이 아닌 첫 번째와 마지막 파티션에서 수행하고 디스크가 하나의 A 파일 시스템에서 변경되는 경우입니다. 한 파티션의 파일이 다른 파티션의 파일 시스템으로 이동되면 모두 통합된 단일 파일 시스템에 있는 경우보다 더 많은 빈 블록을 통과해야 합니다.

전체적으로 단일 파일 시스템의 이점은 단일 저장 장치를 여러 파일 시스템으로 분할하는 이점보다 여전히 중요합니다. 안정성과 데이터 보안 관점에서 볼 때, 다중 파일 시스템(각각 자체 장치에 있음)이 선호되는(비록 가장 비용이 많이 드는) 접근 방식입니다. 병렬 SCSI가 보편화되었을 때 중고 SCSI 디스크를 값싸게 구입하곤 했습니다. 하나는 /용, 하나는 /usr용, 하나는 /home용으로 가장 작은(보통 가장 오래된 것) /tmp, /var/tmp 및 /var/log. 이 장치는 일반적으로 가장 작고 실패할 가능성이 높으며 파일의 가치는 상대적으로 낮습니다(사용자가 지정하지 않는 한 프로그램은 결과를 /tmp에 저장하지 않습니다... 따라서 /tmp 및 /var/tmps에는 일회용 데이터가 있습니다. "스크래치" 영역이며 단일 /tmp 디렉토리는 NFS를 통해 여러 호스트에서 공유될 수 있습니다. /var/tmp는 공유된 /tmp에서 찾을 수 없는 tmp 파일에 사용됩니다.

Poettering은 실제로 Linux를 MS-WINTENDO로 단순화하려고 노력했습니다.