페도라와 우분투를 말합니까?
… 둘 다 오늘날 시스템 운영 체제입니다.
시스템 운영 체제에서 발생하는 사항
기본 메커니즘
Systemd는 다양한 종류의 장치를 사용합니다. .mount단위 파일은 볼륨을 마운트하도록 지시합니다. .swap유닛 파일은 커널에게 스왑 파티션에 대해 알려주도록 지시합니다. ( .service단위 파일은 서비스를 실행하는 방법을 알려줍니다. 등) 기본 시스템 메커니즘입니다. 이를 구현하기 위해 시스템 자체는 관련 시스템 호출을 수행하는 하위 프로세스를 분기합니다.
이러한 시스템 운영 체제에서 systemctl(with --all) 명령 을 사용 하면로드 된 .swap장치 에 대해 알려줍니다 . 예를 들면 다음과 같습니다.
dev-disk-by \ x2dpartuuid-40549710 \ x2d05.swap로드 된 활성 활성 / dev / disk / by-partuuid / 40549710-05
dev-disk-by \ x2duuid-1bb589e8 \ x2d929f \ x2d4041 \ x2d81f4 \ x2dff2b339b4e2a. 스왑로드 된 활성 활성 / dev / disk / by-uuid / 1bb589e8-929f-4041-81f4-ff2b339b4e2a
dev-sda5.swap로드 된 활성 활성 / dev / sda5
또한 .mount단위 에 대해 알려줄 것 입니다.
시스템 관리자는 실제로 같은 쓸 수 있습니다 .swapXE 쓸 수있는 것처럼, 손으로 유닛 파일을 .service, .socket그리고 손으로 다른 유닛 파일. systemd 자체는 파일 시스템에서 단위 파일을 찾습니다. 그것들은 고유의 메커니즘입니다.
이러한 단위 파일의 내용과 파일 시스템의 위치를 표시하도록 시스템을 구성 할 수도 있습니다.
$ systemctl cat dev-disk-by \\ x2duuid-1bb589e8 \\ x2d929f \\ x2d4041 \\ x2d81f4 \\ x2dff2b339b4e2a.swap
# /run/systemd/generator/dev-disk-by\x2duuid-1bb589e8\x2d929f\x2d4041\x2d81f4\x2dff2b339b4e2a.swap
# systemd-fstab-generator에 의해 자동 생성
[단위]
SourcePath = / etc / fstab
설명서 = man : fstab (5) man : systemd-fstab-generator (8)
[교환]
What = / dev / disk / by-uuid / 1bb589e8-929f-4041-81f4-ff2b339b4e2a
옵션 = sw
$
자동으로 생성 된 단위 파일
하나는 손으로 쓸 수 있습니다. 그러나 일반적으로 이러한 파일 .mount과 .swap단위 파일은 생성기 라고하는 프로그램에 의해 자동으로 생성됩니다 . 이러한 두 생성기는 systemd-fstab-generator및 systemd-gpt-auto-generator입니다. 부트 스트랩 프로세스 초기에 systemctl daemon-reload명령 에 대한 응답으로 실행되며 (위에서 볼 수 있듯이)에서 문서화되지 않은 하위 디렉토리에 전체 단위 파일로드를 생성합니다 /run/systemd/. systemd 자체 는 생성 된 단위 파일 만 사용합니다 .
이전 생성기 /etc/fstab는 해당 파일 형식에 대한 여러 시스템 확장자를 인식하여를 읽습니다 . 답변 의견에서 지적했듯이 전통적으로 스왑 파티션에는 마운트 유형 이 sw있으며 이는 다른 운영 체제가이 표에서 스왑 레코드를 인식하는 방법입니다. 그러나 Linux 소프트웨어는 VFS 유형을 대신 인식하여 VFS 유형 을 찾는 대안을 택했습니다 swap. systemd-fstab-generator여기서도 예외는 아닙니다 /etc/fstab. 이것이 기본 메커니즘으로 변환 할 때 해석하는 방식입니다.
후자의 생성기는 EFI 시스템 파티션이있는 동일한 디스크에있는 EFI 파티션 테이블을 처리하여 잘 알려진 다양한 파티션 유형 GUID 가있는 EFI 파티션 테이블 항목을 찾습니다 . 이러한 GUID 중 하나는 Linux 스왑 파티션에 할당 된 일반적인 GUID입니다. 그리고 systemd-gpt-auto-generatorGUID가있는 파티션을 찾으면 (systemd doco에 주어진 기준을 만족하는) 파티션을 만들 .swap것입니다. 전혀 /etc/fstab관여 하지 않습니다 .
물론이 과정에는 많은 부작용이 있습니다. 예를 들어, /etc/fstab테이블에 대한 기본 키가 없기 때문에 레코드에는 중복 "spec"및 "file"(예 : "what"및 "where") 필드가있을 수 있습니다. 그러나 기본 시스템 메커니즘에서 "파일"(예 : "where") 필드는 .mount장치 이름에 포함 된 장치 의 고유 키입니다 . 두 .mount유닛이 공유 할 수 없습니다 . 들어 .swap유닛은 "사양"(즉 "무엇을") 필드 단위의 고유 키입니다. 두 .swap유닛이 공유 할 수 없습니다 . 따라서 모든 레코드 /etc/fstab가 반드시 기본 메커니즘으로 변환 가능한 것은 아니며 특히 사람들이 두 가지 다른 목적으로 동일한 마운트 지점을 나열하거나 두 가지 다른 방식으로 동일한 스왑 파티션을 나열하는 경우 작동합니다.
마찬가지로 /etc/fstab기본 메커니즘으로 변환 되고 systemd의 기본 메커니즘 에는 다른 단위 활성화 방법이 있기 때문에 비 시스템 운영 체제의 동작과 미묘하게 다릅니다. .mount유닛은 기본적으로한다 자동 활성화systemd-udevd 의 출현에 응답하여, 부트 스트랩에도 후에는, 축전 장치를 탑재. 아니면은로 표시 할 수 있습니다 Wants=또는 Requires=일부의 .service또는 .socket그들이 때 활성화 (재) 될 것을 의미 단위. 심지어있다 RequiresMountsFor=.
설치 프로그램 및 체계적인 방법
전통적으로 운영 체제 설치 프로그램 및 시스템 관리자는 나중에 시스템을 재구성하여에 sw항목을 기록 했습니다 /etc/fstab. 이것이 네이티브 .mount와 .swap유닛이 자동 생성되는 방식입니다. 설치 / 구성 유틸리티는 사용자 인터페이스에서 시스템 관리자가 어떤 종류의 선택을하고 /etc/fstab일치하도록 쓰기 때문에 스왑 파일이 저장된 위치를 "인식"합니다 . 때로는 설치의 일부로 스왑 파티션을 만들어야합니다. ; 때로는 디스크에서 이미 찾은 스왑 파티션을 사용 하기도합니다 . (파티션 유형을보고있는 설치자도).
그러나 체계화 된 사람들은 상태가없는 시스템/etc 이라고 하는 빈 트리 에서 자동으로 구성되는 운영 체제라는 개념을 가지고 있으며, 이는 EFI 파티션 테이블을 읽는 생성기와 같은 메커니즘에 관한 것입니다. 체계적인 사람들의 계획에는 , 그리고 전혀 영구적 인 구성 데이터가 없으며 ,이 모든 것들이 디스크의 파티션 테이블의 내용 , 모든 부트 스트랩 및 모든에서 추론 됩니다 . 그들은 현재 운영 체제 설치 프로그램을 작성하지 않는 것보다 홍보 하고 있습니다./etc/fstab/etcsystemctl daemon-reload/etc/fstab
기존 방식에서는 물론 각 운영 체제에 고유 한 개인 스왑 파티션이 있고 서로의 스왑 파티션에 닿지 않도록 할 수 있습니다. 그리고 당신은 스왑 파티션을 통해 디스크에 최대 절전 모드를 사용하여 최대 절전 모드 동안 (다른 운영 체제에 멀티 부팅 할 수있을 것으로 기대된다 실제로 경우 인 아주 나쁜 생각 때문에 그것이 원인이 파일 시스템 손상이 방법에 매우 쉽게 될 것입니다) 필요한.
체계화 된 체계에서, 운영 체제가 체계화 된 사람들이 계획 한대로 "상태 비 저장"상태가 아니더라도, 전술 한 발전기는 가동된다; 따라서 필수 파티션 유형을 가진 모든 ESP / 루트 디스크의 스왑 파티션은 모든 시스템 운영 체제에서 자동으로 사용됩니다. 자동 검색된 스왑 파티션을 모두 공유하므로 설치된 운영 체제 당 하나의 스왑 파티션을 만들 필요가 없습니다.
추가 자료