마지막으로 이것이 제가 답을 찾고 싶은 질문이라고 생각합니다.루트 파일 시스템에 고유한 UUID가 없으면 Linux 시스템이 충돌합니까?하지만 계속 읽어보세요. 이 질문은 잘못된 구성으로 인한 영향이 아니라 원인에 대한 통찰력을 얻는 것에 관한 것입니다.
전체 루트 파일 시스템(UUID 포함)을 동일한 크기의 별도 파티션에 복제할 수 있다는 점을 감안할 때. 원본과 복제본 모두에서 inode는 디스크에 있는 동일한 파일과 동일한 블록의 복사본(파티션)을 가리키므로 문제가 발생하기 시작하는 것을 눈치채지 못할 것입니다.
하지만 그렇다면 그 이유나 문제의 성격이 무엇인지 알고 싶습니다.할 수 있는예상됩니다. 파일 시스템의 UUID가 어떻게 여러분의 삶을 더 쉽게 만들어 주는지, 어떻게 작동하는지, 어떻게 작동하는지에 대해 많은 글이 있습니다 udev
. /dev
그리고 UUID가 Linux 시스템 내에서 고유해야 한다는 의견도 있습니다. UUID는 사용자 공간 관점에서 꽤 잘 문서화되어 있다고 생각합니다.커널 공간 관점을 이해하고 싶습니다더 나은 것.
예를 들어, 일부 블록은 한 파티션에서 읽거나 쓰이고 다른 블록은 다른 파티션에서 읽거나 쓰는 일종의 분할 브레인 상황이 발생할 수 있습니까? 커널을 잠글 수 있나요? 다른 장치를 설치 및/또는 제거하는 데 문제가 있습니까? 아마도 한 가지 더 중요한 점은 다중 경로가 어떻게 적용되는지, 매우 특수한 중복 UUID 사례를 관리할 수 있는지입니다.
실제 질문으로 돌아가서:커널은 실제로 이러한 UUID를 내부적으로 어떻게 활용합니까? UUID로 파일 시스템을 마운트하고 mount
, df
또는 의 출력을 확인할 /proc/mounts
때 마운트 명령을 실행하는 데 사용하는 UUID가 표시되지 않고 항상 의 장치 노드가 표시됩니다 /dev
. UUID-장치 매핑을 위한 사용자 공간 인터페이스가 있습니까(장치-UUID와 동일할 필요는 없음)? 커널은 액세스할 블록 장치를 어떻게 결정합니까? 이것이 시간이 지남에 따라 어느 정도 자발적으로 변합니까(아마도 특정 사건으로 인해)? 고유한 UUID라는 간단한 규칙을 따르지 않으면 내 머신/파일 시스템에 어떤 일이 발생합니까?
어쩌면 내 대답은https://www.kernel.org/doc/하지만 내가 정확히 무엇을 찾고 있는지 알 수 없을 때는 조금 부담스럽습니다. 사이트에 대한 딥 링크도 환영합니다.
답변1
정말 간단합니다.
파티션에 고유하지 않은 UUID가 있을 수 있으며 이는 문제가 되지 않습니다. 그러나 실제로 마운트하면 커널이 파티션 사이에 링크를 생성합니다.고유한장치 노드는 /dev
마운트 지점에 할당됩니다. 이는 읽기 및 쓰기가 언제든지 다른 장치에 액세스할 수 없음을 의미합니다.
예를 들어,설치되지 않음UUID
파티션을 나눈 다음 다음을 사용하여 마운트해 보십시오.무작위로mount
그러나 언제든지 출력을 참조하여 실제로 사용된 장치를 확인할 수 있습니다.
커널은 실제로 이러한 UUID를 내부적으로 어떻게 사용합니까?
그렇지 않습니다. 커널은 장치 노드를 사용합니다.
UUID-장치 매핑을 위한 사용자 공간 인터페이스가 있습니까(장치-UUID와 동일할 필요는 없음)?
확인하다 ls -la /dev/disk/by-uuid
.
커널은 액세스할 블록 장치를 어떻게 결정합니까? 이것이 시간이 지남에 따라 어느 정도 자발적으로 변합니까(아마도 특정 사건으로 인해)?
고유하지 않은 파티션이 있는 경우 커널은 주어진 시간에 그 중 무엇이든 사용할 수 있지만 단 한 번(마운트하려고 할 때)만 사용할 수 있다고 상상할 수 있습니다.
고유한 UUID라는 간단한 규칙을 따르지 않으면 내 머신/파일 시스템에 어떤 일이 발생합니까?
폭발하지는 않지만 이 구성을 유지하는 것은 권장하지 않습니다. 파티션을 복제하고 대상 디스크를 삭제합니다.