커널 공간 관점에서 파일 시스템 UUID는 어떻게 작동합니까(그리고 고유하지 않은 경우 Linux 상자는 어떻게 됩니까?)

커널 공간 관점에서 파일 시스템 UUID는 어떻게 작동합니까(그리고 고유하지 않은 경우 Linux 상자는 어떻게 됩니까?)

마지막으로 이것이 제가 답을 찾고 싶은 질문이라고 생각합니다.루트 파일 시스템에 고유한 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라는 간단한 규칙을 따르지 않으면 내 머신/파일 시스템에 어떤 일이 발생합니까?

폭발하지는 않지만 이 구성을 유지하는 것은 권장하지 않습니다. 파티션을 복제하고 대상 디스크를 삭제합니다.

관련 정보