드라이브/파티션 문자가 여전히 사용되는 이유는 무엇입니까?

Question 1

엄밀히 말하자면,UUID가 해결되지 않았습니다.별말씀을요.

주소 지정은 매우 간단합니다. 드라이브 X 섹터 Y를 읽으십시오. 그렇지 않으면. 메모리 주소 Z를 읽으십시오 - 그렇지 않으면. 주소 지정은 간단하고 빠르며 해석의 여지가 많지 않으며 어디에나 존재합니다.

UUID가 해결되지 않았습니다. 대신 검색하고 찾아내고 때로는 기기가 나타날 때까지 기다리기도 하고,파일 시스템에 대해 알아보기(★). 그리고 기기 수에 따라 시간이 오래 걸릴 수도 있습니다. 찾으면 일반 주소 지정으로 돌아갑니다.

GRUB에서는 (★★)라고 하며 searchGRUB에 날개가 있는 경우에만 사용할 수 있습니다(검색은 지원하는 모든 파일 시스템에 대한 모듈이므로 코어가 로드된 경우에만 사용할 수 있습니다). Linux에서는 (예를 들어) findfs,findfs는 시스템의 블록 장치에서 파일 시스템이나 파티션을 검색합니다..

모든 블록 장치를 통과하여 대기 상태에서 깨우고 데이터를 읽습니다. UUID가 고유하지 않은 경우(사고 후 등) 결과는 여전히 무작위일 수도 있습니다 dd. 변경해도 아무런 결과가 발생하지 않습니다. UUID에는 구성 오류가 발생하기 쉽습니다.

일반적으로 UUID는 훌륭하며, 물론 가능한 경우 어디에서나 사용해야 합니다. 특히 Linux의 드라이브 순서가 무작위이기 때문에 기존 주소 지정이 실패할 수 있지만 복잡성이 단순한 주소 지정 의미를 뛰어넘는다는 점을 이해해야 합니다. 특히 부트로더 초기 단계에서는 아직 선택 사항이 아닐 수도 있습니다. 먼저 문제를 해결한 다음 날개를 키워보세요.

부트 로더의 경우 노력이 전혀 필요하지 않을 수 있습니다(모든 부트 로더가 GRUB와 같은 광범위한 파일 시스템을 지원하는 것은 아닙니다). 상황(BIOS에서 제공)으로 인해 "부팅할 디스크"가 보장 된다면 hd0임의의 드라이브 순서 문제를 배제할 수 있다면 잠재적으로 많은 다른 파티션 목록을 살펴볼 필요가 없을 것입니다. UUID를 검색합니다.

hd0,gpt2이것이 원하는 구성이고 이 방식이어야 하며 이 방식일 수 없다고 말할 수 있을 만큼 구성에 확신이 있다면 이 방식을 사용하는 데 아무런 문제가 없습니다. 때로는 단순하고 간단한 주소 지정이 가능합니다.

(★) 아까도 설명드렸지만여기에 태그를 추가하세요...

라벨에 대한 보편적인 표준은 없으며 모두 손으로 짠 것입니다. 예를 참조하세요.util-linux에서 슈퍼 블록 형식 구현. 내일 새로운 파일 시스템을 개발한다면 레이블이 있더라도 지원이 추가될 때까지 표시되지 않습니다.

...UUID도 마찬가지입니다.

(★★) 사실 GRUB 에는 옵션이 search있는데 --hint... 지금은 소스 코드를 확인하지도 않았고 매뉴얼에 문서화도 하지 않았지만 그러한 옵션은 의미가 있고 두 가지 장점을 모두 제공할 것입니다. 프롬프트가 search알려 주어야 합니다.먼저 파티션을 확인해보세요, UUID가 예상대로 일치하면 장치를 식별합니다.최소한의 노력, 일치하는 항목이 없으면 계속해서 전체 검색으로 돌아가 작업을 계속 수행합니다.

그 외에도 이전에 발견된 UUID는 캐시되는 경향이 있으므로 모든 장치를 계속해서 검색할 필요가 없습니다. 찾고 있는 UUID가 캐시에 저장되어 실제로 어딘가에 존재하는 한 이 방법도 잘 작동합니다. 우선 .

Answer

엄밀히 말하자면,UUID가 해결되지 않았습니다.별말씀을요.

주소 지정은 매우 간단합니다. 드라이브 X 섹터 Y를 읽으십시오. 그렇지 않으면. 메모리 주소 Z를 읽으십시오 - 그렇지 않으면. 주소 지정은 간단하고 빠르며 해석의 여지가 많지 않으며 어디에나 존재합니다.

UUID가 해결되지 않았습니다. 대신 검색하고 찾아내고 때로는 기기가 나타날 때까지 기다리기도 하고,파일 시스템에 대해 알아보기(★). 그리고 기기 수에 따라 시간이 오래 걸릴 수도 있습니다. 찾으면 일반 주소 지정으로 돌아갑니다.

GRUB에서는 (★★)라고 하며 searchGRUB에 날개가 있는 경우에만 사용할 수 있습니다(검색은 지원하는 모든 파일 시스템에 대한 모듈이므로 코어가 로드된 경우에만 사용할 수 있습니다). Linux에서는 (예를 들어) findfs,findfs는 시스템의 블록 장치에서 파일 시스템이나 파티션을 검색합니다..

모든 블록 장치를 통과하여 대기 상태에서 깨우고 데이터를 읽습니다. UUID가 고유하지 않은 경우(사고 후 등) 결과는 여전히 무작위일 수도 있습니다 dd. 변경해도 아무런 결과가 발생하지 않습니다. UUID에는 구성 오류가 발생하기 쉽습니다.

일반적으로 UUID는 훌륭하며, 물론 가능한 경우 어디에서나 사용해야 합니다. 특히 Linux의 드라이브 순서가 무작위이기 때문에 기존 주소 지정이 실패할 수 있지만 복잡성이 단순한 주소 지정 의미를 뛰어넘는다는 점을 이해해야 합니다. 특히 부트로더 초기 단계에서는 아직 선택 사항이 아닐 수도 있습니다. 먼저 문제를 해결한 다음 날개를 키워보세요.

부트 로더의 경우 노력이 전혀 필요하지 않을 수 있습니다(모든 부트 로더가 GRUB와 같은 광범위한 파일 시스템을 지원하는 것은 아닙니다). 상황(BIOS에서 제공)으로 인해 "부팅할 디스크"가 보장 된다면 hd0임의의 드라이브 순서 문제를 배제할 수 있다면 잠재적으로 많은 다른 파티션 목록을 살펴볼 필요가 없을 것입니다. UUID를 검색합니다.

hd0,gpt2이것이 원하는 구성이고 이 방식이어야 하며 이 방식일 수 없다고 말할 수 있을 만큼 구성에 확신이 있다면 이 방식을 사용하는 데 아무런 문제가 없습니다. 때로는 단순하고 간단한 주소 지정이 가능합니다.

(★) 아까도 설명드렸지만여기에 태그를 추가하세요...

라벨에 대한 보편적인 표준은 없으며 모두 손으로 짠 것입니다. 예를 참조하세요.util-linux에서 슈퍼 블록 형식 구현. 내일 새로운 파일 시스템을 개발한다면 레이블이 있더라도 지원이 추가될 때까지 표시되지 않습니다.

...UUID도 마찬가지입니다.

(★★) 사실 GRUB 에는 옵션이 search있는데 --hint... 지금은 소스 코드를 확인하지도 않았고 매뉴얼에 문서화도 하지 않았지만 그러한 옵션은 의미가 있고 두 가지 장점을 모두 제공할 것입니다. 프롬프트가 search알려 주어야 합니다.먼저 파티션을 확인해보세요, UUID가 예상대로 일치하면 장치를 식별합니다.최소한의 노력, 일치하는 항목이 없으면 계속해서 전체 검색으로 돌아가 작업을 계속 수행합니다.

그 외에도 이전에 발견된 UUID는 캐시되는 경향이 있으므로 모든 장치를 계속해서 검색할 필요가 없습니다. 찾고 있는 UUID가 캐시에 저장되어 실제로 어딘가에 존재하는 한 이 방법도 잘 작동합니다. 우선 .

Question 2

간단한 번호 매기기 체계는 실제로 최근 시스템에서 사용되지 않습니다("최근"은 Ubuntu 9 이상이며 다른 배포판에서도 해당 시대에 적용했을 수 있음).
루트 파티션이 일반적인 번호 지정 방식으로 설정되어 있음을 확인했는데 이는 맞습니다. 그러나 이는 기본 또는 대체 설정일 뿐이며 일반적으로 다음 명령으로 재정의됩니다. 예를 들면 다음과 같습니다.

search --no-floppy --fs-uuid --set=root 74686973-6973-616e-6578-616d706c650a

그러면 파일 시스템의 UUID를 기반으로 루트 파티션이 선택됩니다.

실제로 일반 번호 지정 체계는 일반적으로 안정적입니다(하드웨어 변경이 없는 한). 내가 관찰한 예측할 수 없는 번호 매기기의 유일한 사례는 선착순 모델을 기반으로 열거된 다음 IDE 드라이브로 에뮬레이션되는 많은 USB 드라이브가 있는 시스템입니다. 이러한 프로세스는 본질적으로 지저분하지 않으므로 이 특정 시스템의 BIOS 구현에 문제가 있다고 가정합니다.

참고: 이 문서의 "루트 파티션"은 부팅 파티션을 의미하며, 이는 "루트(일명 ./filesystem)"을 포함하는 파티션과 다를 수 있습니다.

Answer

간단한 번호 매기기 체계는 실제로 최근 시스템에서 사용되지 않습니다("최근"은 Ubuntu 9 이상이며 다른 배포판에서도 해당 시대에 적용했을 수 있음).
루트 파티션이 일반적인 번호 지정 방식으로 설정되어 있음을 확인했는데 이는 맞습니다. 그러나 이는 기본 또는 대체 설정일 뿐이며 일반적으로 다음 명령으로 재정의됩니다. 예를 들면 다음과 같습니다.

search --no-floppy --fs-uuid --set=root 74686973-6973-616e-6578-616d706c650a

그러면 파일 시스템의 UUID를 기반으로 루트 파티션이 선택됩니다.

실제로 일반 번호 지정 체계는 일반적으로 안정적입니다(하드웨어 변경이 없는 한). 내가 관찰한 예측할 수 없는 번호 매기기의 유일한 사례는 선착순 모델을 기반으로 열거된 다음 IDE 드라이브로 에뮬레이션되는 많은 USB 드라이브가 있는 시스템입니다. 이러한 프로세스는 본질적으로 지저분하지 않으므로 이 특정 시스템의 BIOS 구현에 문제가 있다고 가정합니다.

참고: 이 문서의 "루트 파티션"은 부팅 파티션을 의미하며, 이는 "루트(일명 ./filesystem)"을 포함하는 파티션과 다를 수 있습니다.

Question 3

태그도 잊지 마세요. UUID만큼 고유하지는 않지만 더 많은 정보를 제공하고 fstab을 읽을 수 있게 만듭니다. 데스크톱이거나 소규모 회사인 경우, 즉 몇 개에서 수십 개의 드라이브를 관리하는 경우 UUID 대신 레이블을 선호할 수 있습니다.

@frostschutz의 묵상좋은 대답귀하의 질문과 관련하여 "클래식" 장치 링크 주소 지정을 선호할 수 있는 상황 중 하나는 특히 온-렌트 가상 머신(약어로 "IaaS") 클라우드에서 가상 머신 설정입니다. 당신이우벤지마04.18영상. 2개의 디스크가 있는 (일회용) VM을 만듭니다. 하나는 (일회용) 시스템 드라이브이고, 두 번째는 설치하고 사용자 지정한 드라이브입니다. 새 디스크에서 최신 grub을 실행하려면 UEFI 부팅 파티션을 마운트해야 할 수도 있습니다. 아래의 대상 파티션에 대한 마운트 지점을 선택했다고 가정하면 /mnt필요한 마운트 테이블은 다음과 같습니다.

/dev/sda1    /
/dev/sda9    /boot/efi
/dev/sdb1    /mnt/root
/dev/sdb9    /mnt/efi

따라서 공급자가 제공한 기존 클라우드 지원 이미지에서 동일한 드라이브 2개를 만들고 이를 새 가상 머신에 연결하고 부팅할 수 있습니다. 자연,

우리가 상상하는 모든 최신 운영 체제 배포판우벤지마04.18예외는 없습니다. UUID 이름 지정을 사용하는 마운트도 예외는 아닙니다.
동일한 이미지에서 밀어낸 모든 하드 드라이브는 동일한 UUID를 갖습니다. UUID는 고유한데 무엇이 잘못될 수 있나요?

당신은 이것이 어디로 가는지 이미 알고 있습니다.

이 Frankencontraption은 처음 부팅할 때 부팅 파티션을 EFI로 선택 sda9하지만 Linux는 이를 sdb1루트 FS로 다시 마운트하기로 결정합니다.

/dev/sda1    /mnt/root
/dev/sdb1    /
/dev/sda9    /boot/efi
/dev/sdb9    /mnt/efi

내 롤아웃 스크립트가 이에 대해 준비되지 않았기 때문에 부팅되지 않는 쓸모없는 이미지가 생겼고 Frankenbuild 중에 로그에 도구가 불평하지 않았습니다!

틀림없이로그에 설치 테이블을 인쇄했습니다. 그리고틀림없이mount(8)는 무작위 마운트 순서와 장치 마운트 순서 사이의 어딘가에 마운트 순서를 인쇄하기 때문에 이러한 혼란을 발견하기 어렵습니다. 따라서 제가 이를 즉시 발견하지 못한 것은 놀라운 일이 아닙니다. 동일한 스크립트(다른 이미지 디스크 사용)가 2015년에 Glenfiddich가 했던 것과 똑같이 작동했다고 상상해 보십시오. 문제를 파악하기 위해 나무에 머리카락을 붙이는 데 몇 시간을 소비했는지 추측해 보세요.

데스크톱 컴퓨터부터 라우터에 내장된 Linux, Android 휴대폰, 클라우드 데이터 센터에 이르기까지 모든 것에 적용되는 엄격하고 빠른 규칙은 없습니다. SO 답변은 객관적이어야 하지만 내 경험이나 선호도는 확실히 그렇지 않습니다. 따라서 다양한 파티션 식별 방법 중에서 선택할 때 논리적 추론의 예를 보여 드리겠습니다.

내버려둬그렇게 하지 않을 이유가 없다면. UUID는 대부분의 최신 배포판에서 기본값입니다. 두 번째 드라이브를 추가해야 한다면 시도해 보고 결정하세요. 아마 전혀 알 필요가 없을 것입니다. 시스템이 여전히 부팅되고 새 장치를 볼 수 있고 파티션을 나눌 수 있으면 포맷하고 fstab에 추가합니다(UUID, LABEL 또는 link 를 통해 /dev동일한 고려 사항이 적용됩니다). 문제는 추가 드라이브를 연결한 후 시스템이 부팅을 거부하는 경우에만 발생합니다. UEFI BIOS에서 부팅 순서를 변경하는 것이 가장 빠른 해결 방법일 수 있습니다.

실제로 어떤 SATA 커넥터가 데스크탑의 어떤 드라이브에 연결되어 있는지 표시하는 것이 아마도 가장 빠르고 쉬운 솔루션일 것입니다. 반면 시스템 부팅 방법을 변경하고 부팅 오류가 발생할 가능성이 높은 경우 복구하는 것은 틀림없이 가장 시간이 많이 걸리는 방법입니다. 그러나 50명의 프로그래머를 위해 관리하고 있고 추가 드라이브를 추가하는 것이 귀찮게 할 만한 문제가 아니라고 결정한다면 적어도 행운의 한계를 테스트하지 말고 초기 부팅 드라이브가 모두 표시되는지 확인하십시오. grub hd0및 시스템은 sda.
상표소규모 환경(우스꽝스럽게 "스타트업 사무실"이라고 부르는 소프트웨어 엔지니어들로 가득 찬 집의 거실)에서 자신의 데스크톱 또는 세 개의 데스크톱 또는 자신의 드라이브와 파티션을 관리하세요. 다른 사람의 컴퓨터에서 물리적 드라이브를 꺼낸 경우 레이블을 일관되게 사용하면 그것이 어디서 왔는지 알 수 있습니다.

if lsblk(8)이 말하는 LABEL=bubba-boot시스템에서 가져온 것임을 알고 있습니다.부바;와는 별개로,Bubba 리드내 혀를 굴려봐6864c4ea-f9b9-46db-b875-4d7fc2981007, 제 입맛에는 입이 떡 벌어질 정도입니다. 이제 라벨이 고유한지 확인하는 것은 귀하의 책임입니다. 그러나 그 대가로 얻는 것은 라벨의 의미입니다.
/dev- 링크를 기반으로동일한 이미지의 파생물이며 상대적으로 수명이 짧고 유지 관리가 적은 VM을 명령할 때 모든 UUID가 UU 약속과 일치한다고 주급을 걸지는 못할 것입니다. 어느합리적인VM 서비스, 그게 다야와이퍼-H자신의 물리적 서버에서 또는쿠겔클라우드또는 부팅 드라이브를 호출하지 않는 모든 것 sde, 그리고 두 번째이자 유일한 다른 sdc드라이브²입니다. 반면 물리적 시스템에서는 SATA 케이블을 창의적으로 연결하여 동일한 배열을 쉽게 얻을 수 있습니다.

지금은 다른 방향으로 나아갔지만 이 경우에는 소위 "일관된" 이더넷 인터페이스 이름 지정과 동일한 경로를 사용했습니다. 즉, 가상 머신에서 이를 비활성화합니다. 오해하지 마십시오. PCI 슬롯 4에 넣은 카드가 보지 않을 때(또는 보지 않을 때에도 슬롯 5로 무작위로 점프하지 않는 한 이름은 꽤 일관적입니다. 카드에 수치심). 불행하게도 "여단" 환경에서는 그것이 바로 그들이 하는 일입니다. eth0이런 경우에는 직관에 어긋나게더일관된 비율 enp0s4f6. VM 공급자는 항상 가상 NIC 번호 1을 PCI 버스 0의 슬롯 4에 배치할 것을 약속하지 않으며(언급된 3개 엔터티 중 어느 것도 물리적으로 실제가 아님) 항상 기능 6이 될 것이라고 약속하지 않습니다. 그러나 일반적으로 virtio 제품군의 동일한 드라이버 모듈을 가지고 있다는 점을 고려하면 두 번째 인터페이스 이전의 첫 번째 인터페이스에 크게 의존할 수 있습니다(첫 번째 NIC가 항상 eth0동일한 것이 아닌 경우 Note²는 여전히 적용됩니다).

1 물론 이것은 상징적이다. 나는 이 사업을 너무 오랫동안 해왔기 때문에 남은 것이 아무것도 없습니다.
² 그렇다면 나는 ~~그들의 비명을 피하고~~ 공급업체나 하이퍼바이저 소프트웨어를 바꾸는 것을 진지하게 고려할 것입니다.

Answer