GPT 또는 MBR?

Question 1

GPT 또는 MBR?

@mgorven이 말했듯이 둘 중 하나는 2TB에서 작동합니다. 2T 디스크에 수십 개의 MBR 디스크 레이블을 배포했는데 제대로 작동합니다. 그것은 정말로 당신의 선택입니다. 지금은 MBR을 선호하지만 곧 바뀔 예정입니다.

UEFI 및 GPT

GPT 디스크 레이블을 디스크에 쓰는 데 UEFI가 필요하지 않으며, 영리하다면 UEFI가 아닌 ROM에서 GPT 디스크 레이블을 사용하여 디스크를 부팅할 수도 있습니다(소금이 필요합니다. 아직 부팅하지 않았습니다). 이것을 했습니다). 그만큼GPT에 관한 Wikipedia 기사이에 대한 간접적인 정보가 있습니다.

구역

사람들은 이것을 종종 무시하지만,하다중요한 역할을 하며 잠재적으로 큰 역할을 합니다. 회전하지 않는 대용량 저장소에서는 문제가 아니지만 수년 동안 디스크에서는 문제가 되어 왔습니다. 기하학 및 물리학과 관련된 이유로 인해 디스크 처리량은 디스크 시작 부분 근처에서 가장 높습니다. 처리량은 영역별로 분류되며 한 영역에서 다른 영역으로 이동하면 속도가 떨어집니다. 이는 속도를 가장 많이 요구하는 파티션을 디스크 시작 부분 근처에 유지해야 함을 의미합니다. 이 차이는 디스크의 처음 몇 기가바이트에서 상당히 두드러집니다.

Unix용 디스크 파티셔닝

다음과 같은 이유로 많은 파일 시스템을 갖고 싶어합니다.

모든 계란을 한 바구니에 담는 것이 아닙니다. 하나의 파일 시스템이 손상되면 백업에서 복원하면 수명이 다시 정상으로 돌아갑니다. 만약에모두의 파일 시스템이 손상되고, 다운타임이 늘어나고, 문제가 발생하고, 짜증이 더 많이 납니다.
성능상의 이유로 각 파일 시스템을 다르게 조정할 수 있습니다. MailDir을 저장하는 파일 시스템에는 몇 개의 디렉터리에 수십만 개의 작은 파일이 있을 수 있습니다. 비디오 파일을 보관하는 파일 시스템에는 수십 개의 거대한 파일이 있습니다. 최적화할 수 있습니다.
파일 시스템의 공간을 예약하고 다른 사용자가 사용할 수 없을 때 특정 사용자가 이를 사용하도록 허용할 수 있습니다. 루트는 일반적으로 파일 시스템 공간의 5%를 예약합니다. 여러 파일 시스템을 사용하면 이를 조정할 수 있습니다(예: 메일 스풀 파일 시스템은 메일 사용자에게 할당된 공간을 가질 수 있습니다).
하나의 파일 시스템을 하나의 백업 매체에 적합하게 만들어 백업 정책을 단순화하고 있습니다. 이는 백업 정책 및 소프트웨어에 따라 다릅니다.
예를 들어 별도의 파일 시스템을 사용하면 /home한 컴퓨터에 여러 개의 *nix 운영 체제를 두고 문제를 일으키지 않고도 이들 간에 파일을 공유할 수 있습니다.
시스템 제한을 해결할 수 있습니다. 예를 들어 과거에는 일부 디스크가 디스크 시작에서 너무 먼 디스크 블록에서 부팅할 수 없었기 때문에 /boot디스크의 첫 번째 블록을 차지할 만큼 작은 파일 시스템을 만들었습니다.
속도를 최적화할 수 있습니다. 가장 빠른 디스크 영역에 중요한 파일 시스템을 배치합니다.
부팅 속도: fsck20G 파일 시스템을 사용하는 것이 1900G 파일 시스템을 사용하는 것보다 빠릅니다 fsck. 검사 기간을 교묘하게 선택하면 실행을 분산시킬 수 있습니다 fsck.

다음과 같은 이유로 너무 많은 파일 시스템을 갖고 싶지 않을 수도 있습니다.

디스크 공간을 양자화하고 있습니다. 디스크에 100G를 저장해야 하는 경우 총 200G의 여유 공간이 있지만 충분한 디스크 공간이 있는 단일 파티션이 없을 수 있습니다.
디스크 레이블의 기능에 따라 제한됩니다. 많은 Unices는 디스크 레이블에 8개의 파티션/슬라이스만 넣을 수 있으며 그 중 하나는 예약되어 있습니다. MBR은 이 점에서 크게 제한되지 않으며 GPT는 필요한 것보다 훨씬 많은 128개의 파티션을 허용합니다.
파일 시스템이 너무 많으면 생성하고 관리하는 데 방해가 될 수 있습니다.
파일 저장 요구 사항은 그다지 다양하지 않습니다.

파일 시스템 구성표

누구나 자신이 좋아하는 것이 있습니다. 나는 그것들을 계산하기 위해 스프레드시트를 사용하곤 했지만, 종이 한 장과 구식 필기 도구 중 하나를 사용하는 경우가 많습니다(정말 독특합니다). 만족스러울 때까지 여러 번의 반복을 거친 후 파티션 구성표를 컴퓨터에 커밋합니다. 이 방법이 더 빠릅니다. 대부분의 Debian 기반 서버에서는 다음 파일 시스템을 분리하여 유지합니다.

/(뿌리)
/boot
/usr
/var
/usr/local
/tmp
/home
예비 파일 시스템

추가 요구 사항에는 사진을 위한 별도의 파티션(백업 정책이 다름), 비디오를 위한 별도의 파티션 등과 같은 별도의 파일 시스템이 필요합니다. 메일 서버는 이메일을 위한 별도의 파티션을 갖습니다. 데이터베이스 서버는 데이터 저장소와 디스크 상의 일관된 데이터베이스 백업 파일 등을 위해 별도의 파티션을 갖게 됩니다. 그러나 기본 계획은 거의 항상 이것이다.

또한 디스크 끝에 예비 파일 시스템을 보관합니다. 나는 mkfs그것을 스크래치 공간으로 사용하며 종종 /disk1(작업 규칙) 또는 /disk/tmp(나의 규칙) 아래에 장착됩니다. 이 파일 시스템은 새로운 요구 사항을 발견하거나(삭제하고 다른 파일 시스템을 확장하거나 용도를 변경할 수 있음) 스크래치 공간이 많이 필요한 경우에 유용합니다.

사이징

이는 주로 컴퓨터를 어떤 용도로 사용할 것인지에 따라 달라집니다. 아주 작은 크기로도 많은 일을 처리할 수 있습니다. 내 제안은 LVM을 사용하고(계속 읽어보세요) 각각 10G를 /usr, /var및 /usr/local(자신의 소프트웨어를 컴파일하고 설치할 계획이 없다면 더 작게) 할당하는 것입니다. 나는 /tmp1~2G 정도로 작게 유지합니다. 루트 파일 시스템에 큰 파일 시스템이 모두 없으면 작을 수도 있습니다. 현재 상자에는 2G 파티션이 있고 공간이 많이 남아 있습니다. /boot커널 개발자가 아니거나 완전히 생략된 경우 파일 시스템은 매우 작을 수 있습니다 . 최신 컴퓨터와 GRUB 최신 버전은 이를 잘 처리할 수 있습니다. 원한다면 200~300메가 정도가 적당합니다.

LVM

오랫동안 LVM이 아닌 시스템을 배포하지 않았습니다. 당신이 얻는 유연성은 짧은 학습 곡선의 가치가 있습니다. LVM을 사용하면 마음을 바꿀 수 있는 여지가 훨씬 더 많아지고 파일 시스템도 함께 성장할 수 있습니다. 정말 추천합니다.

예시 구성표

파티션 1: 스왑 공간(디스크의 시작)
파티션 2: 'fs'라고 불리는 볼륨 그룹이 있는 LVM 물리 볼륨.
- 볼륨 fs-root: ~2G.
- 볼륨 fs-usr: ~10G.
- 볼륨 fs-var: ~10G.
- 볼륨 fs-local( 의 약자 /usr/local): ~5~10G.
- 볼륨 fs-tmp: ~2G.
- 볼륨 fs-home: 남은 공간에서 ~30G를 뺀 것입니다.
- 볼륨 fs-spare: 여유 공간: ~30G.

8G 스왑 공간이 있는 2T 디스크에서 파티션 /home은 2000 - 8 - 2 - 10 - 10 - 10 - 2 - 30 = 1928G입니다.

하나 이상의 다른 볼륨에 더 많은 공간이 필요한 경우 예비 30G 파티션이 유용합니다. LVM 볼륨(및 ext{2,3,4} 파일 시스템)의 크기를 조정하는 것은 쉽습니다.

별도의 은 없으며 /boot모든 부트스트랩 인프라(커널 및 initrd)는 다음과 같습니다.내부에LVM. 이로 인해 어떤 사람들은 불안해하지만 저는 한 번도 문제를 겪은 적이 없습니다. GRUB는 LVM 물리 볼륨 내부를 잘 볼 수 있습니다. 불안하시면 /boot200M 정도 따로 만들어 두세요. 파티션 2(LVM PV 파티션 3 만들기) 또는 파티션 1(다른 두 개 아래로 밀어넣기)로 만듭니다.

Answer

GPT 또는 MBR?

@mgorven이 말했듯이 둘 중 하나는 2TB에서 작동합니다. 2T 디스크에 수십 개의 MBR 디스크 레이블을 배포했는데 제대로 작동합니다. 그것은 정말로 당신의 선택입니다. 지금은 MBR을 선호하지만 곧 바뀔 예정입니다.

UEFI 및 GPT

GPT 디스크 레이블을 디스크에 쓰는 데 UEFI가 필요하지 않으며, 영리하다면 UEFI가 아닌 ROM에서 GPT 디스크 레이블을 사용하여 디스크를 부팅할 수도 있습니다(소금이 필요합니다. 아직 부팅하지 않았습니다). 이것을 했습니다). 그만큼GPT에 관한 Wikipedia 기사이에 대한 간접적인 정보가 있습니다.

구역

사람들은 이것을 종종 무시하지만,하다중요한 역할을 하며 잠재적으로 큰 역할을 합니다. 회전하지 않는 대용량 저장소에서는 문제가 아니지만 수년 동안 디스크에서는 문제가 되어 왔습니다. 기하학 및 물리학과 관련된 이유로 인해 디스크 처리량은 디스크 시작 부분 근처에서 가장 높습니다. 처리량은 영역별로 분류되며 한 영역에서 다른 영역으로 이동하면 속도가 떨어집니다. 이는 속도를 가장 많이 요구하는 파티션을 디스크 시작 부분 근처에 유지해야 함을 의미합니다. 이 차이는 디스크의 처음 몇 기가바이트에서 상당히 두드러집니다.

Unix용 디스크 파티셔닝

다음과 같은 이유로 많은 파일 시스템을 갖고 싶어합니다.

모든 계란을 한 바구니에 담는 것이 아닙니다. 하나의 파일 시스템이 손상되면 백업에서 복원하면 수명이 다시 정상으로 돌아갑니다. 만약에모두의 파일 시스템이 손상되고, 다운타임이 늘어나고, 문제가 발생하고, 짜증이 더 많이 납니다.
성능상의 이유로 각 파일 시스템을 다르게 조정할 수 있습니다. MailDir을 저장하는 파일 시스템에는 몇 개의 디렉터리에 수십만 개의 작은 파일이 있을 수 있습니다. 비디오 파일을 보관하는 파일 시스템에는 수십 개의 거대한 파일이 있습니다. 최적화할 수 있습니다.
파일 시스템의 공간을 예약하고 다른 사용자가 사용할 수 없을 때 특정 사용자가 이를 사용하도록 허용할 수 있습니다. 루트는 일반적으로 파일 시스템 공간의 5%를 예약합니다. 여러 파일 시스템을 사용하면 이를 조정할 수 있습니다(예: 메일 스풀 파일 시스템은 메일 사용자에게 할당된 공간을 가질 수 있습니다).
하나의 파일 시스템을 하나의 백업 매체에 적합하게 만들어 백업 정책을 단순화하고 있습니다. 이는 백업 정책 및 소프트웨어에 따라 다릅니다.
예를 들어 별도의 파일 시스템을 사용하면 /home한 컴퓨터에 여러 개의 *nix 운영 체제를 두고 문제를 일으키지 않고도 이들 간에 파일을 공유할 수 있습니다.
시스템 제한을 해결할 수 있습니다. 예를 들어 과거에는 일부 디스크가 디스크 시작에서 너무 먼 디스크 블록에서 부팅할 수 없었기 때문에 /boot디스크의 첫 번째 블록을 차지할 만큼 작은 파일 시스템을 만들었습니다.
속도를 최적화할 수 있습니다. 가장 빠른 디스크 영역에 중요한 파일 시스템을 배치합니다.
부팅 속도: fsck20G 파일 시스템을 사용하는 것이 1900G 파일 시스템을 사용하는 것보다 빠릅니다 fsck. 검사 기간을 교묘하게 선택하면 실행을 분산시킬 수 있습니다 fsck.

다음과 같은 이유로 너무 많은 파일 시스템을 갖고 싶지 않을 수도 있습니다.

디스크 공간을 양자화하고 있습니다. 디스크에 100G를 저장해야 하는 경우 총 200G의 여유 공간이 있지만 충분한 디스크 공간이 있는 단일 파티션이 없을 수 있습니다.
디스크 레이블의 기능에 따라 제한됩니다. 많은 Unices는 디스크 레이블에 8개의 파티션/슬라이스만 넣을 수 있으며 그 중 하나는 예약되어 있습니다. MBR은 이 점에서 크게 제한되지 않으며 GPT는 필요한 것보다 훨씬 많은 128개의 파티션을 허용합니다.
파일 시스템이 너무 많으면 생성하고 관리하는 데 방해가 될 수 있습니다.
파일 저장 요구 사항은 그다지 다양하지 않습니다.

파일 시스템 구성표

누구나 자신이 좋아하는 것이 있습니다. 나는 그것들을 계산하기 위해 스프레드시트를 사용하곤 했지만, 종이 한 장과 구식 필기 도구 중 하나를 사용하는 경우가 많습니다(정말 독특합니다). 만족스러울 때까지 여러 번의 반복을 거친 후 파티션 구성표를 컴퓨터에 커밋합니다. 이 방법이 더 빠릅니다. 대부분의 Debian 기반 서버에서는 다음 파일 시스템을 분리하여 유지합니다.

/(뿌리)
/boot
/usr
/var
/usr/local
/tmp
/home
예비 파일 시스템

추가 요구 사항에는 사진을 위한 별도의 파티션(백업 정책이 다름), 비디오를 위한 별도의 파티션 등과 같은 별도의 파일 시스템이 필요합니다. 메일 서버는 이메일을 위한 별도의 파티션을 갖습니다. 데이터베이스 서버는 데이터 저장소와 디스크 상의 일관된 데이터베이스 백업 파일 등을 위해 별도의 파티션을 갖게 됩니다. 그러나 기본 계획은 거의 항상 이것이다.

또한 디스크 끝에 예비 파일 시스템을 보관합니다. 나는 mkfs그것을 스크래치 공간으로 사용하며 종종 /disk1(작업 규칙) 또는 /disk/tmp(나의 규칙) 아래에 장착됩니다. 이 파일 시스템은 새로운 요구 사항을 발견하거나(삭제하고 다른 파일 시스템을 확장하거나 용도를 변경할 수 있음) 스크래치 공간이 많이 필요한 경우에 유용합니다.

사이징

이는 주로 컴퓨터를 어떤 용도로 사용할 것인지에 따라 달라집니다. 아주 작은 크기로도 많은 일을 처리할 수 있습니다. 내 제안은 LVM을 사용하고(계속 읽어보세요) 각각 10G를 /usr, /var및 /usr/local(자신의 소프트웨어를 컴파일하고 설치할 계획이 없다면 더 작게) 할당하는 것입니다. 나는 /tmp1~2G 정도로 작게 유지합니다. 루트 파일 시스템에 큰 파일 시스템이 모두 없으면 작을 수도 있습니다. 현재 상자에는 2G 파티션이 있고 공간이 많이 남아 있습니다. /boot커널 개발자가 아니거나 완전히 생략된 경우 파일 시스템은 매우 작을 수 있습니다 . 최신 컴퓨터와 GRUB 최신 버전은 이를 잘 처리할 수 있습니다. 원한다면 200~300메가 정도가 적당합니다.

LVM

오랫동안 LVM이 아닌 시스템을 배포하지 않았습니다. 당신이 얻는 유연성은 짧은 학습 곡선의 가치가 있습니다. LVM을 사용하면 마음을 바꿀 수 있는 여지가 훨씬 더 많아지고 파일 시스템도 함께 성장할 수 있습니다. 정말 추천합니다.

예시 구성표

파티션 1: 스왑 공간(디스크의 시작)
파티션 2: 'fs'라고 불리는 볼륨 그룹이 있는 LVM 물리 볼륨.
- 볼륨 fs-root: ~2G.
- 볼륨 fs-usr: ~10G.
- 볼륨 fs-var: ~10G.
- 볼륨 fs-local( 의 약자 /usr/local): ~5~10G.
- 볼륨 fs-tmp: ~2G.
- 볼륨 fs-home: 남은 공간에서 ~30G를 뺀 것입니다.
- 볼륨 fs-spare: 여유 공간: ~30G.

8G 스왑 공간이 있는 2T 디스크에서 파티션 /home은 2000 - 8 - 2 - 10 - 10 - 10 - 2 - 30 = 1928G입니다.

하나 이상의 다른 볼륨에 더 많은 공간이 필요한 경우 예비 30G 파티션이 유용합니다. LVM 볼륨(및 ext{2,3,4} 파일 시스템)의 크기를 조정하는 것은 쉽습니다.

별도의 은 없으며 /boot모든 부트스트랩 인프라(커널 및 initrd)는 다음과 같습니다.내부에LVM. 이로 인해 어떤 사람들은 불안해하지만 저는 한 번도 문제를 겪은 적이 없습니다. GRUB는 LVM 물리 볼륨 내부를 잘 볼 수 있습니다. 불안하시면 /boot200M 정도 따로 만들어 두세요. 파티션 2(LVM PV 파티션 3 만들기) 또는 파티션 1(다른 두 개 아래로 밀어넣기)로 만듭니다.

Question 2

MBR은 2TB 드라이브에서는 제대로 작동하지만 더 큰 드라이브에서는 작동하지 않습니다. 하지만 사용하려는 모든 운영 체제가 MBR을 지원한다면 MBR을 사용하든 GPT를 사용하든 상관없습니다. BIOS는 GPT 드라이브에서 부팅하기 위해 EFI를 지원할 필요가 없습니다.

MBR을 사용하든 GPT를 사용하든 관계없이 LVM을 사용하여 공간을 관리하는 것이 좋습니다. LVM이 훨씬 더 유연하고 나중에 변경하기 쉽기 때문입니다.

Answer

MBR은 2TB 드라이브에서는 제대로 작동하지만 더 큰 드라이브에서는 작동하지 않습니다. 하지만 사용하려는 모든 운영 체제가 MBR을 지원한다면 MBR을 사용하든 GPT를 사용하든 상관없습니다. BIOS는 GPT 드라이브에서 부팅하기 위해 EFI를 지원할 필요가 없습니다.

MBR을 사용하든 GPT를 사용하든 관계없이 LVM을 사용하여 공간을 관리하는 것이 좋습니다. LVM이 훨씬 더 유연하고 나중에 변경하기 쉽기 때문입니다.

Question 3

나는 당신이 이것을 조금 지나치게 생각하고 있다고 생각합니다. GPT와 MBR은 여러 운영 체제를 설치하거나 드라이브를 다른 컴퓨터로 이동하려는 경우에만 중요합니다. MBR을 사용할 수 있다면 계속 사용하는 것이 좋습니다. 특히 LVM(MBR에 없는 많은 기능을 허용함)을 사용하는 경우 더욱 그렇습니다.

파티션 크기와 관련하여 다음은 몇 가지 좋은 경험 법칙입니다.

작은 파티션은 실제로 얼마나 많이 사용할지 미리 알 수 없기 때문에 성가실 수 있습니다.
큰 파티션은 구축하고 확인하는 데 오랜 시간이 걸리기 때문에 성가실 수 있습니다. 또한 파일 시스템의 "마모"는 사용량에 따라 증가하는 경향이 있습니다. 모든 것을 하나의 파티션에 넣는 것은 이러한 축적이 더 빨리 일어난다는 것을 의미합니다. 그만한 가치가 있는 무엇이든.

Answer

나는 당신이 이것을 조금 지나치게 생각하고 있다고 생각합니다. GPT와 MBR은 여러 운영 체제를 설치하거나 드라이브를 다른 컴퓨터로 이동하려는 경우에만 중요합니다. MBR을 사용할 수 있다면 계속 사용하는 것이 좋습니다. 특히 LVM(MBR에 없는 많은 기능을 허용함)을 사용하는 경우 더욱 그렇습니다.

파티션 크기와 관련하여 다음은 몇 가지 좋은 경험 법칙입니다.

작은 파티션은 실제로 얼마나 많이 사용할지 미리 알 수 없기 때문에 성가실 수 있습니다.
큰 파티션은 구축하고 확인하는 데 오랜 시간이 걸리기 때문에 성가실 수 있습니다. 또한 파일 시스템의 "마모"는 사용량에 따라 증가하는 경향이 있습니다. 모든 것을 하나의 파티션에 넣는 것은 이러한 축적이 더 빨리 일어난다는 것을 의미합니다. 그만한 가치가 있는 무엇이든.

Question 4

너무 작은 파일 시스템은 대개 드라마입니다. 10GB는 바이너리와 로그 파일로 쉽게 채울 수 있습니다. 디스크 공간이 풍부한데 왜 공간을 절약하기 위해 그렇게 열심히 노력합니까? 조금 있으면 후회하게 될 거예요. 디스크 공간을 한꺼번에 할당하지 말고 필요할 때 파일 시스템을 이동할 수 있도록 공간을 남겨 두십시오. 파일 시스템을 확장하는 것은 쉽지만 축소하는 것은 쉽지 않습니다. LVM2가 당신을 위해 무엇을 할 수 있는지 확인해 보세요.http://tldp.org/HOWTO/LVM-HOWTO/index.html 앞으로 몇 년 동안 당신을 묶어두는 나쁜 결정을 내리지 마십시오.

Answer

너무 작은 파일 시스템은 대개 드라마입니다. 10GB는 바이너리와 로그 파일로 쉽게 채울 수 있습니다. 디스크 공간이 풍부한데 왜 공간을 절약하기 위해 그렇게 열심히 노력합니까? 조금 있으면 후회하게 될 거예요. 디스크 공간을 한꺼번에 할당하지 말고 필요할 때 파일 시스템을 이동할 수 있도록 공간을 남겨 두십시오. 파일 시스템을 확장하는 것은 쉽지만 축소하는 것은 쉽지 않습니다. LVM2가 당신을 위해 무엇을 할 수 있는지 확인해 보세요.http://tldp.org/HOWTO/LVM-HOWTO/index.html 앞으로 몇 년 동안 당신을 묶어두는 나쁜 결정을 내리지 마십시오.

GPT 또는 MBR?

답변1

GPT 또는 MBR?

UEFI 및 GPT

구역

Unix용 디스크 파티셔닝

파일 시스템 구성표

사이징

LVM

예시 구성표

답변2

답변3

답변4

관련 정보