어떤 이유에서인지 내 VPS(Debian 8 실행)의 첫 번째 파티션은 섹터 63(2048 대신)에 정렬되어 있습니다.
Model: VMware Virtual disk (scsi)
Disk /dev/sda: 314572800s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 63s 79971569s 79971507s primary ext4 boot
2 79971570s 83875364s 3903795s primary linux-swap(v1)
83875365s 314572799s 230697435s Free Space
이제 여유 공간을 할당하기 위해 파티션 크기를 조정하고 싶습니다. 불행히도 fdisk첫 번째 섹터는 2048에서 시작됩니다. 하지만 내가 읽어보니여기fdisk63에서 강제로 부팅하려면 이 명령을 사용하세요 .
fdisk -c=dos -u=cylinders /dev/sda
얼마나 안전합니까? 또한 이 방법은 더 이상 사용되지 않으므로 VPS 성능이 저하됩니까?
답변1
크기를 확장하는 경우 파티션 삭제가 포함되므로 시작하는 번호에 관계없이 파티션을 다시 생성해야 합니다.
그렇지 않으면 인식할 수 없으며 최악의 경우 데이터가 손상될 수 있습니다.
이 VPS가 다른 VM을 생성하기 위한 템플릿이라면 시작 *및* 데이터/섹터를 2048 섹터로 다시 생성/이동하는 수고를 겪을 것입니다.
가상 머신이기 때문에 파티션을 이동하고 싶다면 완전히 이동하지 않고 측면에 파티션을 만들고 데이터를 복사한 후 복사된 파티션으로 부팅합니다. 이것이 가상 머신 사용의 장점입니다. 테스트할 수 있는 공간이 더 많습니다.
추신. 내 개인적인 의견으로는 작은 성능 향상은 63섹터 밖으로 옮길 가치가 없습니다. 조만간 기계가 폐기될 때까지 기다릴 것입니다.
파티션 정렬의 경우:
파티션을 4096바이트 경계에 정렬하려고 합니다. 이런 방식으로 실제 섹터는 기본적으로 가상 섹터와 일치하며 VMWare를 사용하면 하이퍼바이저/VM이 하드웨어에서 더 나은 성능을 얻을 수 있습니다.
잘못 정렬된 파티션으로 인해 성능 문제가 발생할 수 있는 이유를 이해하려면 purestorage.com에서 다음 이미지를 참조하세요.
업계 스토리지 전문가가 작성한 이 백서를 확인하여 무엇이 무엇인지 더 잘 이해하세요.현재 모범 사례:
Microsoft 및 Linux 배포자(예: Red Hat)의 최신 공급업체 지원 운영 체제(OS)에서는 가상 환경의 기본 스토리지 시스템 블록에 파일 시스템 파티션을 맞추기 위해 더 이상 조정이 필요하지 않습니다.
(예: "기본 설정 유지")
그러나 원래 질문에 대한 답변을 계속하기 위해 다음과 같은 몇 가지 링크된 백서가 있습니다.
권장되는 모범 사례는 VMDK 및 LUN의 파티션을 4K 경계에 맞추는 것입니다.
그리고:
각 장치의 출력에서 시작 위치에 섹터 크기(일반적으로 fdisk 출력에서는 512)를 곱하고 4096으로 나눕니다. 결과가 정수(정수)이면 ALIGNED이고, 그렇지 않으면 MISALIGNED입니다.
따라서 섹터 63에서 파티션 생성에 대한 질문을 확인하십시오.
512 * 63 / 4096 = 7.875 => 정렬되지 않음
앞으로도 기본값인 2048을 사용하고 유지할 수 있습니다. 확인 해보자:
512 * 2048 / 4096 = 156 => 정렬
인용하다:
FAQ: VMware vSphere, 기타 가상 환경 및 NetApp 스토리지 시스템에 대한 게스트 가상 머신 파일 시스템 파티션/디스크 정렬
답변2
참고로:
- 기존 512b 섹터 드라이브의 섹터 2048이 첫 번째 섹터입니다.뒤쪽에1MB 표시.
- 섹터 63은 오른쪽 섹터입니다.앞으로32k 마크는 원래 대부분의 하드 디스크 첫 번째 플래터의 첫 번째 트랙의 마지막 섹터에 해당합니다(적어도 디스크 구조가 합리적으로 표준화되기 전까지는).
그렇다면 이것들은 왜 관련이 있습니까?
파티셔닝이 일반적으로 섹터 1에서 시작되지 않는 데에는 몇 가지 이유가 있습니다.
- 부트로더를 위한 공간을 남겨둡니다. MBR 형식은 부트로더용으로 40바이트 남짓을 남깁니다. CP/M과 DOS 시대에는 이 정도이면 충분했지만, 이내 너무 작아졌습니다. 따라서 첫 번째 플래터의 첫 번째 트랙(거의 전체)을 부트로더에 남겨 두는 것이 관례입니다. 예를 들어 MBR 파티션 디스크에서 GRUB를 사용할 때 이는 실제로 필요합니다.
- 여러 방식으로 분할된 디스크를 처리할 때도 중요합니다. 일부 파티션 테이블 형식은 섹터 0에서 시작하지 않습니다. 현대적인 예는 섹터 1에서 시작하여 일반적으로 섹터 31까지 올라가는 GPT입니다. 오래된 예는 클래식 운영 체제가 설치된 Apple 시스템에서 사용되는 파티션 테이블 형식입니다. 이것은 좀 더 틈새적인 사용법이지만 GPT 덕분에 여전히 어느 정도 관련성이 있습니다.
- 실린더 또는 트랙 경계와 같은 하드 드라이브 기하학적 구조의 자연스러운 경계에서 시작하고 끝나도록 파티션을 정렬하면 성능이 향상될 수 있습니다. 섹터 63은 자연스러운 경계에 있으며 대부분의 파일 시스템은 실제로 첫 번째 섹터를 자주 건드리지 않으므로(전혀) 두 번째 섹터를 새 실린더의 시작 부분에 배치하게 되며 일반적으로 위치도 지정됩니다. 일부 오래된 파일 시스템에서 매우 자주 액세스되는 경우가 많은 새 트랙의 시작 부분(일부 다른 파일 시스템에서는 일반적으로 건드리지 않는 ext4 및 BTRFS와 같이 전혀 액세스되지 않음)
포인트 1과 3으로 인해 섹터 63이 마침내 표준이 되었습니다. 그러나 아래에 설명할 이유로 인해 거의 사용되지 않게 되었습니다.
좋아요, 그럼 왜 1MB로 늘어났나요?
이건 좀 까다롭습니다. 실제 명확한 역사적 참고 답변을 본 적이 없습니다.왜이것이 표준이 되기 시작하더라도 1MB를 선택하세요. 그러나 IT에는 다음과 같은 몇 가지 장점이 있습니다.
- 일반적으로 대부분의 결과를 초래하는 섹터 63에서 시작하는 것과는 달리 512b 및 4k 섹터 크기에 대해 올바르게 정렬됩니다.문서파일 시스템 자체가 잘못 정렬되었습니다(FAT12 및 FAT16은 일반적으로 기본적으로 512b 섹터를 사용하여 내부적으로 작동하므로 처음에는 문제가 아니었습니다).
- 많은 네트워크 스토리지 프로토콜은 읽기 및 쓰기의 최대 블록 크기를 1MB로 정의합니다. 이와 같이 파티션을 정렬하면 최종적으로 이러한 블록 프로토콜에 맞게 적절하게 정렬할 수 있으므로 부분 쓰기만 수행하려는 경우 RMW 주기를 수행해야 할 가능성을 피할 수 있습니다.
- 대부분의 최신 SSD에는 512b 또는 4k 섹터가 있지만 실제로는 내부적으로 더 큰 블록을 사용하여 작동합니다. 이제 일반적으로 이러한 블록은 2MB 또는 4MB 블록이지만 많은 이전 블록은 1MB 블록을 사용합니다. 이러한 블록을 적절하게 정렬하면 실제로 일부 SSD의 예상 수명이 크게 향상될 수 있으며 쓰기 성능도 크게 향상될 수 있습니다.
좋습니다. 하지만 원래 질문은 어떻습니까?
위의 내용을 고려하면 기본으로 2048로 변경하면 실제로 가상 머신의 성능이 약간 향상됩니다.
또한 완전히 안전해야 합니다. 이동 후 올바른 위치를 가리키지 않는 파일이 아닌 파일 시스템의 정확한 블록 위치를 참조할 수 있으므로 이동 후 부트로더를 다시 설치하세요.
답변3
- partitions 을 사용하는 경우
fdisk시작 섹터는 2048+입니다. - 를 사용하는 경우
cfdisk초기 설치 후 디스크를 추가할 때 이런 현상이 발생할 수 있으며, 시작 섹터는 63일 수 있습니다.
따라서 디스크가 섹터 63으로 시작하고 파티션 크기를 조정하려면 cfdisk대신 fdisk.
ProxMox에서 가상 디스크를 추가하고 크기를 조정할 때 이 문제가 발생했습니다. 기본적으로 내가 /dev/sda*사용하는 것을 변경해야 하거나 fdisk파티션 크기를 조정해야 하는 경우 /dev/sdb|c|d에는 cfdisk이것을 열심히 배웠습니다.