선택할 파일 시스템을 Freebsd에서 선택하세요. 자동 마운트를 설정합니다. 설명이 포함된 자세한 지침

알렉세이 페도르추크
2004-2005

이 노트에서는 디스크 파티션 블록을 물리적으로 구성하는 방법에 대해 설명하고, FreBSD에 특정한 파일을 작성, 저장 및 조작하는 기능을 제공합니다. 더 정확하게는 이 문서의 유일한 기본 파일인 UFS 및 UFS2 파일 시스템에 대해 설명합니다. ZFS 포팅 전의 OS.

소개

FreeBSD 파일 시스템은 Unix 파일 시스템 제품군에 속하며 모든 시스템에 공통된 많은 기능을 가지고 있습니다. UFS라고 하며 5번째 브랜치에서는 향상된 버전인 UFS2가 사용됩니다. 먼저 살펴 보겠습니다. 일반 원칙그런 다음 UFS2 고유의 기능을 고려하겠습니다.

FreeBSD 파일 시스템(및 4.2BSD부터 시작하는 일반적인 BSD 시스템)의 경우 다른 이름인 FFS(Fast 파일 시스템). 이 용어들의 상관관계를 이해하려면 역사를 살펴볼 필요가 있습니다.

초기 파일 유닉스 시스템 s5fs라는 이름을 지녔습니다(즉, 파일 시스템 시스템 V). 동시대 사람들에 따르면 속도가 매우 느렸고 14자를 초과하는 파일 이름도 허용하지 않았습니다. 그리고 당시 버클리 대학에서는 Unix 버전(모든 현대 BSD 시스템의 전신인 BSD Unix라고 함)이 개발 중이었기 때문에 그들은 문제를 개선하기로 결정했습니다. 그리고 그들은 FFS라는 파일 시스템을 만들었습니다(여기서 Fast는 s5fs에 비해 속도를 의미함).

Berkeleyan의 개발은 초기에 무료였기 때문에(RMS가 오픈 소스와 자유 소프트웨어 재단을 내놓기 전에도) 원래 Unix 개발자들은 정식 System V의 다음 버전에 FFS 지원을 포함하는 것을 주저하지 않았습니다. 그리고 대부분 현대 Unix 파일 시스템의 대부분은 독점 및 무료 모두 에서 나왔습니다. 그리고 UFS는 가상 파일 시스템인 vfs/vnode의 요소를 포함하는 그러한 구현 중 하나입니다(적어도 Yu.Vakhalia가 자신의 저서 "Unix from the Inside"에서 이러한 개념을 해석하는 방법은 다음과 같습니다). 그리고 짐작할 수 있듯이 UFS2는 UFS2의 향상된 64비트 버전입니다.

일반적으로 UFS는 단순히 Unix File System을 나타냅니다. 그리고 이 이름으로 이 제품군의 다른 운영 체제의 파일 시스템도 알려져 있는데 이는 FreeBSD의 UFS와 결코 동일하지 않습니다. 그래서 용어에 대한 불확실성이 있습니다 ...

에서 알 수 있듯이 논리 디스크 파티션(슬라이스의 일부)은 비유적으로 말하면 512바이트의 물리적 블록으로 나누어진 인접한 실린더 그룹입니다. 그러나 BSD 클랜 파일 시스템의 특징은 실제로는 (파티션 볼륨에 따라) 고정 볼륨의 일부로 분할된다는 것입니다. 이것이 소위 각각 4개의 독립적인 부분으로 구성된 실린더 그룹(내부라고 함)

모든 그룹의 내용이 동일한 수퍼 블록;
그것을 설명하는 실린더 그룹의 블록; 가장 중요한 부분 중 하나는
인덱스 테이블(또는 테이블 아이노드);
데이터 블록 영역.

목록 끝, 즉 데이터 영역부터 검사를 시작하는 것이 좋습니다.

데이터 블록

데이터 영역(각 실린더 그룹의 압도적인 공간을 차지함)은 파일 시스템 블록으로 구성됩니다. 물리적 블록과 마찬가지로 파일 시스템 블록(논리 블록이라고도 함)은 한 번의 읽기/쓰기 작업에서 사용할 수 있는 정보의 양이지만 디스크 헤드에서는 사용할 수 없습니다. 운영 체제. 분명히 논리적 블록은 물리적 블록(즉, 512바이트)보다 작을 수 없으며 크기는 반드시 물리적 블록의 정수배입니다.

디스크 연산의 성능을 향상시키기 위해 논리 블록이라는 개념이 도입되었습니다. 이 진술에는 1KB 퀀텀의 데이터 교환 속도가 512바이트 퀀텀보다 높으며 2KB 퀀텀이 더 빠르다는 등의 증거가 필요하지 않습니다. 따라서 파일 작업 속도 측면에서 유리합니다. 최대 크기파일 시스템의 논리적 블록.

반면에 논리 블록의 크기를 늘리면 낭비가 발생합니다. 디스크 공간소위 때문에 내부 데이터 조각화. 전투원이 있는 모든 종류의 스피드 디스크가 한때 FAT 계열 파일 시스템에 동원되었던 것과 싸우기 위해 외부 조각화와 혼동해서는 안 됩니다. 데이터 관리 알고리즘의 특성으로 인해 Unix 계열 파일 시스템은 외부 조각화에 거의 영향을 받지 않으므로 극복하는 것은 불가능합니다. 그들은 실제로 그것에 대해 전혀 이야기하지 않습니다.

내부 단편화는 파일 시스템 블록보다 크기가 작은 파일 데이터가 여전히 전체를 점유한다는 사실로 표현됩니다. 또한 파일 테일, 즉 논리 블록 크기의 배수인 볼륨을 초과하는 잔여물을 저장하려면 전체 블록이 필요합니다. 동어반복을 해서 죄송하지만 UFS의 조각화를 방지하기 위해 조각 개념이 도입되었습니다. 조각은 나머지 부분과 독립적으로 쓰거나 읽을 수 있는 파일 시스템 블록의 논리적 부분입니다.

조각 크기는 여전히 물리적 블록보다 작을 수 없다는 것이 분명합니다. 동시에 UFS는 이에 대한 반대 제한도 적용합니다. 최소 조각 크기는 논리 블록의 1/8로 결정됩니다. 다른 가능한 값은 파일 시스템 블록의 1/4 및 1/2입니다(분명히 블록 크기에 조각을 할당하는 것은 금지되지는 않지만 블록 조각화를 전혀 거부하는 것과 같습니다).

아이노드

데이터 블록이 특정 파일에 속하는지 어떻게 확인합니까? 테이블이라고도 하는 인덱스 테이블 사용 아이노드또는 테이블 아이노드. 이는 고정 길이(UFS의 경우 128바이트, UFS2의 경우 256바이트)의 특정(유한) 수의 레코드로 구성되며, 각 레코드는 실제로 존재하거나 생성만 가능한 하나의 파일에 고유하게 해당합니다.

이 인덱스 테이블 항목은 다음과 같습니다. 아이노드, 우리는 그녀를 남겨 둘 것입니다. 정보 노드나 색인 설명자처럼 나에게 알려진 이 용어의 모든 번역은 매우 서투르게 보이기 때문입니다. 또한 "설명자"라는 단어는 "파일 설명자"라는 맥락에서도 나타납니다. 이는 특정 프로세스에서 사용하는 파일의 식별자(고유하지 않으면 무엇을 식별합니까?)를 의미합니다(파일 시스템과 관련 없음). - 이는 프로세스 제어 하위 시스템의 범위입니다. 그리고 이러한 설명자는 서로 공통점이 없습니다. 그래서, 아이노드식별자 2(이것은 항상 파일 시스템의 루트 디렉터리 식별자임)와 파일 설명자 번호 2(모든 프로세스에 대해 이는 표준 오류 메시지 출력 장치인 /dev/stderr임)와 어떤 방식으로도 상관 관계가 없습니다. (어떤 이유로 그들은 큰 소리로 말하는 것을 좋아하지 않지만 이에 대해 더 자세히 설명합니다.)

그러나 나는 빗나갔습니다. 우리의 이야기로 돌아가자 아이노드. 이 테이블의 각 멤버에는 파일 메타데이터라는 것이 포함되어 있습니다. 진짜로 기존 파일여기에는 다음이 포함됩니다.

고유 식별자 아이노드(따라서 메타데이터가 포함된 파일은) 단순히 파일 시스템에서 생성된 파일의 카운터입니다.
파일 유형 - 디렉터리, 기호 링크, 장치 파일, 명명된 파이프나 소켓 또는 일반(즉, 나열된 유형과 관련되지 않음) 파일일 수 있습니다.
파일 크기(바이트);
파일에 대한 링크 수(이 문제에 대해서는 조금 더 낮은 수준으로 다시 설명하겠습니다)
파일을 구성하는 논리 블록 및 해당 조각의 주소
그것이 차지하는 블록의 수;
파일 속성 - 소유권, 액세스, 모드, 시간.

그런데 안에 뭐가 들어있어요? 아이노드어떤 방법으로도 발견할 수 없습니다. 따라서 이것은 그 사람(또는 그녀?)에 해당하는 이름입니다. 어떤 이유에서인지는 다음과 같습니다. 아이노드, 문법과 달리 여성형입니다). 유닉스에 관한 모든 책에서 그들은 파일 이름이 파일 자체의 속성이 아니라 파일이 속한 디렉토리의 요소라는 점을 반복해서 반복합니다(그리고 저는 이 좋은 전통에서 벗어나지 않을 것입니다). 소프트 업데이트 메커니즘에 익숙해지면 이를 곧 이해해야 하므로 FreeBSD(및 일반적으로 Unix)의 파일 이름 지정 문제를 명확히 하기 위해 약간의 여담을 만들겠습니다.

테이블 내용을 설명할 때 아이노드파일 형식 필드가 전달 중에 언급되었습니다. 따라서 Unix에서는 모든 파일(및 물리적 장치를 포함하여 Unix에서 사용 가능한 모든 항목이 시스템에 파일로 표시됨)이 디렉터리와 기타라는 두 그룹으로 나뉩니다. 다른 파일은 다양한 목적(데이터 및 실행 프로그램 저장, 기호 링크, 장치 설명 또는 프로세스 간 상호 작용 수단)으로 사용될 수 있습니다. 디렉토리의 목적은 유일하지만 매우 중요합니다. 고유하게 할당된 식별자인 디렉토리에 포함된 파일 이름을 관리하는 것입니다. 아이노드, 이러한 파일의 메타데이터를 저장합니다.

즉, 파일 이름은 디렉토리 목록에만 존재하고 시스템의 다른 위치에는 존재하지 않습니다. 그리고 파일을 생성한다는 것은 인덱스 테이블에서 해당 항목과 관련된 항목을 채우고 여기에 지정된 데이터 블록을 채우는 것뿐만 아니라 "식별자 - 파일 이름" 형식의 레코드를 의 데이터 영역에 입력하는 것을 의미합니다. 디렉토리. 그리고 다른 파일과 마찬가지로 디렉터리에는 테이블에 자체 메타데이터가 있습니다. 아이노드그리고 귀하의 데이터 영역. 그리고 그 이름은 inode 식별자와 함께 해당 디렉토리에 포함됩니다. 높은 레벨, 등을 파일 시스템의 루트까지 계속합니다. 링크 수 필드에서 아이노드 생성된 파일최소한으로 설치 가능한 의미, 1과 같습니다. 모든 파일이 적어도 하나의 디렉터리에 포함되어 있기 때문입니다. 그렇지 않으면 시스템에서 액세스할 수 없습니다. 링크 수가 0인 파일은 존재하지 않는 것 같습니다(실제로는 아이노드그리고 데이터 블록은 시간이 지남에 따라 필연적으로 물리적으로 덮어쓰게 됩니다. 물론, 파일이 어떤 프로그램에서든 열리지 않았다면 - 이 경우 이름이 모든 디렉토리에서 제거되더라도 파일은 존재합니다.

실제로 동일한 데이터 및 메타데이터 세트가 동일한 파일 시스템 내의 임의 개수의 디렉터리에 할당될 수 있으며 동일한 디렉터리에서 다른 이름으로 나타날 수도 있습니다. 이 경우 이에 대한 링크 수가 이에 상응합니다. 그러나 디렉토리에 대한 최소 링크 수는 2개입니다. 디렉토리에 대한 항목이 상위 디렉토리(..)와 현재 디렉토리(.. - 즉 자체)에 모두 존재하기 때문입니다. 그리고 중첩된 각 하위 디렉터리는 디렉터리의 링크 수를 1씩 증가시킵니다.

파일 이름을 디렉토리 항목으로 테이블 항목에 연결하는 링크 아이노드데이터 파일을 형성하는 데이터 블록을 하드링크라고도 합니다. 러시아어에 해당하는 좋은 단어는 "연결"이라는 단어일 수 있지만 어떻게든 인기를 얻지 못했습니다. 동일한 데이터 세트에 대한 하드 링크를 통해 또는 실행 가능한 프로그램동일한 또는 다른 디렉토리에 포함되는 것을 누구도 금지하지 않는 임의의 수의 이름을 지정할 수 있습니다. 이에 대한 유일한 조건은 이러한 모든 중복 이름이 단일 파일 시스템의 디렉터리에 있어야 한다는 것입니다(비유적으로 말하면 동일한 디스크 파티션에 있지만 소프트웨어 RAID 섹션에 표시되는 것처럼 이는 완전히 정확하지는 않습니다). .

확실성을 위해 하드 링크는 기호 링크(종종 간단히 링크라고 불리는 심볼릭 링크 - 링크 지정을 유지하고 러시아어로 하드링크 연결이라고 부르는 것이 합리적일 수 있는 이유)와 구별되어야 한다는 점에 유의합니다. 심볼릭 링크는 특별한 유형의 파일로, Windows의 바로가기나 OS/2의 섀도우와 모호하게 유사합니다. 이 파일 자체에는 데이터가 없지만 단순히 다른 파일 이름(주어진 파일 외부에 위치할 수 있음)에 대한 경로를 설명합니다. 체계).

존재하지 않는 파일의 경우 테이블의 항목을 비우십시오. 아이노드방금 예약했어요. 그리고 이러한 레코드의 개수는 물론 인덱스 테이블의 크기에 따라 특정 파일 시스템에서 실제로 생성될 수 있는 파일의 개수가 결정됩니다. 여유 레코드가 고갈되면 여유 디스크 공간의 양에 관계없이 새 파일이 하나도 생성되지 않는다는 사실이 발생합니다.

실린더 그룹 블록 및 슈퍼 블록

테이블 아이노드약속 있음/없음 카드와 함께 실린더 그룹 블록에 포함되어 있습니다. 아이노드및 약속 있음/없음 데이터 블록 맵). 이는 수용하기 위한 것입니다. 아이노드이와 관련된 데이터 블록은 가능한 한 서로 가깝습니다. 이는 머리 움직임을 최소화하여 성능을 향상시키는 것 외에도 위에서 언급한 외부 데이터 조각화를 최소화하는 것을 수반합니다.

그러나 실린더 그룹 블록에는 인덱스 테이블의 크기에 대한 정보가 없습니다. 이들이 위치한 장소는 파티션에서 첫 번째로 나오는 동일한 슈퍼블록이기 때문에(사실 모든 파티션의 첫 번째 블록은 부팅 블록이 되지만 실제로는 부팅 파티션에서만 점유됩니다. 다른 모든 파티션에서는 장소는 단순히 예약되어 있습니다). 또한 각 실린더 그룹에 복제되어 디스크의 기계적 손상에 대한 저항력을 보장합니다. 또한 슈퍼 블록은 파일 시스템 블록의 크기와 총 개수, 데이터 블록 개수, 블록 조각의 크기와 블록 내 개수, 실제로 블록 개수를 기록합니다. 파일이 많아서 바쁘다, 영구적으로 무료로 예약된 파티션의 볼륨, 그리고 지금 이야기하기에 부적절한 파일 시스템의 더 많은 특성.

서식 연습

따라서 파일 시스템을 생성하는 과정은 a) 슈퍼 블록을 할당하고 쓰기로 귀결됩니다. 일반 매개변수파일 시스템, b) 테이블 생성 아이노드(UFS에서는 Linux용 일부 최신 파일 시스템과 달리 모든 inode가 한 번에 생성되며 필요에 따라 동적으로 할당되지 않습니다.) c) 데이터 영역의 블록 레이아웃. 잊을 수 없는 Katerina Matvevna처럼 간단히 newfs라고 불리는 단일 프로그램이 이 모든 것을 담당합니다.

newfs 명령에는 단일 인수(포맷할 파티션의 파일 이름)가 필요합니다. 예:

$ newfs /dev/ad0s1a

그 후에는 모든 기본 파일 시스템 속성이 기본적으로 정의됩니다. 그러나 사용자는 명령줄에 지정된 newfs 명령 옵션을 사용하거나 항목을 통해 전역적으로 단번에 영향을 미칠 수 있습니다. 옵션 sysinstall 프로그램. 우리는 다음 옵션 중 가장 중요한 것을 고려할 것입니다.

-b 옵션은 파일 시스템의 논리적 블록 크기를 지정합니다. 최소 크기는 4096바이트이고 최대 크기는 65536입니다. 그러나 가능한 최대 크기로 모든 종류의 문제가 발생할 수 있으므로 32768바이트의 상한은 신뢰할 수 있는 것으로 간주됩니다. 그리고 상식적인 관점에서 볼 때 대부분의 경우 "기본값"인 16384바이트가 합리적으로 보입니다.

-f 옵션은 블록 조각 크기를 설정합니다. 기본적으로 2048바이트인 블록 크기의 1/8로 정의하는 것이 좋습니다. 1/4 또는 1/2 블록 값도 허용되지만 문서에서는 사용하지 않는 것이 좋습니다.

-i 옵션은 매우 중요합니다. 인덱스 테이블의 항목 수를 간접적으로 설정합니다(즉, 최대 금액파일 시스템의 파일). 이 옵션의 값은 인덱스 테이블 요소당 할당된 바이트 단위로 제공되며 블록 조각 크기의 배수여야 합니다. 기본값은 평균 예상 파일 크기(8192바이트)를 결정하는 크기의 4배입니다. 그리고 특정 파일 시스템의 최대 파일 수는 할당된 파티션의 크기를 기반으로 쉽게 계산할 수 있습니다.

또 다른 흥미로운 옵션은 -m이며, 이 값은 파티션에 할당된 전체 디스크 공간의 백분율로 표시됩니다. 그리고 이는 일반 사용자가 쓰지 못하도록 예약된 볼륨을 나타냅니다(그러나 루트 사용자는 아닙니다. 그는 항상 자신의 작업을 디스크에 쓸 수 있는 기회를 갖습니다). 이는 데이터 영역의 사용 가능한 블록 수가 거의 소진될 때(실제로 테스트됨) UFS의 파일 작업 성능이 심각하게 떨어지기 때문에 결정됩니다. 따라서 파일 시스템의 일정량(기본적으로 8%)이 강제로 예약됩니다.

이 옵션과 관련된 또 다른 옵션인 -o는 새 파일을 생성할 때 여유 데이터 블록을 할당하기 위한 알고리즘을 지정합니다. 사실 UFS는 두 가지 방법으로 배치할 수 있습니다. 첫 번째는 내부 조각화를 최소화하고 디스크 공간을 절약하기 위한 고밀도 패킹 방법입니다. 그리고 이를 볼륨별 최적화라고 합니다(-o 옵션은 값 공간을 사용합니다). 두 번째 방법(-o time)은 다음을 제공합니다. 가장 빠른 선택파일 생성 속도를 높이기 위해 무료 블록을 사용합니다(즉, Leonid Ilyich Brezhnev의 원칙인 "경제는 경제적이어야 합니다"에 반합니다). 따라서 기본값 -o는 -m 값과 상관 관계가 있습니다. 8%보다 크거나 같으면 시간 최적화가 적용되고, 작으면 볼륨 최적화가 적용됩니다. 정확히 반대 값을 명시적으로 표시하는 것은 가능합니다.

사실, 위의 모든 옵션은 일반 교육에 매우 중요하고 흥미롭고 유용하지만 사용자가 이에 의존할 필요는 없습니다. FreeBSD의 거의 모든 것과 마찬가지로 기본값은 대부분의 교육에서 합리적이고 수용 가능합니다. 사례. 그러나 newfs를 시작할 때 -U 옵션은 기본적으로 활성화되지 않습니다. 이는 파일 작업 속도와 파일 시스템의 안정성을 높이는 데 도움이 되는(역설적이기는 하지만 사실) 소프트 업데이트 메커니즘이라는 매우 유용한 기능을 지원합니다.

그러나 소프트 업데이트라는 주제는 그 자체로 매우 흥미롭기 때문에 다음 섹션에서 별도로 논의할 가치가 있습니다. 그동안 FreeBSD 파일 시스템의 현재 버전인 UFS2와 이전 버전인 UFS 간의 차이점을 살펴보겠습니다.

FreeBSD 파일 시스템에 관해 위에서 언급한 모든 내용은 두 종류 모두에 동일하게 적용됩니다. UFS2의 주요 특징은 64비트이므로 1테라바이트 이상의 디스크 볼륨으로 작업할 수 있다는 것입니다(이것이 곧 데스크톱 사용자에게 관련이 될지 궁금합니다. 디스크 드라이브의 속도로 판단하면, 이 날짜가 멀지 않았습니다). 이와 관련하여 UFS2의 inode 테이블 항목 길이가 두 배로 늘어나 256바이트라는 점을 상기시켜 드리겠습니다.

또한 UFS2에는 확장된 파일 속성, 특히 ACL에 대한 지원이 포함되어 있습니다. 네트워크 관리자. 그러나 사용자가 알 수 있는 것은 새 파일 시스템 생성이 더 빠르다는 것입니다(대형 디스크 파티션에서는 이것이 감각적으로 눈에 띕니다). 이것은 소위 때문에 발생합니다. "게으른" 초기화 아이노드, 예를 들어 XFS와 같이 동적 할당은 없지만.

일반적으로 사용자 입장에서는 UFS와 UFS2의 차이가 눈에 띄지 않을 수도 있습니다. 그러나 UFS2를 포기할 이유도 없습니다. 게다가 위에서 언급한 newfs와 기본적으로 sysinstall은 이제(5번째 브랜치에서) 이것을 정확하게 생성합니다. UFS2를 지원하지 않는 이전 분기 버전과의 호환성을 위해 UFS를 생성하려는 경우 newfs에 -O 1 옵션을 지정하여 강제로 수행해야 합니다.

Paradox 소프트 업데이트

많은 장점에도 불구하고 FreBSD 파일 시스템은 속도라는 한 가지만을 자랑할 수 없습니다. 그리고 이는 일반적인 Berkeley FFS(빠른 파일 시스템)를 기반으로 한다는 사실에도 불구하고 그렇습니다. 그러나 여기서 별명은 이전 Unix 파일 시스템인 s5와 비교한 것입니다. 지식이 풍부한 사람들이 말했듯이 모든 변형은 탁월한 사려 깊음으로 구별됩니다. FreeBSD 파일 시스템의 성능을 기본 Linux Ext2fs와 비교하면 사용자는 특히 많은 수의 작은 파일을 사용하는 작업에서 후자보다 상당히 느린 것을 볼 수 있습니다.

왜? 대답하기 쉽습니다: 수정된 파일을 처리하기 위한 FreeBSD의 기본 모드 때문입니다. 대부분의 일반 파일 시스템은 다음 세 가지 모드 중 하나로 작동할 수 있습니다.

파일의 메타데이터와 데이터 영역 모두에 대한 업데이트가 변경 직후 디스크에 기록되는 경우 완전 동기식입니다.
파일에 대한 모든 변경 사항(메타데이터 및 데이터 영역 모두)이 완전히 비동기식으로 캐시됩니다. 랜덤 액세스 메모리그리고 실제로 적절한 시간에 디스크에 기록됩니다.
혼합되어 변경된 메타데이터에 대한 동기 메커니즘을 구현하고 데이터 영역 수정을 위한 캐싱을 구현합니다.

분명히 첫 번째 모드는 오류에 대한 파일 시스템의 가장 큰 저항을 제공하고 두 번째 모드는 가장 빠른 파일 작업 속도를 제공합니다(파일 시스템의 무결성을 위반할 가능성과 긴급 상황 발생 시 완전히 파괴될 수도 있음). 종료), 세 번째는 첫 번째 솔루션과 두 번째 솔루션 간의 일종의 절충안입니다.

따라서 Linux 파일 시스템(특히 ext2fs에서 Linux는 이제 많은 파일 시스템을 기본 파일 시스템으로 인식함)에서는 기본적으로 완전히 활성화되어 있습니다. 비동기 모드작동하지만 FreeBSD에서는 혼합되어 있습니다. 물론 이는 파일 시스템이 마운트될 때 결정되며, 마운트 명령에 대한 적절한 옵션(관련 게시물에서 보여드리겠습니다)을 사용하면 FreeBSD 파일 시스템이 완전히 비동기적으로 실행되도록 만들 수 있습니다. 그러나 합리적인 사람들은 이 작업을 절대적으로 권장하지 않으며 아마도 이에 대한 이유가 있을 것입니다(이유 중 하나는 이 섹션의 끝에서 명확해질 것입니다). 그리고 테스트 결과에 따르면 FreeBSD에서 파일 시스템을 비동기식으로 마운트해도 성능이 크게 향상되지 않습니다.

실제로 기본 모드에서 FreeBSD 파일 시스템은 (ext2fs와 비교하여) 놀라운 안정성을 보여줍니다. 이 OS를 다루는 수년 동안(그 중 절반은 예상치 못한 정전이 잦았던 시골 지역에서) 작업 세션이 비정상적으로 종료되어 문제에 직면한 적이 없습니다(Linux에서는 다음과 같은 문제가 있습니다). 저널링 파일 시스템을 구현하기 전에는 이러한 문제가 항상 발생했습니다.

그러나 이에 대한 대가는 속도입니다. 아니면 오히려 그것이 없다는 것입니다. 그리고 이것은 복사할 때 특히 분명합니다. 많은 분량작은 파일(주로 텍스트 자료로 작업할 때 매우 일반적인 절차). 실제로 이 경우 엄청난 수의 파일이 동기 모드에서 업데이트됩니다. 아이노드, 데이터 자체의 변화량은 볼륨 면에서 미미하며, 이를 캐싱하는 것은 거의 기쁨을 주지 않습니다. 어쨌든 입력한 내용을 복사하면 텍스트 에디터기사에서 이 노트의 크기와 표준 CD의 전체 볼륨은 상당히 민감한 시간이 걸립니다(이러한 작업이 겉보기에 즉시 수행되는 Linux와는 달리 - 또 다른 점은 활동 표시기가 하드 드라이브오랫동안 윙크할 수 있습니다.)

더욱이, 모든 실제 안정성에도 불구하고 저널링되지 않은 FreeBSD 파일 시스템 자체에는 자체 무결성을 보장하는 메커니즘이 없습니다. 즉, 소위 긴급 종료가 발생한 경우입니다. 클린 마운트 해제 비트(클린 바이트는 다음 중 하나입니다. 중요한 매개변수시스템이 올바르게 종료되면 슈퍼 블록에 기록되는 파일 시스템), 후속 부팅 절차 중에 메타데이터와 데이터 영역 간의 불일치를 찾아 제거하기 위해 프로그램이 강제로 호출됩니다. 최신 디스크 크기(및 이에 따른 파일 시스템)에서는 이러한 확인에 몇 시간이 걸릴 수 있습니다. 물론 이는 서버의 경우 특히 안타까운 일이지만 데스크톱 컴퓨터에서도 긍정적인 감정을 거의 불러일으키지 않습니다.

무결성 위반 문제는 Linux에도 존재합니다(위에서 언급한 이유 때문에 – 더 큰 범위까지). 그리고 Linux에서는 로깅, 즉 메타데이터(경우에 따라 데이터까지)의 변경 사항을 사전에 등록하여 이 문제에 맞서고 있습니다. FreeBSD에서는 파일 시스템의 무결성을 위한 투쟁이 역사적으로 두 가지 방향으로 진행되었습니다. 그 중 하나(역사적으로는 두 번째이지만)는 5번째 분기에 나타난 백그라운드 파일 시스템 무결성 검사로, 시작을 허용합니다. 정상 작동머신을 긴급 재부팅한 직후. 이것은 근본적인 혁신 중 하나이므로 이 주제에 대해 몇 마디 말씀 드리겠습니다.

FreeBSD에서 파일 시스템의 무결성을 확인하려면 fsck 유틸리티가 사용됩니다(Linux에는 동일한 이름의 유틸리티가 있습니다. ext2fs의 경우 다른 파일 시스템에 대한 유사한 도구가 있습니다). 사용자(또는 루트)가 시작할 수 있습니다. 명령줄. 그러나 시스템 시작 구성표는 자동으로 마운트된 파일 시스템 중 하나에서도 클린 마운트 해제 비트가 감지되지 않는 경우 강제 시작을 제공합니다. 그리고 fsck는 비트별 작업이므로 일반적으로 심각한 결과를 피하기 위해 마운트되지 않은 파일 시스템에서 수행됩니다.

이는 FreeBSD의 4번째 브랜치 버전까지의 경우였습니다. 그러나 5번째 버전에서는 처음부터 마운트되어 바로 사용할 수 있는 파일 시스템에서 디스크 검사를 수행할 수 있습니다. 그리고 그에 따라 배경시스템이 완전히 로드된 후 실행과 동시에 정규직. 사소해 보이지만 좋은 일입니다. 현재 일반적으로 사용되는 80GB 또는 120GB 나사를 완전히 검사하는 데 시간이 얼마나 걸릴지 말하기 어렵습니다.

그러나 파일 시스템의 무결성을 위해 싸울 방법을 구현한 최초의 방법은 동시에(또는 주로) 파일 작업 성능을 향상시키는 소프트 업데이트 메커니즘이었습니다.

소프트 업데이트 메커니즘 자체는 아래에 설명되어 있습니다. 간단히 말해서, 이 메커니즘의 핵심은 한편으로는 명시적인 비동기식 메타데이터 조작 없이 동기식 쓰기 작업을 최소화하는 것입니다. 또한 다른 한편으로는 메타데이터의 예비 저널링(ReiserFS 또는 XFS와 같은 파일 시스템에서와 같이) 없이도 동기식 쓰기 작업을 최소화하는 것입니다.

이는 소위 업데이트 종속성으로 인해 다시 대략적으로 구현됩니다(구현 세부 사항은 제가 이해할 수 없는 수준입니다. 고백합니다). 이러한 종속성이 무엇인지는 새(단순화를 위해 비어 있음) 파일을 생성하는 예에서 직관적으로 명확합니다. 이를 위해서는 다음이 필요합니다.

테이블 항목 아이노드, 파일 유형, 식별자, 링크 카운터(값 1 - 각 파일은 최소한 하나의 디렉터리에 속해야 함) 및 기타 항목 - 기본 마스크에 따른 액세스 권한 등의 필드를 채웁니다. ;
비어 있는/점유된 지도 변경 아이노드실린더 그룹 블록(새 파일에 해당) 아이노드바쁜 비트로 표시되어야 함);
새 파일이 생성되는 디렉터리 구조에 "identifier - file_name" 형식의 항목을 추가하면 해당 필드에 바로 단일 링크가 제공됩니다. 아이노드파일.

파일 시스템 무결성 관점에서 이러한 작업은 다음 순서로 수행되어야 합니다. 즉, 비어 있는(아직 생성되지 않았거나 이미 파괴된) 식별자를 가진 파일 이름이 디렉터리에 존재하는 것입니다. 아이노드- 명백한 장애: 세션이 비정상적으로 종료된 후 디스크 검사 프로그램이 실행되는 것은 이러한 분노를 바로잡기 위한 것입니다.

동기 모드에서 종속성 관련 업데이트 작업을 수행하는 데는 시간이 오래 걸립니다(각각 디스크에 대한 자체 액세스가 필요함). 비동기 모드에서는 시퀀스 유지가 보장되지 않습니다(신이 원할 때 캐시의 업데이트가 기록될 수 있음). 따라서 소프트 업데이트 메커니즘은 한편으로는 종속 업데이트의 실행 순서(파일 시스템 상태의 무결성에 기여)에 대한 제어를 제공하는 한편, 이를 동기식 단일 원자 작업으로 그룹화합니다. 디스크에 대한 액세스 수를 줄임으로써 생산성이 향상됩니다. 제가 이해하는 한 이것은 소프트 업데이트 역설, 즉 안정성과 성능 모두의 예상치 못한 증가에 대한 설명입니다.

일반적으로 저는 제가 이해한 대로 최선을 다해 설명하려고 노력했습니다. 자세한 내용은 언급된 기사를 참조하세요. 또한 오해를 피하기 위해 참고할 것입니다. 소프트 업데이트 메커니즘은 시스템 충돌 전 사용자의 부주의로 인해 디스크에 기록되지 않은 사용자 데이터의 안전을 보장할 뿐만 아니라 이를 추구하지도 않습니다. 그런 목표. 그의 임무는 파일 시스템이 항상 가능한 일관되게 표시되도록 하는 것입니다. 그러나 모든 저널 파일 시스템에 대해서도 마찬가지입니다. 그 중 어느 것도 사용자 오류를 보장하지 않습니다.

이제 소프트 업데이트를 어떻게 사용할 수 있는지 살펴보겠습니다. sysinstall을 통해 파일 시스템을 생성하면 모든 것이 간단합니다. 기본적으로 이 메커니즘을 활성화하는 것은 루트 시스템을 제외한 모든 파일 시스템에 대해 오랫동안 (약 4.3 버전) 제공되었습니다. 후자는 보안 고려 사항에 의해 정당화됩니다. 그리고 루트 파일 시스템의 경우 소프트 업데이트가 특별히 필요하지 않습니다. 적절한 디스크 파티셔닝과 적절한 작동을 통해 새 커널을 설치할 때만 쓰기(초기 설치 후)가 발생하지만 정상적인 조건에서는 이 작업이 얼마나 자주 수행됩니까?

newfs 명령을 사용하여 수동으로 파일 시스템을 생성할 때 소프트 업데이트는 자동으로 활성화되지 않습니다. 이미 언급한 대로 옵션을 지정하여 이를 수행해야 합니다.

$ newfs -U /dev/ad#s#?

그러나 포맷하는 동안 잊어버린 경우에는 괜찮습니다. 루트를 제외한 모든 파티션에 대해 tunefs 명령을 사용하여 소프트 업데이트를 쉽게 활성화할 수 있습니다. 이렇게 하려면 단일 사용자 모드로 전환해야 합니다(강력히 권장됩니다. 어떻게든 그것 없이도 관리했지만 합리적인 사람들의 조언을 따르는 것이 더 낫습니다). 이는 명령에 의해 수행됩니다.

$ 지금 종료

다음 명령을 사용하여 루트(이 번호는 작동하지 않음)를 제외한 모든 파일 시스템을 마운트 해제합니다.

$umount -Af

명령을 내리다

$ tunefs -n 활성화 /dev/ad#s#?

소프트 업데이트가 필요한 파일 시스템의 각 파티션에 대해. 그리고 마지막으로 명령을 반복합니다.

나는 간단한 질문이 인터넷에서 잘 다루어지지 않는 경우가 많다는 사실에 종종 주목합니다. 이것은 아마도 모든 전문가가 누구도 그런 어리석은 질문을 하지 않을 것이라고 확신하기 때문일 것입니다. 왜냐하면 모두가 이것을 알고 있기 때문입니다. 그러나 내 경험에 따르면 초보자뿐만 아니라 이를 처리할 필요가 없는 진지한 관리자들 사이에서도 가장 흔한 것은 이러한 작고 간단한 질문이라는 것이 밝혀졌습니다. 진지한 관리자조차도 매일이 작업을 수행하지는 않지만 잊지 않기 위해 누구에게도 인정하지 않고 일종의 치트 시트를 보관합니다. 모든 것을 고치자. 이제 5분 안에 FreeBSD에 하드 드라이브를 추가하는 방법을 배우게 됩니다. 그래서. 먼저 번역하겠습니다 완전한 지침과정을 이해하고 마지막에는 짧은 작업 목록, 여기에는 치트 시트로 명령 목록만 포함됩니다.

설명이 포함된 자세한 지침

하드 드라이브 이름 선택

먼저 방금 추가한 장치의 이름을 결정해야 합니다. 다음 명령이 도움이 될 것입니다.

검 디스크 목록

또는 다음 명령을 사용하세요.

Camcontrol 개발 목록

실제 시스템에서 이 명령은 더 많은 정보를 표시합니다. 유용한 정보, 즉 장치 이름 및 일련번호입니다.

새 장치를 설치하기 전에 우리는 시스템이 ada0에 설치되어 있다는 것을 알았습니다. 이는 논리적으로 새 드라이브가 ada1임을 의미합니다. 새 장치의 이름, 일련 번호 또는 볼륨으로 이를 확인할 수 있습니다.

이제 새 디스크에 표시가 있는지 확인해 보겠습니다.

Gpart 쇼 ada1

디스크에는 표시가 없습니다.

기존 마크업 제거

디스크가 이미 사용되었고 표시를 제거해야 하는 경우 다음을 실행하면 됩니다.

Gpart 파괴 -F ada1

GPT 마크업 만들기

먼저 디스크 파티션을 생성해야 합니다. MBR을 잊어버리고 새롭고 더 편리하며 기능적인 GPT로 전환하는 것이 좋습니다.

우리는 창조한다 GPT 마크업디스크에서 무슨 일이 일어났는지 확인하세요.

Gpart create -s gpt /dev/ada1 gpart show ada1

이제 디스크에 GPT 마크업이 있습니다. 출력에서 LBA 34부터 시작하여 LBA 8388541로 끝나는 전체 디스크가 완전히 비어 있음을 알 수 있습니다. LBA 0−33 - 파티션 테이블용으로 시스템에 예약되어 있습니다.

이 디스크에 두 개의 파티션을 생성해야 한다고 가정해 보겠습니다.

교환- 파티션 교체
데이터- 필요한 데이터를 저장하기 위한 ufs 유형의 섹션입니다.

섹션(슬라이스) 생성

현대식으로 설치하는 경우 하드 디스크, 섹터 크기 = 4KB인 경우 파티션(파티션)을 생성할 때 정렬을 사용해야 합니다. 이 작업은 두 가지 방법으로 수행할 수 있습니다. 1) 섹션 매개변수를 블록으로 지정하는 경우 블록 번호를 8의 배수로 입력합니다. 예: -b 40; 2) 파티션 크기를 바이트 단위로 표시하거나 시작 및 크기를 전혀 표시하지 않는 경우 매개 변수를 사용하십시오. -4K, 섹션의 시작과 끝을 4kb 크기의 섹터로 조정합니다. 우리는 이 예에서는우리는 테스트 설치를합니다 가상 하드디스크라면 이 작업을 수행할 필요가 없습니다. 어떤 경우든 파티션을 생성하기 전에 드라이브의 섹터 크기를 정확히 알아야 합니다. 그렇지 않으면 작업 속도가 크게 느려질 수 있습니다.

이제 파티션을 만들어 보겠습니다. 이를 위해 다양한 매개변수를 사용하는 gpart add 명령이 있습니다. 첫 번째 매개변수 -티- 생성되는 파일 시스템의 유형을 나타냅니다. 우리의 경우 freebsd-swap과 freebsd-ufs의 두 가지 유형이 사용됩니다. 다음은 2개 선택적 매개변수: -비- 파티션을 생성해야 하는 LBA 번호를 나타냅니다. 이 매개변수를 지정하지 않으면 첫 번째 여유 LBA에서 파티션이 자동으로 생성됩니다. -에스- LBA의 파티션 크기를 나타냅니다. 하나의 LBA 블록 크기 = 512바이트. LBA 블록 수로 표시하는 것이 좋지만 킬로/메가/기가/…바이트(접미사 k/M/G)로도 표시할 수 있습니다. 이 매개변수를 지정하지 않으면 빈 영역 내에서 가능한 최대 LBA까지 파티션이 생성됩니다. 섹션 레이블을 매개변수로 지정할 수도 있습니다. 예를 들면 다음과 같습니다. -l 스왑1- 이 경우 파티션에 보다 편리하게 액세스하는 데 사용할 수 있는 /dev/gpt/swap1 레이블이 생성됩니다. 마지막 필수 매개변수는 디스크 경로입니다. 우리의 경우: /dev/ada1.

두 개의 파티션을 만든 다음 무엇이 있는지 살펴보겠습니다. 초기 LBA를 지정하지 않고 크기를 1GB(2097152블록)로 지정하여 첫 번째 파티션을 생성하겠습니다. 초기 LBA를 지정하지 않고 크기를 지정하지 않고 두 번째 파티션을 생성하므로 전체 여유 공간에 생성됩니다.

Gpart add -t freebsd-swap -s 2097152 /dev/ada1 gpart add -t freebsd-ufs /dev/ada1 gpart show ada1

크기는 블록이 아닌 바이트 단위로 지정할 수 있습니다. 훨씬 더 편리합니다. 유일한 단점은 시스템이 항상 블록 수를 정확하게 계산할 수 없다는 것입니다. 파티션 크기를 바이트 단위로 지정할 때 특정 수의 블록이 디스크에 비어 있는 경우가 있을 수 있습니다.

파일 시스템 생성(포맷)

스왑 파티션을 포맷할 필요가 없습니다. 하지만 ufs와 같은 파티션은 사용하기 전에 포맷해야 합니다. 말하는 것이 더 정확할 것입니다. 파일 시스템이 생성되어야합니다.

두 번째 파티션에 파일 시스템을 생성하려면 다음 명령을 실행하세요.

Newfs -U /dev/ada1p2

안에 이 경우-U 매개변수가 사용되었습니다. 이는 이 파일 시스템에서 소프트 업데이트 메커니즘을 사용해야 함을 나타냅니다. 이 메커니즘을 활성화하지 않으려면 이 옵션을 생략할 수 있습니다.

설치

다음 단계는 파티션을 마운트하는 것입니다. 먼저, 잊지 않도록 /etc/fstab에 새 섹션을 추가해 보겠습니다. 편집 후 내 파일은 다음과 같습니다.

/etc/fstab 파일에 따라 모든 파티션을 다시 마운트하려면 다음 명령을 실행하면 됩니다.

마운트 -a

출력에서 볼 수 있듯이 /dev/ada1p2 파티션이 마운트되었습니다. 이제 SWAP 섹션에 무슨 일이 일어났는지 살펴보겠습니다. 다음 명령을 실행해 보겠습니다.

본 것처럼, 새 섹션 SWAP이 마운트되지 않았습니다. SWAP을 마운트하려면 특수 명령을 사용하여 활성화해야 합니다.

/dev/ada1p1 교환

마찬가지로, swapoff 명령을 사용하면 SWAP 파티션에 대한 작업을 수행하기 전에 해당 파티션을 비활성화해야 합니다.

추가하는 것이 전부입니다 새로운 하드시스템에 디스크가 완료되었습니다.

간단한 지침

주어진: 하드 드라이브 /dev/ada1

표적: 기존 파티션을 삭제하고, 새 GPT 파티션을 생성하고, 스왑과 데이터라는 두 개의 파티션을 생성하여 작업 시스템에 연결합니다.

각 작업 후에는 다음을 수행합니다. gpart 쇼결과를 관찰하기 위해. 시퀀싱:

기존 파티션 제거: gpart destroy -F ada1
새 파티션 생성: gpart create -s gpt /dev/ada1
두 개의 파티션 생성: 스왑 및 데이터: gpart add -t freebsd-swap -s 2097152 /dev/ada1 gpart add -t freebsd-ufs /dev/ada1
파일 시스템 생성 UFSv2두 번째 파티션: newfs -U /dev/ada1p2
부팅 시 자동 마운트를 위해 /etc/fstab 파일에 줄을 추가합니다: /dev/ada1p1 none swap sw 0 0 /dev/ada1p2 /mnt ufs rw 2 2
새 파티션을 마운트합니다(이 명령은 /etc/fstab 파일의 모든 파티션을 마운트합니다): mount -a
다음 명령을 사용하여 새 스왑 파티션을 활성화합니다: swapon /dev/ada1p1

이것으로 설정이 완료됩니다.

사용할 디스크 공간을 준비하는 것은 파티션과 파일 시스템을 생성하는 것으로 끝나지 않습니다. 생성된 모든 파일 시스템은 FreeBSD에서도 사용할 수 있어야 합니다. 마운트해야 하는 이유는 무엇입니까? 즉, 파일 시스템 이름으로도 지정되는 디렉터리 및 파일의 단일 계층에 포함됩니다. 그러나 이전에 데이터의 물리적 구성에 대해 이야기했다면 이제 해당 논리에 대해 알아볼 차례입니다.

파일 시스템 로직

논리적으로 FreeBSD 파일 시스템(모든 Unix 시스템과 마찬가지로)은 트리 원칙에 따라 구성됩니다. 기본에는 루트(기호 /로 표시되고 루트 디렉터리라고도 불리는 루트 디렉터리)가 있습니다. 후자를 혼동해서는 안 됩니다. 슈퍼유저의 홈 디렉토리 역할을 하는 / 루트 디렉토리).

나무 줄기와 비슷할 수 있는 루트 디렉터리에는 분기(그 안에 중첩된 하위 디렉터리와 일반 파일)가 있습니다. 그러나 후자는 거의 없습니다. FreeBSD 버전에서 이것은 특정 엔트로피 파일(/entropy)과 시스템 저작권을 설명하는 파일 /COPYRIGHT입니다.

그러나 루트 디렉터리에는 상당히 많은 하위 디렉터리가 있으며 그 중 일부는 더 깊은 수준의 상당히 많은 수의 중첩된 하위 디렉터리를 포함하여 내부에 매우 복잡하게 배열되어 있습니다.

원칙적으로 모든 Unix 시스템의 디렉토리 계층 구조는 첫째로 오랜 전통에 따라 규제되고 둘째로 모든 종류의 표준화 문서, 특히 현재 FHS(Filesystem Hierarchy Standard)에 의해 규제되기 때문에 유사합니다. 러시아어 번역이 가능합니다(Viktor Kostromin에게 감사드립니다).

FHS 표준은 원래 수많은 Linux 배포판의 디렉토리 구조를 구성하기 위해 개발되었습니다. 그리고 나중에야 다른 Unix 계열 시스템(BSD 클랜 포함)에도 적용되었습니다. 그러나 FHS의 정신을 모범적으로 고수하는 예가 될 수 있는 것은 FreeBSD 디렉토리 계층 구조입니다. 그리고 글자 그대로의 개별 편차는 항상 기능적으로 결정됩니다.

FHS 표준은 두 가지 기본 원칙, 즉 공유 디렉터리와 비공유 디렉터리의 파일 계층 구조를 명확하게 분리하고, 다른 한편으로는 불변 및 변경 가능을 기반으로 합니다.

공유 디렉토리와 비공유 디렉토리 사이의 대조는 일반적으로 Unix와 특히 FreeBSD의 고유한 네트워크 특성 때문입니다. 즉, 로컬 시스템과 관련된 데이터(예: 해당 장치의 구성 파일)는 네트워크의 다른 시스템, 로컬 또는 글로벌에서 액세스할 수 있는 내용과 별도의 디렉토리에 있어야 합니다(예: 사용자뿐만 아니라 데이터뿐만 아니라 프로그램도 포함).

불변 디렉토리와 가변 디렉토리의 대조의 본질은 예를 들어 쉽게 설명할 수 있습니다. 따라서 동일한 사용자 프로그램은 본질적으로 변경할 수 없어야 합니다(또는 시스템 관리자만 수정할 수 있고 작업에 사용하는 사용자 자신은 수정할 수 없음). 동시에 이러한 프로그램은 작동 중에 텍스트나 이미지와 같은 데이터 파일(해당 변수의 성격은 주석 없이 명확함)뿐만 아니라 로그 파일, 임시 파일 및 로그 파일과 같은 모든 종류의 서비스 정보를 생성합니다. 좋다). 실행에 필요한 프로그램, 라이브러리, 구성 파일 등의 실제 실행 파일과 분리된 디렉터리로 그룹화되어야 합니다.

공유 및 비공유, 불변 및 불변 디렉토리를 서로 분리하는 개념을 엄격히 준수하면 단일 트리형 파일 계층 내에서 개별 분기를 물리적으로 격리할 수 있습니다. 즉, 다음 위치에 있는 독립 파일 시스템의 형태로 가능합니다. 격리된 장치(디스크, 디스크 슬라이스, 파티션, V 일반적인 경우-원격 네트워크 연결 미디어에 있지만 지금은 논의하지 않습니다). 여기에는 속도 향상, 신뢰성 향상, 단순히 편의성 고려 등 여러 가지 이유가 있지만 지금은 이에 대해 이야기하지 않겠습니다. 이제 우리에게 중요한 것은 파일 트리의 이러한 분기가 전체 파일 시스템에 통합되어야 한다는 것입니다.

Unix 시스템에서 모든 파일(디렉토리 포함)은 이름이 아니라 테이블 항목의 고유 식별자로 시스템에서 인식됩니다. 아이노드. 이러한 파일 ID를 볼 수 있는 도구가 있습니다. 하나는 -i 옵션이 포함된 ls 명령으로, 명명된 각 파일의 ID를 인쇄합니다. 루트 디렉토리에 대해 제공됨 -

$ ls -i /

이는 우리에게 다소 예상치 못한 그림을 보여줄 것입니다(단순화를 위해 일반 파일및 루트의 심볼릭 링크, 나머지 디렉토리는 ID별로 정렬됩니다.

2 ../ 2 ./ 2 dev/ 2 home/ 2 tmp/ 2 usr/ 2 var/ 3 cdrom/ 4 mnt/ 5 root/ 8257 dist/ 8258 bin/ 8294 proc/ 8295 sbin/ 16512 스탠드/ 24768 etc/ 24776 신병/

이 예(이 줄이 기록되는 시스템의 파일 시스템과 관련)에서 최대 7개의 디렉터리가 동일한 디지털 식별자(2개)를 갖고 있음이 분명합니다. 문제는 여기서 고유성이 무엇입니까?

목록의 처음 두 요소는 이해하기 쉽습니다. ./는 현재 디렉터리(이 경우 루트)를 나타내고 ../는 현재 디렉터리의 상위 디렉터리입니다. 정의에 따라 파일 계층 구조의 루트 위에는 아무것도 없기 때문에 후자는 그 자체를 나타냅니다. 따라서 ./와 ../가 동일한 식별자를 갖는다는 것은 놀라운 일이 아닙니다. 이는 동일한 루트, 디렉터리에 대해 서로 다른 지정(하드 링크, 즉 중복 이름)입니다.

그러나 언뜻 보면 /dev, /home, /tmp, /usr, /var 디렉토리에 대한 식별자의 의미에 대해서도 설명이 필요합니다. 그러나 이는 간단합니다. 이들 모두는 독립 파일 시스템이 마운트되는 디렉토리이며, 별도의 장치(/home, /usr, /var 디렉토리와 같은 디스크 파티션 또는 구축되지 않은 가상 파일 시스템)에 위치합니다. 실제 디스크 장치(장치 파일 시스템이 있는 /dev 디렉토리, 이 경우 RAM의 파일 시스템이 마운트되는 /tmp 디렉토리, 이에 대해서는 나중에 설명함). 그리고 테이블부터 아이노드- 파일 시스템마다 다르기 때문에 각 파일 시스템의 루트가 숫자 2로 식별되는 것은 놀라운 일이 아닙니다. 아이노드그 안에 들어가요 자체 시스템카운트다운.

따라서 마운트는 루트 시스템에 존재하는 모든 디렉터리에 시스템의 파일을 포함하는 것입니다(반드시 루트에 직접적으로 존재할 필요는 없으며 아래 그림과 같이 어느 정도 중첩될 수 있습니다). 이것이 없으면 마운트된 시스템의 디렉토리와 파일에 액세스할 수 없습니다. "/usr 파일 시스템 생성"과 같은 표현을 접할 때 이를 이해하는 것이 중요합니다. 위에서 보면 (newfs 명령에 의해) 생성되는 것은 일종의 추상 파일 시스템일 뿐이며 지정된 디렉터리에 마운트할 때만 "이름"을 얻음이 분명합니다.

마운트할 디렉터리 식별자(마운트 지점이라고도 함)는 마운트할 때만 발견된다는 점이 흥미롭습니다. 이를 검증하기 위해 간단한 실험을 해보겠습니다. 임시로 마운트된 파일 시스템을 마운트하기 위해 특별히 고안된 /mnt 디렉터리에서 세 개의 하위 디렉터리인 /mnt/disk, mnt/iso, /mnt/usb를 볼 수 있습니다(이것은 내 시스템에 있으며 내 편의를 위해 만들었습니다. 처음에는 FreeBSD에 있던 /mnt 디렉토리가 비어 있습니다. 시스템이 시작되면 아무것도 마운트되지 않으며 일반적인 상태는 비어 있습니다. 식별자를 살펴보면 다음과 같은 내용을 볼 수 있습니다.

$ ls -i /mnt 18 디스크/ 24 ISO/ 19 USB/

이제 USB 인터페이스가 있는 플래시 드라이브를 /mnt/usb(정확히 제가 의도한 것임)에 마운트하고 보기를 반복해 보겠습니다. 그리고 우리는 다음을 봅니다:

디스크 18개/ iso 24개/ usb 2개/

즉, 비어 있던 디렉터리(/mnt/disk 및 /mnt/iso)의 식별자는 변경되지 않았지만 디렉터리 식별자 /mnt/usb는 마술처럼 2로 변경되었습니다. 마운트하는 순간 디렉터리 식별자가 의 루트가 되었기 때문입니다. 자체 파일 시스템 및 미적분학의 기준점 아이노드그것에 기록된 모든 파일.

조금 벗어나서 하드 링크에 대해 기억해 봅시다. 아이노드이와 관련된 데이터 블록에는 다른 이름이 지정될 수 있습니다. 이제 그러한 모든 중복 파일이 동일한 파일 시스템에 있어야 하는 이유가 분명해졌습니다. 결국 서로 다른 파일 시스템에는 일치하지 않는 고유한 번호가 지정되어 있기 때문입니다. 아이노드, 숫자로 식별하는 것은 불가능합니다(그렇지 않으면 시스템이 우리 예에서 /usr 및 /var 디렉토리를 어떻게 구별합니까? 결국 파일 이름은 신경 쓰지 않습니다). 자체적인 심볼릭 링크의 경우 아이노드(사실 그 외에는 거의 없음) 해당 식별자가 위치한 파일 시스템의 참조 프레임에 번호가 매겨져 있으면 그러한 제한이 없습니다. 그리고 심볼릭 링크는 어디든 위치할 수 있습니다(다른 파티션뿐만 아니라 원격 시스템도 포함).

그러나 루트 디렉터리의 예로 돌아가 보겠습니다. 고려한 모든 것에서 많은 분기가 별도의 파티션에 있고 자체 파일 시스템을 형성한다는 것이 분명합니다(사실 이것이 바로 우리가 두 가지를 모두 만든 이유입니다). 따라서 모두 마운트해야 합니다.

장착 실습

마운트 목적은 시스템 부팅 중에 자동으로 실행되거나 명령줄에서 수동으로 실행되는 mount 명령에 의해 제공됩니다. 실제로는 어떤 경우에도 루트 파일 시스템만 자동으로 마운트됩니다. 디스크에 있을 필요는 없습니다. 복구 CD나 기타 안전 미디어에서 시작할 때 디스크에 위치할 수 있습니다. 가상 디스크 RAM에.

그러나 루트 파일 시스템을 마운트하는 과정은 세계적인 규모의 사회주의의 승리만큼이나 불가피합니다. 사회주의가 세계적인 규모에서 승리하지 못하면 단순히 존재 능력을 상실하는 것처럼(최근 관찰한 바 있음) OS는 루트 시스템 없이 존재할 수 없습니다. Linux에서는 이로 인해 커널 패닉 모드가 발생합니다. 이는 대략 우리 리더들이 약 20년 전에 빠졌던 상태입니다. 사실, 그들은 Linux보다 강력하다는 것이 밝혀졌고 매우 빠르게 복구되었습니다. 그래서 그들은 여전히 우리를 재부팅하고 있습니다 (또는 재부팅합니까? – 그러나 우리는 점점 더 강해지고 있습니다 :)). 그러나 이것은 제가 지금 여러분에게 제시하려는 설치 문제에는 적용되지 않습니다.

따라서 루트 파일 시스템을 제외한 모든 파일 시스템을 마운트하려면 몇 가지 단계를 수행해야 합니다. 먼저 이를 수동으로 수행하는 방법을 살펴본 다음 적절한 구성 파일에서 이를 영구화하는 방법을 살펴보겠습니다.

그래서, 마운트 명령. 실제로 이것은 전체 프로그램 제품군으로, 각 프로그램은 UFS뿐만 아니라 FreeBSD에서 지원하는 모든 유형의 파일 시스템을 마운트하도록 설계되었습니다. 이들 목록은 매우 광범위합니다. /sbin 디렉토리를 보면 이에 대한 아이디어를 얻을 수 있습니다.

$ ls -1 /sbin/마운트*

우리에게 응답으로 무엇을 줄 것인가?

/sbin/mount_cd9660* /sbin/mount_devfs* /sbin/mount_ext2fs* /sbin/mount_fdescfs* /sbin/mount_linprocfs* /sbin/mount_mfs* /sbin/mount_msdosfs* /sbin/mount_nfs* /sbin/mount_nfs4* /sbin/mount_ntfs* /sbin/mount_nullfs* /sbin/mount_procfs* /sbin/mount_std* /sbin/mount_udf* /sbin/mount_umapfs* /sbin/mount_unionfs*

이 목록의 각 명령은 다른 유형의 파일 시스템을 마운트하는 역할을 하며, 그 중 일부는 나중에 다시 설명하겠습니다. 지금은 UFS 및 UFS2와 함께 작동하도록 설계된 /sbin/mount 자체만 기록해 두겠습니다.

명령줄에서 호출하려면 마운트할 장치 이름과 마운트 지점(즉, 기본 파일 시스템을 마운트해야 하는 디렉터리)이라는 두 가지 인수가 필요합니다. 장치 이름은 UFS(UFS2 파일 시스템)가 생성된 기존 BSD 슬라이스에 이미 매핑된 패트리샤를 나타내야 합니다. 예를 들어 다음과 같습니다.

$ 마운트 /dev/ads0d /usr

파일 트리 루트의 /usr 디렉토리에 있는 지정된 파티션에 파일 시스템을 마운트합니다. 장치의 파일 시스템이 생성되지 않았거나 UFS/UFS2 이외의 유형인 경우 잘못된 슈퍼 블록을 나타내는 오류 메시지가 나타납니다. 동일한 이름의 Linux 유틸리티와 달리 FreeBSD 마운트 명령 자체는 파일을 인식할 수 없습니다. 시스템 유형.

마운트 지점에는 다음 요구 사항이 적용됩니다. a) 마운트 시 동일한 이름의 디렉터리가 있어야 하며 b) 가능한 한 비어 있어야 합니다. 첫 번째는 필수이지만 두 번째는 전적으로 사실이 아닙니다. 모든 파일이 포함된 디렉터리에 마운트하는 것은 원활하게 진행되지만(얼마 전에 Linux에서 이로 인해 시스템 충돌이 발생했다는 것을 기억합니다) 마운트 해제할 때까지 모든 내용에 액세스할 수 없게 됩니다. 그리고 여기에 포함된 파일이 하위 시스템에서 중요한 역할을 한다면 온갖 종류의 나쁜 결과를 초래할 수 있습니다. 예를 들어, X 윈도우 시스템이 실행되는 동안 /tmp 디렉토리의 내용이 파일 시스템을 마운트하여 차단된 경우 그 결과 X 서버가 충돌할 가능성이 높습니다. 다행히 필요한 경우 결합 마운트를 수행할 수 있습니다(아래 참조).

이 형식에서는 일부 기본 특성을 사용하여 마운트가 수행됩니다. 즉, 파일 시스템은 소위 모드에서 읽기/쓰기가 됩니다. noasync(메타데이터 작업이 동기적으로 수행되고 데이터 작업이 비동기적으로 수행되는 것과 동일) 이 위치는 -o 옵션의 값을 사용하여 변경할 수 있습니다. 꽤 많이 있지만 실제로 주요한 것들은 다음과 같습니다. 이 단계에서우리에게는 다음이 있을 것입니다:

async - 완전한 비동기 모드를 제공합니다(이전 게시물의 무서운 경고에도 불구하고 이것이 정당화될 수 있는 상황에 대해서는 나중에 이야기하겠습니다).
sync - 반대로 완전 동기 모드를 활성화합니다(실제로 이것이 왜 필요한지는 잘 모르겠습니다).
noatime은 파일의 마지막 액세스 시간 속성이 업데이트되는 것을 방지하여 성능을 크게 향상시키는 매우 유용한 옵션입니다.
rdonly - 파일 시스템을 읽기 전용 모드로 마운트합니다(때로는 이것이 필요함).
Union은 마운트 지점 디렉터리의 이전 내용이 계속 표시되는 통합 마운트를 수행할 수 있는 옵션과 동일합니다. true - 일부 제한 사항이 있음 - man(8) mount 를 참조하세요.

특정 유형의 파일(예: 실행 파일(-o noexec), 장치 파일(-o nodev) 또는 이를 포함하는 파일)이 마운트된 파일 시스템에 배치되는 것을 금지하는 -o 옵션의 다른 여러 값이 있습니다. -라고 불리는. 약간의 자살. 그러나 이는 주로 서버 관리자에게 실질적으로 중요하며 보안 목적으로 사용됩니다. 데스크톱 컴퓨터에서 일반적인 마운트 형식은 다음과 같습니다.

$ 마운트 -o noatime /dev/ads0d /usr; $ 마운트 -o noatime /dev/ads0e /var; $ 마운트 -o noatime /dev/ads0f /home

위의 모든 사항은 파일 마운트에만 적용됩니다. FreeBSD 시스템. 그러나 실제로는 다른 유형의 파일 시스템을 해당 디렉토리 트리에 통합해야 하는 경우가 많습니다. 이는 특히 ISO9660(Mac CD를 제외한 모든 CD의 일반적인 파일 시스템) 및 다양한 종류의 FAT에 필요합니다. 이 경우 적절한 마운트 명령을 명시적으로 호출해야 합니다.

$ mount_cd9660 /dev/acd0 /cdrom

콤팩트 장착용 또는

$ mount_msdosfs /dev/ad## /mnt

모든 종류의 FAT(FAT32 포함)에 대해 그러나 이는 mount 명령에 -t file_system_type 옵션을 지정하여 간접적으로 수행할 수도 있습니다.

$ 마운트 -t ext2fs /dev/ad## /mnt/linux

파일 마운트 리눅스 시스템(해당 기능이 커널에 포함되어 있는 경우) 이 경우 BSD 파티션의 표준 마운트는 ext2fs 파티션(ext3fs도 마찬가지지만 저널링 기능은 없음)을 마운트하도록 설계된 /mount_ext2fs 명령으로 간단히 대체됩니다. 즉, 형태는

$ 마운트 -t fstype ... ...

명령과 완전히 동일합니다

$mount_fstype ... ...

FreeBSD에서 파일 시스템(이동식 미디어 포함)을 마운트하기 위한 모든 작업에는 수퍼유저 권한이 필요합니다. 여기서 -o 옵션의 값은 Linux 버전의 mount 명령과 달리 일반 사용자에게 마운트를 허용하는 -o user 매개변수를 포함하지 않습니다. 사실, 특별 참고 사항에서 논의한 것처럼 이 문제를 해결하는 방법에는 여러 가지가 있습니다.

자동 마운트 설정

그러나 실제로는 거의 사용되지 않는 파일 시스템에 대해서만 수동 마운트가 사용됩니다. FreeBSD의 기능에 근본적으로 중요한 모든 파일 시스템은 시스템 시작 시 자동으로 마운트되며, 자주 사용되는 파일 시스템은 말하자면 반자동 모드로 마운트됩니다.

을 위한 자동 장착마운트 프로그램이 프로세스에서 시작됩니다 부트스트랩초기화 스크립트에서. 구성 파일인 /etc/fstab을 찾고 몇 가지 예외를 제외하고(아래에서 설명) 발견한 모든 것을 마운트합니다.

/etc/fstab 파일 자체는 FreeBSD가 설치될 때 생명을 지원하는 데 필요한 모든 파일 시스템을 포함하여 자동으로 생성됩니다. 그러나 나중에 장착할 새 장치를 추가하거나 이미 활성화된 장치에 대한 추가 옵션을 추가하기 위해 수동으로 편집할 수 있습니다.

/etc/fstab 파일은 다음의 간단한 데이터베이스입니다. 텍스트 형식(공백이나 탭으로 구분된 필드), 다음 필드 포함:

장치 - 파일 시스템이 위치한 장치의 파일 이름으로, 수동으로 사용될 때 mount 명령의 첫 번째 인수와 유사합니다.
Mountpoint - 마운트 지점(mount 명령의 두 번째 인수에 해당)
FStype - 파일 시스템 유형이며 -t 옵션의 값으로도 지정됩니다.
옵션 - 추가 옵션-o 옵션의 값과 유사하게 마운트합니다.
덤프 - 실행 조건 예약 사본파일 시스템 유틸리티 덤프 유틸리티;
Pass# - fsck 유틸리티를 사용하여 파일 시스템을 확인하기 위한 조건입니다.

새로 설치된 FreeBSD에서 /etc/fstab에는 반드시 다음 항목이 포함됩니다(첫 번째 IDE 채널에 있는 마스터 디스크의 첫 번째 슬라이스에 대한 예):

# 장치 마운트 지점 FStype 옵션 덤프 패스# /dev/ad0s1a / ufs rw 1 1 /dev/ad0s1b 없음 스왑 sw 0 0

합리적인 사람들의 조언(및 sysinstall의 기본값)을 따르고 루트에서 파일 시스템의 일부 분기를 선택하면 다음과 같은 항목이 표시됩니다.

/dev/ad0s1d /var ufs rw 0 0 /dev/ad0s1e /usr ufs rw 0 0 /dev/ad0s1f /tmp ufs rw 0 0

/dev/ad0s1g /home ufs rw 0 0

사용자 홈 디렉토리가 있는 파일 시스템을 담당합니다.

분명히 옵션 필드에서 -o 옵션의 사용 가능한(그리고 합리적인) 값(공백 없이 쉼표로 구분)을 추가할 수 있습니다. 예를 들어 모든 파일 시스템의 경우 noatime, /tmp의 경우 - async도 가능합니다. 이 디렉터리의 내용은 재부팅 후에 저장되지 않습니다.

위 내용은 시작 시 자동으로 마운트되는 파일 시스템에 적용됩니다. 그러나 때때로 연결되는 시스템에 대해 /etc/fstab에 항목을 작성하도록 귀찮게 하는 사람은 없습니다. 이 경우 시스템은 단순화된 구성표에 따라 마운트될 수 있습니다(위에서 의미한 바는 다음과 같습니다). 반자동 모드). 따라서 CD 드라이브의 경우 한 줄을 추가할 수 있습니다. (실제로 sysinstall에서 설치 소스로 CD를 선택한 경우 /etc/fstab 파일을 생성할 때 자동으로 나타납니다.)

/dev/acd0 /cdrom cd9660 ro,noauto 0 0

짐작할 수 있듯이 옵션은 시작 시 마운트 거부(noauto) 및 읽기 전용 모드(ro)를 규정합니다. 그런 다음 CD를 마운트하려면 마운트 지점만 지정하면 충분합니다.

$마운트/cdrom

또는. 반대로 장치 파일 이름은

$ 마운트 /dev/acd0

모든 이동식 드라이브(Zip, USB 드라이브, 플로피 디스크까지)와 BSD가 아닌 파티션(FAT 또는 Ext2fs)에 대해서도 유사한 항목을 만들 수 있습니다. 그런데 /etc/fstab을 변경한 후 시스템이 재부팅될 때까지 기다리지 않고 즉시 단순화된 구성표를 사용하여 파일 시스템을 마운트할 수 있습니다.

마운트 해제

전원을 끄거나 머신을 재부팅하기 전에 관련된 모든 파일 시스템을 마운트 해제해야 합니다. 정상적으로 종료되면 이 작업이 자동으로 수행되어 쓰기 가능한 각 파일 시스템이 자체 슈퍼블록에 기록된 깨끗한 마운트 해제 비트를 수신하게 됩니다. 이 비트가 있으면 fsck 유틸리티가 다음에 시스템을 시작할 때 파일 시스템의 일관성을 검사할 수 없습니다.

그러나 많은 경우(예: 소프트 업데이트 메커니즘을 연결 또는 연결 해제하거나 무결성 검사를 수행하는 경우) umount 명령이 사용되는 파일 시스템을 수동으로 마운트 해제(및 다시 마운트)해야 합니다. 여기에는 디렉터리 트리에서 "제거된" 파일 시스템의 마운트 지점을 지정하는 단일 인수가 필요합니다. 예:

$umount/tmp

또는 반자동 마운트의 경우 "종료" 장치의 파일 이름:

$ umount /dev/ad#s#?

한 줄로 여러 파일 시스템을 마운트 해제할 수 있습니다.

$ umount /usr /var /home

또는 마운트된 모든 파일 시스템 또는 /etc/fstab 파일에 나열된 모든 파일 시스템(루트 제외)을 수행할 수 있습니다. 여기에는 옵션이 필요합니다.

$umount -A

$umount -a

각기. -t 옵션의 값을 지정하여 특정 유형의 파일 시스템을 마운트 해제하는 것도 가능합니다. 응, 팀

$ umount -t ufs

CD 및 시스템과 관련된 모든 것에 영향을 주지 않고 BSD 파티션만 마운트 해제합니다.

마운트 해제 시 파일 시스템을 사용해서는 안 됩니다. 즉, 파일 시스템에 있는 파일에 액세스할 수 없어야 합니다. 따라서 파일 시스템의 디렉토리에 있다는 것은 마운트 해제를 거부할 충분한 이유가 되며(device busy와 같은 메시지와 함께) 위에 나열된 명령 중 어느 것도 루트 파일 시스템을 마운트 해제할 수 없는 이유입니다. 마운트 해제를 거부하는 이유는 모든 프로그램에서 데이터 파일을 읽기 때문입니다. 파일 삭제와 마찬가지로 모든 프로세스에서 열린 파일 설명자는 이를 허용하지 않습니다.

그러나 사용 중인 파일 시스템을 마운트 해제할 수도 있습니다. 이렇게 하려면 -f 옵션과 함께 umount 명령을 실행해야 합니다(force에서, 즉 강제로). 사실, 이로 인해 오류가 발생할 수 있으므로 꼭 필요한 경우가 아니면 이 방법을 사용하지 않는 것이 좋습니다. 그리고 강제 마운트 해제 옵션은 루트 파일 시스템에 아무런 영향을 미치지 않습니다.

대량 마운트

파일 시스템에서 낮은 수준의 작업을 수행한 후 작업을 계속하려면 파일 시스템을 다시 마운트해야 합니다. 이 작업은 재부팅 없이 수행할 수 있을 뿐만 아니라 지루한 개별 장착 작업 없이도 수행할 수 있습니다. -a 옵션을 사용하세요.

$마운트 -a

/etc/fstab에 항목이 있는 모든 파일 시스템이 마운트됩니다. 이 경우 noauto 플래그로 표시된 항목을 마운트하려고 시도합니다. 이를 방지하려면 파일 시스템 유형을 추가로 정의할 수 있습니다. 즉, 팀

$ 마운트 -a -t ufs

CD나 플래시 드라이브를 침해하지 않고 BSD 파티션만 마운트합니다. 또는 반대로 /etc/fstab에 나열된 일부 파일 시스템(예: 불필요한 파일 시스템)을 전역 마운트 프로세스에서 제외할 수 있습니다. 이 순간지방:

$ 마운트 -a -t nomsdosfs

결론 대신 서문

그건 그렇고, 옵션과 인수가 없는 mount 명령(그리고 이 형식에서는 위에서 설명한 모든 경우와 달리 주어질 수도 있습니다) 일반 사용자)에는 마운트 지점, 해당 조건 및 작동 모드를 나타내는 현재 마운트된 파일 시스템 목록이 표시됩니다. 예를 들어, 이 행이 작성된 시스템의 경우 출력은 다음과 같습니다.

/dev/ad0s1a on / (ufs, local, noatime, 소프트 업데이트) devfs on /dev (devfs, local) /dev/ccd0e on /var (ufs, local, noatime, 소프트 업데이트) /dev/ccd1e on / usr(ufs, local, noatime, 소프트 업데이트) /home의 /dev/ccd2e(ufs, local, noatime, 소프트 업데이트) /tmp(ufs, local, noatime, async)의 /dev/md0

출력의 첫 번째 줄은 /dev/ad0s1a 파티션이 루트 디렉터리에 마운트되어 있고 소프트 업데이트를 통해 UFS 파일 시스템(특히 이 경우에는 UFS2이지만 mount 명령의 출력에서는 다르지 않음)을 전달함을 보여줍니다. 활성화된 메커니즘은 로컬입니다(즉, 이 시스템의 디스크에 위치함 - 네트워크 드라이브또한 mount 명령으로 마운트됨) atime 속성 업데이트의 대상이 되지 않습니다.

$ more /etc/fstab /dev/ad0s1b 없음 스왑 sw 0 0 /dev/ar0s1b 없음 스왑 sw 0 0 /dev/ad0s1a / ufs rw,noatime 1 1 /dev/ccd0e /var ufs rw,noatime 2 2 /dev/ ccd1e /usr ufs rw,noatime 2 2 /dev/ccd2e /home ufs rw,noatime 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 /dev/da0s1 /mnt/usb ext2fs rw,noauto,noatime 0 0 / dev/md0 /tmp mfs rw,noatime,async,-s32m 2 0

그런 다음 출력 라인 중 하나를 볼 수 있습니다

/dev의 Devfs(devfs, 로컬)

그의 기록에는 전혀 일치하는 내용이 없습니다. 이러한 장치와 파일 시스템은 무엇입니까?