GPT 또는 MBR?

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

UEFI 및 GPT

디스크에 GPT 디스크 레이블을 쓰는 데 UEFI가 필요하지 않으며, 충분히 똑똑하다면 UEFI가 아닌 ROM에서 GPT 디스크 레이블을 사용하여 디스크를 부팅하는 것을 상상할 수 있습니다. 아직 이 작업을 수행하지 않았습니다). 이것GPT에 관한 Wikipedia 기사이에 대한 간접적인 정보가 있습니다.

영역

이는 종종 간과되지만,하다변화를 만들고 아마도 큰 변화를 가져올 수도 있습니다. 이는 회전하지 않는 대용량 저장소의 문제가 아니지만 수년간 디스크의 문제였습니다. 기하학 및 물리학과 관련된 이유로 디스크 처리량은 디스크 시작 부분 근처에서 가장 높습니다. 처리량은 지역별로 분류되며 한 지역에서 다른 지역으로 이동하면 속도가 감소합니다. 이는 가장 빠른 속도가 필요한 파티션을 디스크 시작 부분 근처에 유지해야 함을 의미합니다. 이 차이는 디스크의 처음 몇 기가바이트에서 매우 두드러집니다.

유닉스 디스크 파티션

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

• 모든 계란을 한 바구니에 담지 않습니다. 파일 시스템이 손상된 경우 백업에서 복원하면 수명이 정상으로 돌아갑니다. 만약에모두파일 시스템이 손상되고, 가동 중지 시간이 길어지고, 문제가 더 많아지고, 짜증이 더 많이 나게 됩니다.
• 성능상의 이유로 각 파일 시스템을 다르게 조정할 수 있습니다. MailDir을 저장하는 파일 시스템에는 여러 디렉터리에 수십만 개의 작은 파일이 포함될 수 있습니다. 비디오 파일이 저장되는 파일 시스템에는 수십 개의 대용량 파일이 있습니다. 최적화할 수 있습니다.
• 파일 시스템의 공간을 예약하고 다른 사용자가 사용할 수 없는 경우 특정 사용자가 이를 사용하도록 허용할 수 있습니다. 루트 사용자는 일반적으로 파일 시스템의 5%를 예약합니다. 여러 파일 시스템의 경우 이를 조정할 수 있습니다. 예를 들어 메일 풀 파일 시스템은 메일 사용자에게 공간을 할당할 수 있습니다.
• 하나의 파일 시스템이 하나의 백업 미디어에 적합하도록 백업 전략을 단순화하고 있습니다. 이는 백업 전략 및 소프트웨어에 따라 다릅니다.
• 예를 들어, 별도의 파일 시스템을 사용하면 /home단일 컴퓨터에 여러 개의 *nix 운영 체제를 보유하고 혼란 없이 이들 간에 파일을 공유할 수 있습니다.
• 시스템 제한 사항을 해결할 수 있습니다. 예를 들어, 과거에는 일부 디스크가 디스크 시작 부분에서 너무 멀리 있는 디스크 블록에서 부팅할 수 없었기 때문에 /boot디스크의 첫 번째 블록을 차지할 만큼 작은 파일 시스템을 만들었습니다.
• 속도를 최적화할 수 있습니다. 중요한 파일 시스템을 디스크의 가장 빠른 영역에 배치하십시오.
• 시작 속도: 20G 파일 시스템은 fsck1900G 파일 시스템보다 빠릅니다. 점검 기간을 현명하게 선택하면 작업을 fsck분산시킬 수 있습니다 .fsck

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

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

파일 시스템 솔루션

누구나 자신이 좋아하는 것이 있습니다. 나는 이것을 계산하기 위해 스프레드시트를 사용했지만, 종이와 구식 필기 도구를 사용하는 경우가 많습니다(얼마나 이상합니까). 만족스러울 때까지 여러 번 반복하고 파티션 구성표를 컴퓨터에 제출하겠습니다. 이것이 더 빠릅니다. 대부분의 Debian 기반 서버에서는 다음 파일 시스템을 분리합니다.

• /(뿌리)
• /boot
• /usr
• /var
• /usr/local
• /tmp
• /home
• 대체 파일 시스템

다른 사람들은 사진을 위한 별도의 파티션(다른 백업 전략 사용), 비디오를 위한 별도의 파티션 등과 같은 다른 별도의 파일 시스템을 가져와야 합니다. 메일 서버는 이메일을 위한 별도의 파티션을 제공합니다. 데이터베이스 서버는 데이터 저장소 및 디스크 상의 일관된 데이터베이스 백업 파일 등을 위해 별도의 파티션을 얻습니다. 그러나 기본 계획은 거의 항상 이렇습니다.

또한 디스크 끝에 백업 파일 시스템을 보관합니다. 저는 주로 (작업 컨벤션) 또는 (나의 컨벤션) mkfs아래에 설치하여 스크래치 공간으로 사용하고 있습니다 . 이 파일 시스템은 새로운 요구 사항을 발견하거나(삭제하고 다른 파일 시스템을 확장하거나 용도를 변경할 수 있음) 스크래치 공간이 많이 필요한 경우에 유용합니다./disk1/disk/tmp

사이징

컴퓨터의 용도에 따라 많은 것이 달라집니다. 많은 경우 매우 작은 크기를 사용할 수 있습니다. 내 제안은 LVM을 사용하고(계속 읽기) 및 /usr각각에 10G를 할당하는 것입니다(또는 자신의 소프트웨어를 컴파일하고 설치할 계획이 없다면 더 작은 크기). 저는 1~2G 정도로 작게 유지합니다. 루트 파일 시스템에 큰 파일 시스템이 모두 포함되어 있지 않다면 작은 것이 나을 수도 있습니다. 현재 상자에는 2G 파티션이 있고 여전히 충분한 공간이 있습니다. 커널 개발자가 아니거나 그것에 대해 전혀 생각하지 않는다면 파일 시스템이 매우 작을 수 있습니다. 최신 컴퓨터와 최신 GRUB 버전은 이를 매우 잘 처리합니다. 원한다면 200-300MB 정도가 적당합니다./var/usr/local/tmp/boot

좌심실 용적

오랫동안 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 디스크에서 파티션은 /home2000 - 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(다른 두 파티션을 아래로 푸시)로 설정합니다.

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

MBR을 사용하든 GPT를 사용하든 LVM을 사용하여 공간을 관리하는 것이 더 유연하고 나중에 변경하기 쉽기 때문에 권장됩니다.

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

파티션 크기에 관한 몇 가지 좋은 경험 법칙은 다음과 같습니다.

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

너무 작은 파일 시스템은 종종 극적인 결과를 초래하는 것으로 나타났습니다. 10GB는 바이너리와 로그 파일로 쉽게 채울 수 있습니다. 디스크 공간은 충분한데, 왜 그렇게 공간을 절약하려고 노력하시나요? 잠시 후에 후회하게 될 것입니다. 모든 디스크 공간을 한 번에 할당하지 말고 필요한 경우 파일 시스템을 이동할 수 있는 공간을 남겨 두십시오. 파일 시스템을 확장하는 것은 쉽지만 축소하는 것은 쉽지 않습니다. LVM2가 당신을 위해 무엇을 할 수 있는지 알아보세요.http://tldp.org/HOWTO/LVM-HOWTO/index.html 앞으로 몇 년 동안 당신을 곤경에 빠뜨릴 나쁜 결정을 내리지 마십시오.