DISKPART: Phân vùng chính GPT


0

Đối với lệnh GPT Microsoft DISKPART

 list partition  

định nghĩa một số phân vùng Primaryvà tương tự như tiện ích Quản lý đĩa.
Nhưng các phân vùng chính / mở rộng cũ của lược đồ MBR chính xác là những gì mà tiêu chuẩn GPT dự định sẽ đi qua.

Ví dụ: phân vùng Windows, trong thuật ngữ Microsoft được định nghĩa là Phân vùng dữ liệu cơ bản (GUID EBD0A0A2-B9E5-4433-87C0-68B6B72699C7) được DISKPART báo cáo là Primary. Trớ trêu thay, tiện ích đối tác Linux fdiskbáo cáo chính xác nó làMicrosoft basic data

Nếu chuyển đổi đĩa từ cơ bản sang động, BDP được báo cáo chính xác với loại Dynamic Data.

Tôi đã tìm kiếm một tài liệu tham khảo về thuật ngữ DISKPART, liên quan đến list partitionchỉ huy, không có may mắn. Ngoài ra, trong Triển khai Microsoft GPT hiện tại , không có gợi ý nào về việc này.

Chính xác thì loại phân vùng này là gì? Có phải nó chỉ là một tên thân thiện cho các phân vùng BDP?

Biên tập

Đối với ai đó không rõ những gì tôi đang hỏi. Xin lỗi vì điều đó. Hãy thử với điều này:

list partLệnh Diskpart nhãn một số phân vùng GPT là Type: Primary. Vì không có định nghĩa về các phân vùng chính trong thông số GPT, bạn có thể vui lòng cung cấp:

  1. Một định nghĩa về phân vùng chính GPT?
  2. Một ví dụ về phân vùng GPT không chính?

Mỗi phân vùng GPT tương đương với phân vùng chính MBR. Tôi không nghĩ thuật ngữ này là khó hiểu.
Daniel B

Làm thế nào để bạn có được phân vùng đó? Trong GPT HDD của tôi, nó có ESPMSR làm phân vùng hệ thống.
Biswapriyo

@DanielB: Tiểu học, mở rộng với các phân vùng logic liên quan được tất cả thay thế bằng phân vùng GUID mới, vì vậy lựa chọn không phải là quá tự động. BTW, nếu mỗi GUID = phân vùng chính thì Typecột trở nên vô giá trị. Có lẽ chỉ BCD = chính, nhưng tôi không tìm thấy một tài liệu tham khảo rõ ràng, do đó bài đăng.
antonio

@Biswa: Bố cục Win10 mặc định là System-MSR-Windows-Recovery, sử dụng diskparttên loại: System-Reserved-Primary-Recovery, và đây là những gì tôi nhận được list part. Tôi không hiểu ý bạn là "phân vùng hệ thống". Về mặt thông tin, tất cả chúng đều là các phân vùng hệ thống bắt buộc, chính thức (thông số kỹ thuật của UEFI và MS) chỉ có ESP.
antonio

1
Tôi không phải là một chuyên gia về diskpartcụ thể, nhưng sự nghi ngờ của tôi là nó, giống như partedtrong Linux, chỉ đơn giản là áp dụng tên "chính" cho tất cả các phân vùng GPT. Có nguy cơ phát huy tiếng còi của riêng tôi, nếu bạn muốn thực sự hiểu những gì đang xảy ra với đĩa GPT của mình, bạn nên sử dụng công cụ GPT fdisk ( gdisk) của tôi , được thiết kế từ đầu để sử dụng trên các đĩa GPT. Nó cho bạn thấy cấu trúc dữ liệu GPT mà không lọc chúng qua "ống kính MBR". (Nó sử dụng các ký hiệu mã loại tốc ký, nhưng bạn có thể xem và sử dụng mã GUID mã loại thực nếu cần.)
Rod Smith

Câu trả lời:


1

Thuật ngữ có thể trở nên khó hiểu bởi vì một số trong đó là vấn đề thực hành được chấp nhận hơn bất kỳ điều gì được xác định trong các tài liệu tiêu chuẩn chính thức và bởi vì mọi người thường sử dụng sai thuật ngữ. Cũng có sự khác biệt trong cách mọi người đề cập đến mọi thứ trong các vòng tròn khác nhau. Chẳng hạn, người dùng Windows thường gọi các phân vùng là "ổ đĩa", trong khi trong Linux, thuật ngữ "ổ đĩa" thường dùng để chỉ một đĩa cứng vật lý và trong macOS, thuật ngữ "âm lượng" thường được sử dụng cho các phân vùng. Nó giống như câu châm ngôn về tiếng Anh và tiếng Anh Mỹ: Chúng ta bị chia rẽ bởi ngôn ngữ chung.

Trong mọi trường hợp, các công cụ phân vùng cũ hơn được thiết kế cho MBR và sau đó được điều chỉnh cho GPT thường áp dụng thuật ngữ "chính" cho tất cả các phân vùng GPT. Như bạn đề xuất, điều này là vô nghĩa và tồi tệ nhất có thể gây nhầm lẫn, nhưng nguyên nhân dường như là do cấu trúc dữ liệu và / hoặc giao diện người dùng của chương trình khăng khăng đòi phải có nhãn "chính", "mở rộng" hoặc "logic" áp dụng và cái phù hợp nhất với phân vùng GPT là "chính", do đó, cái phù hợp nhất được hiển thị.

Điều này khác với mã loại của phân vùng. Theo MBR, đây là giá trị 1 byte, thường (nhưng không phải luôn luôn) được trình bày dưới dạng thập lục phân, chẳng hạn như 0x07 cho NTFS (hoặc HPFS) hoặc 0x0c cho FAT-32 LBA. Trong GPT, mã loại là giá trị GUID 16 byte, chẳng hạn như EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 cho phân vùng "dữ liệu cơ bản" của Windows (phân vùng FAT hoặc NTFS bình thường) hoặc C12A7328-F81F 00A0C93EC93B cho phân vùng hệ thống EFI (ESP). Các mã loại GPT này rất khó hiểu và khó nhớ đối với con người, vì vậy hầu hết các công cụ đều không trình bày rõ ràng hoặc trình bày chúng bằng cách ánh xạ chúng thành tên hoặc mã ghi nhớ. Tuy nhiên, các ánh xạ này có xu hướng là duy nhất cho các chương trình cụ thể, vì vậy cách thức Chương trình A trình bày chúng có thể khác với những gì Chương trình B thực hiện. Cũng lưu ý rằng ánh xạ từ mã loại MBR sang GPT không phải là 1: 1. Thỉnh thoảng có ' một ánh xạ khá rõ ràng (chẳng hạn như 0x83 của MBR, dành cho các hệ thống tập tin Linux, ánh xạ sạch tới 0FC63DAF-8483-4772-8E79-3D69D8477DE4 trong GPT); nhưng các thời điểm khác có thể không có tương đương trong một sơ đồ bảng phân vùng hoặc khác (chẳng hạn như 21686148-6449-6E6F-744E-656564454649, dành cho Phân vùng khởi động BIOS, không có mã tương đương MBR) hoặc một mã trong một hệ thống có thể ánh xạ tới nhiều mã trong một mã khác (chẳng hạn như EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 của GPT hoặc phân vùng dữ liệu cơ bản của Windows, ánh xạ tới nhiều mã loại MBR).


Cảm ơn bạn. Điều khiến tôi bực mình là họ không đưa ra bất kỳ lời giải thích nào về primaryloại thuật ngữ ở diskpartcon người. Để chắc chắn nó được sử dụng để gắn nhãn Phân vùng dữ liệu cơ bản ( EBD0A0A2-B9E5-4433-87C0-68B6B72699C7), nhưng dường như không ai biết liệu đây có phải là trường hợp duy nhất có thể.
antonio

1
@antonio bạn có thể "dùng thử và xem" bằng cách sử dụng set id=trong phần đĩa; hoặc thậm chí chỉ cần kiểm tra bất kỳ đĩa nào có cài đặt linux
Tom Yan

0

Bạn chỉ đơn giản là làm một tương tự sai. Các phân vùng trong bảng phân vùng MBR cũng có các loại phân vùng, nhưng chúng không phải là chính / mở rộng / logic mà là:

https://en.m.wikipedia.org/wiki/Partition_type#List_of_partition_IDs

Nó chỉ nằm trong bảng phân vùng MBR, loại ở dạng ID đơn byte (đôi khi được gọi là mã) trong khi trong GPT, loại này ở dạng GUID.

Trường được điền "chính" chỉ vì không có điểm nào để tạo một thuật ngữ khác cho phân vùng trong GPT. Bạn có thể lập luận rằng Microsoft có thể để trống trường nhưng tốt, đó không phải là phong cách của họ, vì họ có thể sợ rằng người dùng sẽ hoảng sợ khi thấy trường đó bị bỏ trống.


Các phân vùng IMHO, GUID thay thế chính / mở rộng / logic không phải là một sự tương tự mà là một thực tế và nó có liên quan đến điểm đặt tên của chính lược đồ GPT. Tuy nhiên, quan điểm của tôi là không thảo luận về các lựa chọn tiếp thị, chỉ hiểu phân vùng chính của GPT là gì , vì nó không được xác định ở bất cứ đâu. Bạn không giải thích lý do tại sao một số trường 'chứa đầy "chính" và một số thì không. Bạn có thể vui lòng thêm một chỉnh sửa cho điều này?
antonio

@antonio Câu hỏi của bạn gần như không hợp lệ, vì ở một mức độ nào đó không có vấn đề gì GPT primary partitionvì với GPT chỉ có một cách để có các mục phân vùng. Đối với những gì chính xác Type: Primaryđề cập đến trong phần đĩa cho một đĩa GPT, tôi đoán là bất kỳ GUID không đặc biệt (trong mắt Windows). Tôi vẫn chưa xác nhận mặc dù (nhưng thực sự tôi sẽ không kiểm tra; ý tôi là tại sao?)
Tom Yan

@antonio Ngay cả chính Microsoft cũng không cho nhiều thứ chết tiệt như thế này. Gần đây tôi đã đọc một cái gì đó như thế này trong Cuộc thi giới thiệu MCSA từ Microsoft Press: Windows versions prior to 2008 use the correct terminology in the Disk Management snap-in. The menus enable you to create partitions on basic disks and volumes on dynamic disks. Windows Server 2012 R2 uses the term volume for both disk types and enables you to create any of the available volume types, whether the disk is basic or dynamic.Vì vậy, về cơ bản họ đang nói "vâng không đúng nhưng chúng tôi không quan tâm"
Tom Yan

@antonio Tôi nghĩ rằng thậm chí có khả năng đĩapart sẽ có logic như thế này cho trường Loại: Nói đĩa MBR; nếu nó là một phân vùng chính với mã loại ef, hiển thị system; nếu nó là một phân vùng chính với bất kỳ mã loại nào khác, hãy hiển thị primary; nếu nó là một phân vùng hợp lý, hiển thị logical.
Tom Yan

Chỉ cần làm rõ: khi tôi yêu cầu giải thích cho tôi "định nghĩa về phân vùng chính GPT", tôi viết chính xác điều này bởi vì Diskpart sử dụng thuật ngữ cho các đĩa GPT, trong khi với tôi là một loại vô nghĩa. Đối với những gì bạn viết thêm, ý tưởng sử dụng 'Chính' là một thuật ngữ còn lại, khi không có gì tốt hơn, là một lời giải thích hợp lý, nhưng vẫn khá kỳ lạ thay mặt MS, vì chính họ đã đặt ra một thuật ngữ cụ thể (và do đó tốt hơn) : "Phân vùng dữ liệu cơ bản". Bây giờ Linux fdisk, partedvv sử dụng biệt ngữ MS và họ thì không.
antonio

0

Cho đến nay, phân vùng chính GPT ở đây là:

Hãy tưởng tượng một bảng phân vùng. Nó không giống như MBR và GPT khác nhau về mọi mặt và không có bất kỳ điểm tương đồng nào. Họ vẫn là bàn. Tôi thực sự thích gọi lược đồ phân vùng MBR là lược đồ phân vùng MSDOS (như các nhà phát triển GParted) nhưng đó là vấn đề ưu tiên.

Đối với sự khác biệt giữa MSDOS và GPT, họ chỉ đơn giản là có cấu trúc dữ liệu khác nhau. Họ vẫn có phân vùng chính; MSDOS không cho phép nhiều hơn bốn phân vùng chính và các đĩa có kích thước + 2TB do cách thức cấu trúc. GPT cho phép những điều này mặc dù. Về mặt lý thuyết, nó có thể có số lượng phân vùng gần như không giới hạn (ít nhất là cho mục đích sử dụng của chúng tôi) (giới hạn ở 128 trên Windows, vẫn còn nhiều hơn so với những gì người dùng trung bình có thể sử dụng). Phân vùng chính GPT có cấu trúc gần như giống với phân vùng chính MSDOS; tuy nhiên trong GPT chúng được GUIDs nhắc đến; MSDOS sử dụng mã loại phân vùng thập lục phân một byte như \ Ox83 (Linux) để chỉ các phân vùng của nó.

Đó chỉ là vấn đề được coi là chính và những gì được coi là mở rộng / logic. Về mặt lý thuyết GPT có thể có các phân vùng hợp lý và mở rộng, nếu nó được xác định. Các phân vùng mở rộng chỉ đơn giản là các thùng chứa, và không nhất thiết là các phân vùng. Các phân vùng logic có các cấu trúc khác nhau để chúng có thể phù hợp với sơ đồ phân vùng MSDOS.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.