Tại sao FAT16 không thể lưu trữ nhiều hơn 2 GB?

Tất cả các trang web tôi tìm kiếm thông tin trên FAT16 chỉ tuyên bố rằng nó không thể phân bổ hơn 2 GB. ĐƯỢC. Tuyệt quá. Tôi tin bạn. Nhưng làm thế nào để bạn đi đến kết luận đó (ngoài việc chỉ kiểm tra nó)?

Có một số loại công thức người ta có thể sử dụng để xác định hệ thống FAT16 có thể giữ được bao nhiêu không?

file-storage allocation

— Sản phẩm Sango
nguồn

Có một lý do tại sao FAT16 có tên "16". :-)

— Eric Lippert

@EricLippert, công bằng mà nói, kết nối giữa 16 và 2 GiB đó không rõ ràng ngay lập tức mà không biết cách thức hoạt động của FS.

— Joey

Tôi không tin chắc 100% rằng câu hỏi này thực sự thuộc chủ đề cho trang web này. Có lẽ nó nên được chuyển đến retrocomputing.stackexchange.com?

— Jules

Điều đáng chú ý là giới hạn 2GB là một giới hạn thực tế về cách MS-DOS và Windows đầu xử lý FAT16. Về mặt khái niệm có thể vượt quá 2GB, nhưng không phải theo cách tương thích với Microsoft.

— phyrfox

@ LưuViênPhúc Nhận xét đúng. Tôi đã nói "MS-DOS và Windows đầu tiên." Các hệ thống hiện đại có thể sử dụng hơn 2GB trong FAT16. Ví dụ, phân vùng 4GB16 sẽ không hoạt động trong các hệ thống MS-DOS / Win3.1 cũ. Và nhiều nguồn tin cho rằng 2GB là giới hạn là do chúng được viết khi giới hạn đó là thực tế hoặc thời gian ngay sau đó, nơi bạn được khuyên không nên vì các hệ thống hơi cũ không thể xử lý được. Các hệ thống sau này có thể xử lý tốt, nhưng giới hạn 2GB là quy tắc ngón tay cái trước khoảng 2000 hoặc hơn, và vài năm sau đó, trích dẫn các giới hạn cũ, lỗi thời.

— phyrfox

Câu trả lời:

FAT16 sử dụng 16 bit để xác định các cụm. Do đó, có tối đa 65536 cụm trước khi bạn hết số nhận dạng và một số số nhận dạng được dành riêng cho việc sử dụng không phải tệp. Mỗi tệp chiếm ít nhất một cụm. Các cụm lớn hơn làm tăng phân bổ tối thiểu cho mỗi tệp, tăng chi phí cho các tệp nhỏ.

Kích thước cụm sau đó cho bạn biết khối lượng nhận dạng tối đa. Đối với cụm 32KiB, đó là 32 * 1024 * 65536 B = 2GiB.

Bạn có thể tăng kích thước cụm vô thời hạn, bằng cách tăng kích thước của các cung trên đĩa, nhưng bạn vẫn bị giới hạn số lượng tệp tối đa. Bạn cũng sẽ gặp vấn đề với phần mềm giả định kích thước cung mặc định (512B)

Tại thời điểm có khối lượng vật lý ~ 2GiB có sẵn, bộ xử lý và HĐH là 32 bit, do đó, chuyển sang FAT32 là một lựa chọn hợp lý, cho phép nhiều tệp hơn trong các cụm nhỏ

— Caleth
nguồn

"nhưng tăng chi phí cho các tệp nhỏ" Không chắc mọi người có rõ ràng không, vì tôi không chắc mọi người sẽ hiểu ý nghĩa của "chi phí" trong ngữ cảnh này. Tôi nghĩ một ví dụ sẽ giúp: "Ví dụ: một tệp có một ký tự trong đó chiếm 1 cụm trên đĩa, hầu hết trong số đó hoàn toàn bị lãng phí. Kích thước cụm lớn hơn có nghĩa là lãng phí hơn."

— Reginald Blue

Một số lưu ý làm rõ: 32KiB là kích thước cụm tối đa cho các phiên bản khác nhau của DOS và Windows, nhưng gia đình Windows NT đã hỗ trợ kích thước cụm lớn hơn kể từ NT 4.0 (và do đó, các phiên bản Windows dành cho người tiêu dùng kể từ XP cũng đã hỗ trợ nó, vì chúng ' lại dựa trên nhân NT). Điều này cho phép kích thước lên tới 16GiB, mặc dù do không hiệu quả như được lưu ý trong câu trả lời nên điều này không có khả năng hữu ích. Bạn có thể sử dụng một cách hợp lý một hệ thống như vậy nếu bạn muốn lưu trữ các tệp chủ yếu lớn, đặc biệt nếu chúng có nhiều kích thước cụm 256KiB mà bạn sẽ phải sử dụng ...

— Jules

... nhưng sau đó bạn có thể đạt đến giới hạn tiếp theo, đây là một vấn đề đối với cả FAT16 và FAT32: kích thước tệp tối đa bị giới hạn ở mức 1 byte ngắn 4GiB bởi thực tế là chỉ có 4 byte được phân bổ để lưu trữ trong đó mục thư mục. OTOH, nếu bạn có nhu cầu lưu trữ một số lượng lớn tệp có kích cỡ khoảng 256KiB lên đến 2GiB với kích cỡ hai cấp và tổng kích thước <16GiB, thì FAT16 có khả năng là định dạng hiệu quả nhất đối với chúng.

— Jules

@Jules: Chỉ có khả năng. Hãy nhớ rằng có một cụm trên mỗi cụm. Các hệ thống tệp cho phép lưu trữ chạy hiệu quả hơn nếu có ít phân mảnh.

— Ded repeatator

Thực tế đã có một số biến thể của "FAT16" trong nhiều năm với các giới hạn khác nhau nhưng hãy xem xét phiên bản tồn tại từ "compaq DOS 3.31" cho đến windows 95.

Khối lượng FAT được chia thành các cụm. Mỗi cụm được tạo thành từ một sức mạnh của hai số lĩnh vực. Số lượng cung trên mỗi cụm trên FAT16 được lưu trữ dưới dạng số có chữ ký 8 bit. Vì vậy, các lĩnh vực tối đa có thể trên mỗi cụm là 64.

Số cụm được lưu trữ dưới dạng giá trị không dấu 16 bit. Giới hạn tổng số cụm thành 65536. Nhân số đó với các lĩnh vực tối đa trên mỗi cụm và bạn nhận được giới hạn là 4194304 lĩnh vực.

Kích thước cung (logic) của ổ đĩa cứng là 512 byte. Nhân số đó với giới hạn số lượng các lĩnh vực được đề cập ở trên và bạn nhận được giới hạn 2GiB của mình. Trong pricipl, một phương tiện có kích thước cung lớn hơn có thể hỗ trợ âm lượng FAT16 lớn hơn nhưng tôi không nghĩ điều này xảy ra trong thực tế.

Windows NT đã thay đổi cách hiểu của trường "sector trên cụm" thành 8 bit không dấu. Điều này cho phép phân vùng 4GiB FAT16 với các cung 512 byte (và về mặt lý thuyết là lớn hơn trên các ổ đĩa có các cung lớn hơn). AIUI windows 98 đã thêm hỗ trợ để đọc và ghi các phân vùng như vậy nhưng nó không thể tạo ra chúng và các tiện ích đĩa không thể sửa chữa chúng.

Chắc chắn có thể thực hiện các điều chỉnh tương đối nhỏ đối với định dạng hệ thống tập tin để hỗ trợ các cụm lớn hơn và do đó khối lượng lớn hơn. Tuy nhiên, MS đã quyết định lựa chọn triệt để hơn là chuyển sang chỉ mục cụm 32 bit với windows 95 OSR2 tạo ra FAT32.

Tôi tin rằng lý do cho lựa chọn triệt để hơn là hiệu quả không gian. Với các tập tin điển hình tại thời điểm các cụm 32kiB đã khá lãng phí và những cụm lớn hơn thậm chí sẽ di chuyển như vậy.

— Peter Green
nguồn

Tôi đã phải suy nghĩ kỹ về "các lĩnh vực tối đa có thể có trên mỗi cụm là 64", cho đến khi tôi nhận được nó: 64 thực sự là công suất lớn nhất mà bạn có thể biểu thị trong một byte đã ký: 128 không thể là ký hiệu tích cực tối đa giá trị byte là 127.

— Ralf Kleberhoff

@RalfKleberhoff Điều đó tự nhiên dẫn đến một câu hỏi tiếp theo: mặc dù: nếu bạn đang lưu trữ sức mạnh của hai, tại sao lại lưu trữ số đó chứ không phải là số mũ trên cả hai?

— Daniel Wagner

@DanielWagner Tôi hoàn toàn đồng ý. Đặc biệt là vào thời điểm đó khi FAT16 được tạo ra, dịch chuyển chắc chắn là một hoạt động rẻ hơn so với nhân. Nhưng có lẽ họ chỉ vui khi chạy nó, và không thiết kế phần mềm trong nhiều thập kỷ trong tương lai ...

— Ralf Kleberhoff