요약
저는 1TB 내부 디스크가 장착된 Dell Inspiron 17-5767 노트북을 가지고 있습니다. 원래 배송된 Windows 10이 계속 모든 것을 자체적으로 보유하고 지배하도록 허용했습니다(제 게임 OS입니다). 또한 현재 및 향후 Linux OS를 부팅할 외부 드라이브가 두 개 있습니다. 내 현재 설정은 다음과 같습니다.
- USB 3.0 포트 #0: Seagate Expansion+ 931.5 GiB(1000204885504바이트) /dev/sdb로 인식되는 외장 HDD
- 현재 하나의 전체 크기 빈 ext4 파티션이 있지만 이를 12개의 파티션으로 구성된 최적의 정렬 파티셔닝 구성표로 교체하는 데 어려움을 겪고 있습니다(정렬 문제가 문제입니다).
- USB 3.0 포트 #1: 238.5 GiB(256060514304바이트) Samsung SSD 840 Pro가 /dev/sdc로 인식됨
- Fedora LiveCD 설치 프로그램("사용자 정의" 옵션 사용)을 사용하여 파티션을 나누고 공유 스왑 공간, 공유 사용자 공간, 별도의 루트 및 별도의 외부 부팅 파티션을 포함하는 단일 LVM 내에 Fedora LXDE 및 Lubuntu Linux 배포판을 모두 수용합니다. 여기서 외부는 LVM이 아니라 동일한 디스크의 다른 곳에 있는 별도의 기본 파티션을 의미합니다.)
- 이 드라이브는 물리적 및 논리적 블록 크기가 모두 512이고 parted의 'align-check opt x' 유틸리티에 따라 최적으로 정렬되어 있으며 fdisk도 정렬에 만족합니다(어떤 유틸리티에서도 정렬에 대한 불만이 없음).
- UEFI BIOS가 내부 부팅 전에 USB에서 부팅을 시도하므로 사용 가능한 모든 옵션이 포함된 grub 팝업이 표시됩니다.
목표
나는 /dev/sdb 드라이브의 /dev/sdc에서 5개의 Linux 배포판을 사용하여 진행 중인 것과 유사한 것을 복제하려고 합니다. 나는 숙련된 멀티 부팅자이기 때문에 내 프로젝트의 해당 측면을 다루었습니다. 그러나 내 목표의 또 다른 부분은 /dev/sdc의 경우와 마찬가지로 /dev/sdb의 파티셔닝을 최적으로 정렬하는 것인데, 여기서 문제가 발생합니다.
환경
저는 현재 상대적으로 새로 업그레이드된 Fedora LXDE 설치 내에서 작업하고 있으며, 내가 얻는 결과는 상대적으로 새로 업그레이드된 Lubuntu 설치에서도 완전히 반복 가능합니다.
보고된 디스크 매개변수
[root@frank ~]# cat /sys/class/block/sdb/queue/physical_block_size
4096
[root@frank ~]# cat /sys/class/block/sdb/queue/logical_block_size
512
[root@frank ~]# cat /sys/class/block/sdb/queue/minimum_io_size
4096
[root@frank ~]# cat /sys/class/block/sdb/queue/optimal_io_size
33553920
[root@frank ~]# cat /sys/class/block/sdb/alignment_offset
0
[root@frank ~]# fdisk -l /dev/sdb
Disk /dev/sdb: 931.5 GiB, 1000204885504 bytes, 1953525167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 9428D9DB-746C-40CA-B189-060F92A10E3C
Device Start End Sectors Size Type
/dev/sdb1 65535 1953467279 1953401745 931.5G Linux filesystem
Partition 1 does not start on physical sector boundary.
[root@frank ~]#
문제
따라서 물리적 블록 크기 보고에 따르면 디스크는 이전 버전과의 호환성을 위해 논리적 섹터 크기 512b를 사용하더라도 다른 드라이브처럼 512b 대신 4k(고급 형식)인 것으로 보입니다. GNU parted 유틸리티는 최적의 IO 간격을 계산할 때 블록 크기를 512로 가정하고 있음을 알 수 있습니다.
(optimal_io_size + alignment_offset) / physical_block_size = optimal_sector_interval
65535라는 값을 얻습니다. 여기서 자동으로 첫 번째 파티션이 시작됩니다. 정렬 확인 하위 유틸리티가 파티션 정렬을 최적으로 전달하는 유일한 방법은 65535의 배수에서 시작하는 경우입니다. parted의 유일한 방법은 결과는 Physical_io_size를 4096 대신 512로 처리한다고 생각하면 의미가 있습니다.
(33553920 + 0) / 512 = 65535.
그러나 parted는 당연히 4096 블록 크기를 사용할 수 없습니다. 왜냐하면 방정식이 다음과 같이 작동하기 때문입니다.
(33553920 + 0) / 4096 = 8191.875.
그 대답은 고등학교 대수 교사를 만족시킬 것이지만, 이산적인 값(즉, 정수!)을 기대할 수 있는 섹터 간격으로는 분명히 의미가 없습니다. 어쨌든 저는 12개의 파티션을 만들고 싶었고 그 중 일부는 크기가 256MiB만큼 작았기 때문에 GNU Parted에서는 백분율을 사용하여 이를 수행할 수 없었으며 간단히 말해서 최적의 정렬을 위한 정렬 확인만 충족할 수 있었습니다. 'unit s'를 고수하고 내 파티션이 65535초 간격으로 시작되도록 모듈식 산술을 직접 수행했습니다. parted가 제가 원했던 방식이었습니다. 내 연구에 따르면 내 파티션도 해당 간격으로 끝나는 것이 중요하지 않다고 생각했기 때문에 대부분의 파티션 사이에 간격(분명히 65535보다 크지 않음)이 남아 있었습니다.
다시 한 번, parted는 내 결과가 최적으로 정렬되어 물리적 블록 크기를 4096이 아닌 512로 처리했다고 생각했습니다. 그러나 parted를 종료하고 'fdisk -l /dev/sdb'를 실행한 후 출력에 다음이 포함되었습니다.
Partition 1 does not start on physical sector boundary.
Partition 2 does not start on physical sector boundary.
Partition 3 does not start on physical sector boundary.
Partition 4 does not start on physical sector boundary.
Partition 5 does not start on physical sector boundary.
Partition 6 does not start on physical sector boundary.
Partition 7 does not start on physical sector boundary.
Partition 8 does not start on physical sector boundary.
Partition 9 does not start on physical sector boundary.
Partition 10 does not start on physical sector boundary.
Partition 11 does not start on physical sector boundary.
Partition 12 does not start on physical sector boundary.
따라서 parted는 좋아하지만 fdisk는 그렇지 않습니다. 그런 다음 gParted를 사용하여 파티션 구성을 다시 실행하여 단위 크기로 1MiB를 사용하도록 했고 다른 디스크(/dev/sdc)에서 볼 수 있는 것처럼 2048초에 첫 번째 파티션을 시작했습니다. fdisk는 만족스러워서 섹터 정렬에 대한 불평을 멈췄습니다. 그러나 GNU parted는 최소 모드에서는 통과했지만 최적 모드에 대한 정렬 확인 테스트에는 실패했습니다.
그러나 두 경우 모두 mkswap(/dev/sdb11에 배치한 LVM 내에서 스왑 볼륨을 생성하는 데 사용)이 다음과 같은 경고를 표시한다는 것을 발견했습니다.
[root@frank ~]# mkswap /dev/strange_quark_experimental/swap
mkswap: warning: /dev/strange_quark_experimental/swap is misaligned
따라서 mkswap은 parted가 디스크가 최적 정렬 또는 최소 정렬이라고 생각하는지 여부에 관계없이 내 스왑 볼륨이 잘못 정렬된 것을 발견하고, mkswap은 또한 fdisk가 정렬에 만족하는지 여부에 관계없이 내 스왑 볼륨이 잘못 정렬된 것을 발견합니다.
이론
이 모든 것은 적어도 하나의 디스크 보고 또는 파티셔닝 유틸리티의 경고를 무시해야 한다는 인상을 주지만 어느 유틸리티인지는 확신할 수 없습니다. HDD가 포함된 USB 호환 인클로저가 섹터 매개변수 중 하나 이상을 잘못 보고할 수 있으므로 모든 보고가 처음부터 신뢰할 수 없을 수도 있습니다. 예를 들어 실제로는 AF 드라이브가 아닐 수도 있습니다. 아니면 최적의 IO 크기가 잘못 보고되었을 수도 있습니다. 아니면 둘 다일까요? 그리고 저를 믿으십시오. 저는 이것이 PEBKAC 사례일 가능성도 고려했습니다. 4k 드라이브에서 파티션을 정렬하는 방법에 대해 오해하고 있을 수도 있기 때문입니다. 잘 모르겠습니다.
무슨 일이 일어나든, 내 파티션이 최적으로 정렬되고 mkswap 또는 최소한 내가 가장 신뢰해야 하는 유틸리티가 정렬에 대한 불평을 멈추면 실제 Linux 설치를 계속 진행하게 되어 기쁠 것입니다.
돕다
최소 정렬(gParted 또는 gdisk를 사용하여 파티셔닝할 때만 달성됨) 이상의 사항에 동의하도록 분할 및 기타 디스크 유틸리티를 얻을 수 없는 이유를 이해하도록 도와주시고 실제로 너무 걱정해야 하는지 알려주세요. 제 경우에는 최소 정렬보다 최적 정렬의 장점에 대해 설명합니다. 성능이나 디스크 상태에 차이가 너무 작으면 더 이상 시간을 낭비하지 않을 것이기 때문입니다. 그렇지 않은 경우에는 디스크의 고급 포맷 이점을 최대한 활용하고 싶습니다.
답변1
기괴한 숫자 65535로 여전히 혼란스러워하는 경우를 대비해. 저도 최근에 이 질문 때문에 혼란스러워요. 나는 답변을 검색하여 다음과 같은 답변을 발견했습니다.http://gparted-forum.surf4.info/viewtopic.php?id=17839
간단히 말해서, HD가 USB-Sata 어댑터를 사용하여 PC에 연결된 경우 Optimal_io_size가 유효하지 않을 수 있습니다.
해결책은 이 숫자를 무시하고 1MiB 경계 제안을 따르는 것입니다.