LBA và quy mô ngành


11

LBA có luôn chỉ định các cung là 512 byte ngay cả khi ổ đĩa được định dạng với các cung 4K không? Bởi vì tôi đọc rằng bạn nên định dạng các ranh giới phân vùng để các cụm 4K thẳng hàng với các thành phần 4K. Tôi giả sử vấn đề này phát sinh nếu đĩa được định dạng với các cung 4K nhưng LBA chỉ định nó sau mỗi 512 byte. Đây có phải là lý do? Ngoài ra, lý do hình học ổ đĩa logic khác với hình dạng ổ đĩa vật lý - để duy trì khả năng tương thích ngược với các tiêu chuẩn và giới hạn cũ với CHS? Nếu hình học báo cáo ổ đĩa không chính xác, tại sao các phân vùng vẫn cần bắt đầu ở khu vực 63 (nếu đó không còn luôn là hình trụ chính xác)?

Và các cụm được căn chỉnh với sự bắt đầu của phân vùng hoặc bắt đầu của đĩa?

Câu trả lời:


10
  • LBA có luôn chỉ định các cung là 512 byte ngay cả khi ổ đĩa được định dạng với các cung 4K không?

Vâng, rất nhiều mã trên thế giới đã được viết trong thời kỳ thống trị độc quyền của các lĩnh vực 512 byte. Mã này không thể xử lý bất kỳ kích thước cung nào khác, vì vậy phần cứng BIOS / đĩa luôn mô phỏng các cung 512 byte bất kể kích thước cung thực tế. Mặt khác, 95% hệ điều hành hoàn toàn không khởi động từ các đĩa như vậy.

  • Ngoài ra, lý do hình học ổ đĩa logic khác với hình dạng ổ đĩa vật lý - để duy trì khả năng tương thích ngược với các tiêu chuẩn và giới hạn cũ với CHS?

Có ranh giới trong hệ thống địa chỉ CHS. 1 ≤ S 63, 0 ≤ H 255 (và đôi khi 0 ≤ C 1023). Đó là lý do tại sao hình học logic tồn tại và khác với hình học vật lý.

  • Nếu hình học báo cáo ổ đĩa không chính xác, tại sao các phân vùng vẫn cần bắt đầu ở khu vực 63 (nếu đó không còn luôn là hình trụ chính xác)?

Kể từ Windows Vista, FDISKtạo phân vùng đầu tiên trên LBA sector 2048 (căn chỉnh 1M). Nó có thể có bất kỳ tọa độ CHS nào; họ không quan trọng nữa.

Trong Windows XP và các phiên bản trước, phân vùng đầu tiên được tạo trên khu vực CHS (C = 0, H = 1, S = 1) thường ánh xạ tới LBA sector 63 (nếu hình học logic của đĩa này có 63 cung trên mỗi rãnh). Một số ổ flash USB có hình học logic với 32 cung ảo trên mỗi rãnh, vì vậy phân vùng đầu tiên bắt đầu trên LBA sector 32 cho chúng. Trong mọi trường hợp, tất cả những điều này không liên quan gì đến hình học đĩa thực tế, lý do hiệu suất, v.v. - đó là một truyền thống thuần túy, chấm dứt trong Vista / Windows 7.

  • Các cụm được căn chỉnh với sự bắt đầu của phân vùng hoặc bắt đầu của đĩa?

Các cụm luôn được căn chỉnh với sự bắt đầu của phân vùng. Vì vậy, chúng có thể được sắp xếp sai trên đĩa, nếu phân vùng được tạo trong tiền Vista FDISKvà bị phân bổ sai.


6

Bản thân LBA có thể áp dụng cho bất kỳ kích thước khu vực nào, nhưng kích thước khu vực ổ cứng đã là 512 byte kể từ khi PC khởi động, và tất cả phần cứng và phần mềm đã được mã hóa cứng với giả định đó. Vì vậy, thay vì chờ các hệ thống và hệ điều hành mới hỗ trợ các lĩnh vực 4K, ổ đĩa sẽ xuất hiện bên ngoài dưới dạng ổ đĩa 512 byte.

CHS đã chết kể từ khi LBA48 được giới thiệu vào năm 2003. CHS bị giới hạn ở 128 GB, vì vậy mọi ổ đĩa lớn hơn kích thước đó đều không hỗ trợ CHS (hãy xem một ổ đĩa hiện đại; nó sẽ không có giá trị CHS trên nhãn ). Trong trường hợp tất cả các phần cứng và hệ điều hành đã được cập nhật (Windows 98 hỗ trợ thêm cho LBA).

Ngay cả với CHS, các đặc tính ổ đĩa vật lý không khớp với các giá trị CHS. Nghiêm túc mà nói, không có ổ cứng nào có 255 đầu. Bộ điều khiển của ổ đĩa sẽ chuyển đổi bên trong các giá trị CHS thành LBA.

Các phân vùng không phải bắt đầu ở khu vực 63 - đó là một hạn chế cũ của DOS. DOS yêu cầu một phân vùng không phân chia ranh giới hình trụ và CHS có 63 cung cho xi lanh. Microsoft cho đến Windows XP đã quyết định duy trì khả năng tương thích với DOS (có thể khởi động kép Windows 98, ME và XP trên phân vùng FAT32). Cho đến các lĩnh vực 4K, không có vấn đề gì với nó.

Cuối cùng, để trả lời câu hỏi của bạn: các cụm được căn chỉnh với điểm bắt đầu của phân vùng, không phải đĩa. Đó là lý do tại sao điều quan trọng là phân vùng của bạn được căn chỉnh chính xác trên một ranh giới ngành.

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.