Linux는 하드 드라이브 문자를 할당하기 위해 어떤 알고리즘을 사용합니까?

Linux는 하드 드라이브 문자를 할당하기 위해 어떤 알고리즘을 사용합니까?

/dev/sda/dev/sdb/동일한 시스템을 반복적으로 부팅하더라도 장치 이름과 물리적 하드 드라이브 간의 매핑이 변경되지 않은 채 유지되는 것을 관찰했습니다 .

그러나 하드 드라이브를 마더보드의 다른 슬롯에 연결하거나 드라이브를 추가/제거해도 상황이 동일하게 유지되는지 잘 모르겠습니다.

장치 이름을 물리적 하드 디스크에 매핑하는 것과 관련하여 Linux는 어떤 보장을 합니까?

물리적 하드 드라이브를 /dev/의 파일에 매핑하는 데 어떤 규칙을 사용합니까?

답변1

드라이브 이름(일반적인 Linux 시스템)은 커널에 의해 결정되며(장치가 커널에서 먼저 감지되어야 하기 때문에) 나중에 udev에 의해 수정될 수 있습니다.어떻게어떤 하드웨어가 어떤 블록 특수 파일에 매핑되는지 결정하는 것은 구현 세부 사항이며 udev 구성, 커널 구성, 모듈 설정 및 기타 여러 가지(운 포함)에 따라 달라집니다.

동일한 하드웨어 및 구성을 사용하더라도 장치-드라이브 문자 매핑이 항상 동일하다고 보장할 수는 없습니다(일부 시스템은 특히 병렬 모듈 로딩 시스템과 같은 경합 조건으로 인해 장치 이름을 바꾸는 경향이 있습니다).

묻지 않은 질문에 대답하려면 /dev/sd*어떤 장치에 설치할지 미리 알지 않는 한(예: fdisk사용 및/또는 검사 후 수동으로 설치한 경우 blkid) 이를 식별자로 사용하지 마세요. 대신 파일 시스템 레이블, 파일 시스템 UUID 또는 디스크 ID를 사용하여 검색 순서가 아닌 해당 속성으로 올바른 장치, 파티션 또는 파일 시스템을 가리키고 있는지 확인하세요. 에서 디스크 ID를 찾을 수 있습니다 /dev/disk/by-id. 이는 편리한 마운트 위치이며 항상 동일한 디스크를 사용하도록 보장합니다.

/dev/sda1예를 들어, 현재 파티션에 사용 가능한 디스크 ID를 찾으려면 다음을 사용할 수 있습니다 find.

$ find -L /dev/disk/by-id -samefile /dev/sda1
/dev/disk/by-id/wwn-0x5000cca22dd9fc29-part1
/dev/disk/by-id/ata-HGST_HUS724020ALA640_PN1181P6HV51ZW-part1

답변2

관련 질문(자동 사이드바에서):/sda /sdb가 부팅 사이에 변경되는 것을 방지하는 방법은 무엇입니까?


이는 커널이 "탐색"(또는 "바인딩")하는 순서대로 할당되도록 보장합니다.

Greg KH는 명령에 의존하는 것을 반대합니다. 그는 후속 부팅 사이에 PCI 순서를 재배치한 (진짜!) 추악하게 디자인된 마더보드의 예를 들기를 좋아합니다. 위의 질문은 그러한 예에 관한 것 같습니다.

로드 가능한 모듈은 사용자 공간에 의해 로드됩니다. udev병렬화를 위해 여러 프로세스를 사용하며 모듈이 특정 순서로 로드된다는 보장은 없습니다. 이와 같은 병렬 초기화는 모듈 초기화 기능이 병렬로 실행될 수 있고 이러한 기능에는 하드웨어를 기다리는 긴 지연이 포함될 수 있으므로 실질적인 성능 이점을 제공할 수 있습니다.

현재 커널은 다음과 같다고 가정할 수 있습니다.기본탐지하는 것이다내장드라이버는 동기화되므로 정해진 순서대로 이루어집니다.

v4.2부터 Linux 커널은 이제 비동기식 프로브를 지원합니다.

(분명히 이 기능은 Google Chrome OS에서 사용됩니다.)

https://www.do-not-panic.com/2015/12/linux-asynchronous-probe.html

https://kernelnewbies.org/Linux_4.2#Core

기반으로역사 뉴스특히 Linus의 이러한 노력에 대해 사람들이 회의적이거나 피로하다고 생각할 수도 있습니다. 위의 내용에 따르면, 조사 강화 및/또는 열띤 외침 메시지가 이 옵션을 통합하는 데 방해가 되지 않은 것으로 보입니다.

커널 전체에서 활성화하는 것은 또 다른 문제입니다. "[일부] 드라이버는 드라이버 버그 또는 최적이 아닌 드라이버 구성으로 인해 비동기 프로브와 잘 작동하지 않습니다." 어쩌면 Linus가 "궁극적인 목표는 기본적으로 프로브를 비동기화하는 것입니다"라는 병합의 커밋 메시지에서 이탈(?)하지 않았을 수도 있지만, 그것은 단지 의견일 뿐이고 그 이후로 어떻게 진행되었는지는 알려주지 않습니다. v4.2.

답변3

fstab이 실행될 때 항상 마운트되도록 탭을 통해 마운트한 외부 USB 드라이브가 있지만 여전히 문제가 있습니다. 때로는 장치가 마운트된 후에도 드라이브 할당이 변경되고 변경된 드라이브의 파일에 액세스할 수 없게 되는 경우가 있습니다.

저는 Ubuntu 16.04.4 LTS(Linux 4.4.0-128-generic i686)를 실행하고 있습니다.

나는 일일 세션 사이에 절전 모드를 사용하고 있으며, 이에 대해 확실하지는 않지만 절전 모드에서 깨어날 때 드라이브가 재할당되는 것으로 의심됩니다. 일반적으로 /dev/sdc가 할당되어 있고, USB SD 카드 리더를 연결했는데 /dev/sdd가 할당되어 있습니다. 때때로 외장 드라이브를 읽거나 쓸 수 없습니다. 이런 일이 발생했을 때 나는 그것이 /dev/sde에 재할당되었음을 발견했습니다. 한 가지 해결 방법은 단순히 OS를 재부팅하면 모든 것이 정상으로 돌아가는 것이지만 극단적으로 갈 필요는 없는 해결 방법을 찾고 있습니다.

제가 찾은 더 나은 해결책은 먼저 외장 드라이브 파티션에 있는 폴더의 터미널 탭을 포함하여 외장 드라이브 파티션에 액세스하는 모든 응용 프로그램을 닫는 것입니다. 액세스할 수 없는 드라이브의 파일을 변경하는 응용 프로그램이 있는 경우 1) 데이터를 저장하기 위해, 2) 액세스할 수 없는 파티션에 대한 링크를 끊기 위해 파일을 액세스할 수 있는 다른 파티션에 저장해야 합니다. 그런 다음 파티션을 마운트 해제합니다.

sudo umount /dev/sde

또는 외부 드라이브의 모든 파티션을 할당합니다. 그런 다음 모든 파티션을 다시 마운트했습니다.

sudo mount -a

이 작업을 수행한 후 파티션이 예상된 /dev/sdc 대신 /dev/sde로 할당되었음에도 불구하고 모든 응용 프로그램이 이제 잘못된 파티션에 다시 액세스할 수 있음을 발견했습니다. fstab은 레이블을 사용하고 이러한 파티션을 폴더에 마운트하므로 이러한 재배포는 문제가 되지 않습니다. 한달에 두세번은 하는 것 같아요.

파티션 식별을 위해 레이블을 사용하더라도 설치 시 레이블이 장치 문자 할당에 매핑되고 이것이 이 문제의 원인인지 궁금합니다. 확실히 말할 수는 없어요... 그냥 생각만 했을 뿐입니다.

답변4

장치 이름을 물리적 하드 디스크에 매핑하는 것과 관련하여 Linux는 어떤 보장을 합니까?

물리적 하드 드라이브를 /dev/의 파일에 매핑하는 데 어떤 규칙을 사용합니까?

모든 Linux 배포판에 대해 말할 수는 없지만 SUSE가 이를 수행하는 방법과 SUSE에서 사용할 수 있는 옵션에 대해서는 말할 수 있습니다.

마운트 포인트

  • 장치 이름
  • 장치 아이디
  • 볼륨 지정
  • 장치 경로
  • 보편적으로 고유한 식별자

장치 이름으로나는 그렇다고 말할 것이다나쁜왜냐하면 리눅스가 하드웨어를 확인하고주문하다연결된 드라이브가 표시되는 위치는 sda, sdb 등에 매핑되는 방식입니다. 따라서 부팅 장치와 파티션을 sda라고 하고 이동식 슬롯(서버의)에 있는 드라이브의 순서를 바꾸거나 가정용 컴퓨터의 두 드라이브 사이에 SATA 케이블을 바꾸는 경우 혼동이 발생할 수 있습니다. 또한 내 경험에 따르면(드라이브 베이가 8개, 16개 또는 24개 있는 서버에서) 드라이브 슬롯 0이 자주 대체되어 sda에 매핑되지 않습니다. 드라이브가 3개 있는 경우 슬롯 2는 sda이고 슬롯 1은 sdb입니다. 슬롯 0은 sdc입니다. 그리고 매핑된 임시 하드웨어를 추가하고 /dev/sda드라이브를 문자 아래로 누르면 상황이 엉망이 됩니다. 하지만 복제하려는 골든 이미지 OS 드라이브를 설정할 때 이 접근 방식이 좋다고 말하고 싶습니다. 적어도 한동안은 새 디스크에서 하드 드라이브 ID나 WWN이 변경되는 것에 대해 걱정할 필요가 없습니다. ..의 경우오직시스템의 디스크는 항상 sda로 표시될 가능성이 높습니다.

FSTAB syntax:**
/dev/sdc2 / EXT3 acl,user_xattr 1 1
/dev/sdc1 /boot/efi VFAT
/dev/sdb1 /data XFS defaults 1 0

기기 ID별해결해주기 때문에 제가 자주 사용하는 것입니다원래"장치 이름별"에서 언급된 모든 문제는 거의 모든 문제에서 수년 동안 나에게 큰 도움이 되었습니다. 장치 ID를 통해 설치를 구성한 후 드라이브가 존재하거나 연결되기만 하면 됩니다. 드라이브가 이동되거나 새 하드웨어가 무언가에 매핑되어도 /dev/sd?이전에 구성한 내용에는 영향을 미치지 않습니다.

FSTAB syntax:
/dev/disk/by-id/scsi-35000aab12345a30-part2 / EXT3 acl,user_xattr 1 1
/dev/disk/by-id/scsi-35000aab12345a30-part1 /boot/efi VFAT
/dev/disk/by-id/scsi-3600404abc123def456-part1 /data XFS defaults 1 0

UUID(범용 고유 식별자)나는 이것이 좋은 접근 방식이라고 생각합니다. "장치 ID별"과 매우 유사하게 작동하지만 UUID가 어떻게 생성되고 고유하게 만들어지는지, 아니면 결국 장치 ID와 동일하게 되는지 모르겠습니다.

라벨별마운트하려는 파일 시스템, 파티션 또는 볼륨에 대해 귀하 또는 누군가가 좋은 볼륨 레이블을 만든 경우에도 잘 작동합니다. 두 파티션의 볼륨 레이블(예: "부팅")이 동일한 경우 문제가 발생할 것이라고 확신합니다.의심하다Linux가 중복된 레이블을 보고하지 않으면 발견된 첫 번째 레이블을 사용합니다.

또한 이것은 모두 Linux Udev를 기반으로 합니다(어떤 알고리즘이 사용되는지 대답하기 위해). 나는 Udev가 대부분의 Linux 배포판에서 사용되는 패키지이기 때문에 이전 Init Linux와 새로운 Systemd Linux가 모두 동일하다고 생각합니다. 그리고제 생각에는주로 /etc/fstab 첫 번째 필드 또는 각 행의 열에 있는 구문에 따라 발생하는 설치 방법(알고리즘이 아님)이 결정됩니다. 어딘가에 다른 구성 파일이 없습니다. /etc/fstab각 행에 서로 다른 마운트 방법을 전달하는 여러 행이 있을 수 있기 때문에 이렇게 말하는 것입니다. (이름, ID, UUID 또는 레이블 기준)은 다른 것을 마운트하며 내가 아는 한 fstab 파일의 구문을 제외하고는 아무 것도 변경되지 않았습니다.

관련 정보