Câu hỏi Tại sao có sự khác biệt lớn giữa "Kích thước" và "Kích thước trên đĩa"?


Như bạn có thể thấy bên dưới, có quá nhiều sự khác biệt giữa Kích thước và Kích thước trên đĩa các trường trong thư mục của tôi. Tại sao vậy?

Screenshot showing 50,875 files in 1,504 folders, 105 MB being 1.43 GB on disk

tôi biết điều đó Kích thước trên đĩa nên nhiều hơn một chút Kích thước vì các đơn vị phân bổ trong Windows, nhưng tại sao lại có nhiều sự khác biệt? Có thể vì số lượng tệp lớn không?

BTW, thư mục này nằm trên thẻ SD của điện thoại Android của tôi. Bên trong này, ứng dụng bản đồ của tôi lưu trữ các bản đồ được lưu trong bộ nhớ cache và ứng dụng nhận bản đồ của nó từ Google Maps.


295
2018-01-20 09:48


gốc


Xin chào thelastblack và chào mừng bạn đến với SuperUser. Tôi đã chỉnh sửa câu hỏi của bạn để xóa phần về chống phân mảnh, vì hai câu trả lời hiện có tập trung vào kích thước / kích thước trên sự khác biệt về đĩa và định dạng Stack Exchange hoạt động tốt nhất khi mỗi câu hỏi được đăng về một điều duy nhất. Bạn chắc chắn có thể hỏi lại rằng đó là một câu hỏi riêng biệt tuy nhiên, mặc dù tôi nghĩ rằng các câu trả lời bạn đã nhận được cho đến nay về câu hỏi này cho thấy chống phân mảnh sẽ không giúp bạn. (Nó cũng thường không tốt trên phương tiện truyền thông trạng thái rắn.) chỉnh sửa câu hỏi của bạn hơn nữa nếu bạn cảm thấy tôi đã thay đổi ý định của bạn theo bất kỳ cách nào. - Michael Kjörling
@ MichaelKjörling Heh, tôi vừa chỉnh sửa trong một cuộc thảo luận nhỏ về phân mảnh (bị phân tâm một chút trước đó) - Bob
@ MichaelKjörling Đừng chỉnh sửa câu hỏi trước để trả lời câu trả lời. Một trong những câu trả lời giải quyết một phần phân mảnh của câu hỏi của OP. Chỉnh sửa của bạn cần được khôi phục để tránh nhầm lẫn. - DanteTheEgregore
@DanteTheEgregore Nếu bạn đang đề cập đến câu trả lời của Bob, thực sự đã được chỉnh sửa để thảo luận về tác động của phân mảnh, sau đó trước khi nhảy súng, vui lòng kiểm tra lịch sử chỉnh sửa và dấu thời gian trên câu trả lời đó và câu hỏi. Tại thời điểm chỉnh sửa của tôi, câu trả lời của Bob không đề cập đến vấn đề phân mảnh. Nếu OP muốn làm như vậy, chỉnh sửa lại trong "sẽ chống phân mảnh các phương tiện truyền thông giúp tôi với điều này?" nên giải quyết bất kỳ sự nhầm lẫn nổi bật nào, mặc dù tôi vẫn cảm thấy được hỏi tốt hơn như một câu hỏi riêng; IMO vấn đề về sự khác biệt giữa hai giá trị không liên quan. - Michael Kjörling
Dường như với tôi như ứng dụng này là nghiêm trọng nặng lập trình - xem xét nộp một báo cáo lỗi. Tôi không phải là một lập trình viên chuyên nghiệp, nhưng tôi đã từng tấn công một cái gì đó tương tự với nhau trong JavaME, và dĩ nhiên một trong những vấn đề tôi phải giải quyết là làm thế nào để lưu trữ tất cả những lát bản đồ nhỏ một cách hiệu quả (lưu trữ và truy cập) trong một container. Tôi đã kết thúc bằng cách sử dụng các tệp nén không nén. - A. Donda


Các câu trả lời:


Tôi sẽ giả định rằng bạn đang sử dụng hệ thống tập tin FAT / FAT32 ở đây, vì bạn đề cập đến đây là một thẻ SD. NTFS và exFAT hoạt động tương tự như các đơn vị phân bổ. Các hệ thống tệp khác có thể khác, nhưng chúng không được hỗ trợ trên Windows.

Nếu bạn có nhiều tệp nhỏ, điều này chắc chắn là có thể. Xem xét điều này:

  • 50.000 tệp.

  • Kích thước cụm 32 kB (đơn vị phân bổ), là kích thước tối đa cho FAT32

Ok, bây giờ tối thiểu không gian thực hiện là 50.000 * 32.000 = 1,6 GB (sử dụng tiền tố SI, không phải nhị phân, để đơn giản hóa toán học). Không gian mà mỗi tệp nhận được trên đĩa luôn là bội số của kích thước đơn vị phân bổ - và ở đây chúng tôi giả sử mỗi tệp thực sự đủ nhỏ để vừa với một đơn vị duy nhất, còn lại một số không gian (lãng phí).

Nếu mỗi tệp tính trung bình 2 kB, bạn sẽ nhận được tổng số khoảng 100 MB - nhưng bạn cũng lãng phí 15x (30 kB cho mỗi tệp) trung bình do kích thước đơn vị phân bổ.


Giải thích sâu

Lý do tại sao điều này xảy ra? Vâng, hệ thống tập tin FAT32 cần phải theo dõi vị trí của từng tập tin được lưu trữ. Nếu nó giữ một danh sách của từng byte đơn, bảng (như sổ địa chỉ) sẽ tăng cùng tốc độ với dữ liệu - và lãng phí rất nhiều không gian. Vì vậy, những gì họ làm là sử dụng "đơn vị phân bổ", còn được gọi là "kích thước cụm". Khối lượng được chia thành các đơn vị phân bổ, và theo như hệ thống tập tin có liên quan, chúng không thể được chia nhỏ - đó là những khối nhỏ nhất mà nó có thể giải quyết. Giống như bạn có một số nhà, nhưng người đưa thư của bạn không quan tâm bạn có bao nhiêu phòng ngủ hoặc những người sống trong họ.

Vậy điều gì sẽ xảy ra nếu bạn có một tập tin rất nhỏ? Vâng, hệ thống tập tin không quan tâm nếu tập tin là 0 kB, 2 kB hoặc thậm chí 15 kB, nó sẽ cung cấp cho nó không gian ít nhất có thể - trong ví dụ trên, đó là 32 kB. Tệp của bạn chỉ sử dụng một lượng nhỏ không gian này và phần còn lại về cơ bản là lãng phí, nhưng vẫn thuộc về tệp - giống như một phòng ngủ bạn bỏ trống.

Tại sao có các kích thước đơn vị phân bổ khác nhau? Vâng, nó trở thành một sự cân bằng giữa việc có một bảng lớn hơn (sổ địa chỉ, ví dụ như John sở hữu một căn nhà tại 123 Fake Street, 124 Fake Street, 666 Satan Lane, vv), hoặc nhiều không gian lãng phí trong mỗi đơn vị (nhà). Nếu bạn có tệp lớn hơn, điều đó có ý nghĩa hơn khi sử dụng đơn vị phân bổ lớn hơn - bởi vì tệp không nhận được đơn vị mới (nhà) cho đến khi tất cả các tệp khác được lấp đầy. Nếu bạn có rất nhiều tập tin nhỏ, tốt, bạn sẽ có một bảng lớn (sổ địa chỉ) anyway như vậy cũng có thể cung cấp cho họ các đơn vị nhỏ (nhà).

Các đơn vị phân bổ lớn, như một quy tắc chung, sẽ lãng phí rất nhiều không gian nếu bạn có nhiều tệp nhỏ. Thường không có lý do chính đáng để vượt quá 4 kB để sử dụng chung.


Phân mảnh?

Đối với phân mảnh, phân mảnh không nên lãng phí không gian theo cách này. Các tệp lớn có thể bị phân mảnh, tức là chia nhỏ thành nhiều đơn vị phân bổ, nhưng mỗi đơn vị phải được điền trước khi đơn vị tiếp theo được bắt đầu. Chống phân mảnh có thể tiết kiệm một chút không gian trong bảng phân bổ, nhưng đây không phải là vấn đề cụ thể của bạn.


Phương pháp khả thi

Như gladiator2345 đề xuất, lựa chọn thực sự duy nhất của bạn vào thời điểm này là sống với nó hoặc định dạng lại với các đơn vị phân bổ nhỏ hơn.

Thẻ của bạn có thể được định dạng trong FAT16, có giới hạn nhỏ hơn về kích thước bảng và do đó yêu cầu đơn vị phân bổ lớn hơn nhiều để giải quyết một ổ đĩa lớn hơn (với giới hạn trên 2 GB với đơn vị phân bổ 32 kB). Nguồn lịch sự của Braiam. Nếu đúng như vậy, bạn sẽ có thể định dạng an toàn dưới dạng FAT32.


299
2018-01-20 09:54



Không gian lãng phí do kích thước phân bổ tối thiểu thực sự được gọi là "phân mảnh nội bộ", vì vậy bạn có thể nói rằng sự phân mảnh là thủ phạm. Nhưng nó vẫn không phải cái gì mà bất kỳ công cụ "chống phân mảnh" nào có thể làm bất cứ điều gì. - hobbs
(Ít kỹ thuật, nó chỉ được gọi là "slack".) - hobbs
Kích thước cụm cũng giới hạn kích thước hệ thống tệp tối đa. Ví dụ: nếu không gian địa chỉ của bạn là 32 bit, bạn có tổng cộng 4,29 tỷ cụm tổng thể có thể. Bây giờ, nếu bạn sử dụng kích thước cụm nhỏ nhất được hỗ trợ bởi NTFS (512 byte), bạn có thể giải quyết tối đa 512 * 2 ^ 32 byte = 2 GiB. Nếu bạn cần một ổ đĩa có thể lưu trữ hơn 2 GiB dữ liệu, bạn phải tăng kích thước cụm. Điều này hoàn toàn độc lập với tệp lớn nhất thực tế mà bạn cố gắng lưu trữ, được cấp cho bạn không thể lưu trữ tệp lớn hơn 2 GiB, ít nhất là vấn đề của bạn. - Andon M. Coleman
4 cụm KiB sẽ cho phép bạn định địa chỉ các tệp có kích thước tối đa 16 TiB, đủ cho tương lai gần. - Andon M. Coleman
Vâng, anh ta có thể nén các tệp nhỏ của mình thành một tệp lớn. - einpoklum


Đây là một trong những tình huống mà việc nén / lưu trữ vào một tệp có thể hữu ích. Gì Bob nói trong câu trả lời là đúng nhưng giải pháp có thể dễ dàng hơn cải cách đĩa như các câu trả lời khác gợi ý. Nếu bạn nén hoặc lưu trữ thư mục (sử dụng zip, tar hoặc bất kỳ phương thức nào khác), hệ thống tệp sẽ thấy rằng bạn có một tệp lớn duy nhất, thay vì một tệp nhỏ hơn. Ngay cả khi không nén bạn sẽ nhận được gần 1,4 GiB của không gian trở lại, bởi vì tất cả những "tệp nhỏ" sẽ được tính là một tệp lớn duy nhất.

Bên trong này, ứng dụng bản đồ của tôi lưu trữ các bản đồ được lưu trong bộ nhớ cache và ứng dụng nhận bản đồ của nó từ Google Maps

Có lẽ bạn nên thảo luận với nhà phát triển để sử dụng kho lưu trữ hoặc cơ sở dữ liệu thay vì nhiều tệp. Điều này có lẽ cũng sẽ giúp để có đĩa ít bị phân mảnh và chắc chắn sẽ tiết kiệm không gian đặc biệt là nếu nó là một ổ đĩa flash NAND. Nếu bạn giải thích tình huống vô lý khi 100MB tải trọng / dữ liệu hữu ích trở thành 1,4GiB, có điều gì đó không ổn với cách dữ liệu được lưu trữ, và các nhà phát triển nên mang lại một giải pháp đẹp hơn.


46
2018-01-20 15:03



> Bên trong này, ứng dụng bản đồ của tôi lưu trữ các bản đồ được lưu trong bộ nhớ cache và ứng dụng nhận bản đồ của nó từ Google Maps. - Thật không may, trong trường hợp này, nén (có hiệu quả là một hệ thống tập tin trên cơ sở một) sẽ yêu cầu hỗ trợ từ ứng dụng bản đồ này. - Bob
@Bob thì giải pháp nên đến từ phía nhà phát triển D: - Braiam
Điều đó hoàn toàn đúng. Tôi nghĩ rằng trong thời gian này, tôi nên thay đổi ứng dụng của mình. - vfsoraki
@Braiam Nó không lừa hệ thống tập tin vào suy nghĩ chỉ có một tập tin; ở đó Là chỉ một tệp. Về lý do tại sao các nhà phát triển không lưu trữ thông tin bộ nhớ cache trong một kho lưu trữ, có thể là do hầu hết các định dạng lưu trữ không được thiết kế để viết ngẫu nhiên nhanh, mà bộ nhớ cache cần. Một lựa chọn tốt hơn có thể là sử dụng một thư viện cơ sở dữ liệu nhẹ như SQLite. - bcrist
Hoàn toàn đúng ..... 1 - arundevma


Trong trường hợp bất kỳ ai đối mặt với vấn đề này, nó có thể hữu ích để biết rằng một lý do khác để thấy sự khác biệt lớn trong kích thước tập tin / không gian trên đĩa là việc sử dụng luồng dữ liệu thay thế (QUẢNG CÁO)

Điều này chỉ áp dụng cho NTFS đối với kiến ​​thức của tôi. ADS được biết đến với mục đích sử dụng hợp pháp và không hợp pháp:

  • để gắn thẻ một tệp được tải xuống từ Internet
  • để lưu trữ siêu dữ liệu (Microsoft muốn bao gồm một số tính năng của Apple OS, như không sử dụng phần mở rộng tệp để xác định loại tệp)
  • để ẩn dữ liệu hoặc mã trong ngữ cảnh của phần mềm độc hại.

ADS đơn giản: bất kỳ tệp NTFS nào cũng có thể chứa nhiều luồng dữ liệu (hiểu "subfiles"). Một là luồng chính, được sử dụng bởi Windows Explorer và các công cụ Windows khác, nó giữ nội dung thông thường của một tệp. Các luồng dữ liệu thay thế có thể chứa thông tin khác, chính xác như luồng chính, nhưng chúng không thể được xử lý trực tiếp bởi các công cụ Windows (cụ thể là Explorer hiển thị kích thước tệp bằng với kích thước của luồng chính, bất kể kích thước của ADS), bạn phải sử dụng các công cụ hoặc mã chuyên biệt để viết, đọc và định vị ADS.

Điểm chính là trong trường hợp có sự khác biệt về kích thước tệp lớn, không bỏ qua khả năng của ADS và phần mềm độc hại ẩn.

Liên kết khác.

Để thử nghiệm một cách an toàn với ADS, hãy thử điều này ở cấp độ DOS / CMD ...

Tạo và sau đó hiển thị nội dung của một tệp trong thư mục gốc của C:

C:\> echo The main data stream> test.txt
C:\> type test.txt

Kết quả:

C:\> The main data stream

Bây giờ thêm một ADS với cùng một phương thức, chỉ cần chỉ rõ tên ADS ngoài tên tệp:

C:\> echo The secret message> test.txt:secret

Bạn vừa ẩn thông báo bí mật trong tệp. Lưu ý rằng kích thước tệp trong Explorer không thay đổi mặc dù chúng tôi đã thêm byte trong "bí mật" của ADS.

Thử hiển thị nội dung ADS:

C:\> type test.txt:secret

Kết quả:

The filename, directory name, or volume label syntax is incorrect.

CMD type không thể hiển thị nội dung của ADS. Thay vào đó, chúng tôi sẽ sử dụng Notepad:

notepad test.txt:secret

Trong Notepad, chúng ta có thể thấy nội dung của ADS:

The secret message

Bạn cũng có thể ẩn một tập tin thực thi đầy đủ trong một ADS của một tập tin văn bản vô tội, và chạy nó bất cứ lúc nào. Sự giàu có không gây hại cho tin tặc :-)


25
2018-01-21 07:37



Tôi không phải là người chiến thắng, công việc của tôi hầu hết được thực hiện trong Linux. Điều này rất hữu ích. Cảm ơn bạn - vfsoraki
Bạn nên sử dụng một công cụ như Luồng từ Sysinternals để kiểm tra việc sử dụng ADS. Ví dụ các tệp được tải xuống trên hệ thống Windows có thể được gắn thẻ với nguồn trong ADS, mặc dù điều này rất nhỏ và không chiếm dung lượng. Nó sẽ không hiển thị trong dir hoặc đầu ra Explorer thông thường. Nó có thể mất khối và làm nặng thêm vấn đề sử dụng đĩa bạn đang điều tra. . - adric


Vấn đề có thể là do kích thước cụm.

Theo Microsoft:

Nếu bạn không sử dụng nén NTFS cho bất kỳ tệp hoặc thư mục nào   chứa trên ổ đĩa, sự khác biệt giữa SIZE và SIZE ON DISK   là không gian lãng phí vì kích thước cụm lớn hơn mức cần thiết. Bạn   nên cố gắng sử dụng kích thước cụm tối ưu để SIZE ON DISK   giá trị càng gần giá trị SIZE càng tốt. Quá nhiều   sự khác biệt giữa SIZE ON DISK và giá trị SIZE là một   chỉ ra rằng kích thước cụm mặc định là quá lớn đối với mức trung bình   kích thước tệp mà bạn đang lưu trữ trên ổ đĩa và phải   giảm. Điều này có thể được thực hiện chỉ bằng cách sao lưu âm lượng và sau đó   định dạng lại ổ đĩa bằng cách sử dụng lệnh định dạng và / a switch   để chỉ định kích thước phân bổ thích hợp: IE: format D: /a:2048   (Ví dụ này sử dụng kích thước cụm 2 KB).

Thử định dạng ổ đĩa của bạn với kích thước cụm nhỏ hơn.


19
2018-01-20 09:57



Điều đó đã được nói, người ta không nên làm cho kích thước cluster ít hơn 4096 byte hoặc chỉ không nhiều số này. Hệ điều hành 32 bit hoạt động với các trang (trong trường hợp không phải PAE) là 4096 byte, do đó việc sử dụng các cụm không nhiều có thể ảnh hưởng tiêu cực đến hiệu năng của hệ thống tệp. Đây là lý do kích thước mặc định được đặt thành 4096 byte. - Ruslan
Để thêm vào những gì @Ruslan nói, các ổ đĩa cứng mới hơn hiện có kích thước sector 4 kB, và nó sẽ tối ưu để căn chỉnh hệ thống tập tin cho các lĩnh vực vật lý và có nhiều kích thước ngành vật lý như kích thước đơn vị phân bổ. - Bob
@ Ruslan Tôi tin rằng bạn có nghĩa là để nói rằng nó phải là một sức mạnh của hai lần 4096. 12288 (3 × 4096) và 20480 (5 × 4096) không phải là lựa chọn tuyệt vời. - Scott


Tôi thấy nhiều người đề xuất định dạng lại ổ đĩa của bạn với kích thước cụm nhỏ hơn. Vì đây là thẻ SD, lưu ý rằng nhiều nhà cung cấp định dạng lại thẻ theo kích thước cụm được đề xuất để phù hợp với kích thước của kích thước cụm của NAND (giữ cả hai đồng bộ hóa là rất quan trọng cho hiệu suất đọc / ghi tối ưu và giảm hao mòn)

Bạn không thể thay đổi kích thước cụm của NAND (đó là thuộc tính vật lý của phần cứng thẻ SD của bạn).

Lần đầu tiên chạy scandisk / chkdsk trên thẻ SD của bạn để đảm bảo vấn đề báo cáo kích thước không nằm trong một hệ thống tệp bị hỏng.

Thứ hai, tôi khuyên bạn nên báo cáo lỗi cho các nhà phát triển Google Map, vì họ là người gây ra lỗi ở đây. Họ nên sử dụng một phương pháp lưu trữ cao cấp. Sửa chữa nó cũng sẽ làm cho ứng dụng chạy nhanh hơn trên nhiều thiết bị do ít hoạt động của trình điều khiển hệ thống tệp và / hoặc tệp.


9
2018-01-21 18:20



Trên thực tế, nó không phải là Google Maps, mà là một ứng dụng khác sử dụng bản đồ của Google. Tôi đã thông báo cho nhà phát triển và chỉ xóa các tệp đó khỏi SD của tôi. - vfsoraki


Đây là một vấn đề chung với nhiều hệ thống tập tin. Có hai yếu tố làm việc ở đây, số lượng tối đa của "khối" một hệ thống tập tin có thể xử lý cho mỗi khối lượng hợp lý và hạn chế vật lý của phương tiện lưu trữ. Chỉ có 1 tệp có thể được cấp phát cho bất kỳ khối nhất định nào (các tệp thường mất nhiều khối khi chúng cần). Vì vậy, một tập tin văn bản với 64 byte thường có thể mất bất cứ điều gì từ 4k đến 32k, tùy thuộc vào kích thước khối của hệ thống tập tin nó nằm trên.

Một cách để suy nghĩ về điều này là suy nghĩ của mỗi khối trong hệ thống tập tin như một hộp, và hệ thống tập tin như một căn phòng. Tất cả các ô của bạn đều có cùng kích thước và bạn cố gắng vừa vặn với nhiều thứ trong phòng. Nếu bạn phù hợp với tất cả trong với nhiều phòng còn lại, bạn phải có được hộp lớn hơn để căn phòng được làm đầy hoàn toàn với hộp.

Một trong những quy tắc để đưa mọi thứ vào trong hộp là bạn không thể đặt hai thứ không liên quan vào một hộp. Họ phải là một phần của cùng một tài liệu. Vì vậy, nếu tôi đã gõ lên một trang văn bản, nó sẽ có hộp riêng của nó. Nếu văn bản đã gõ của tôi có rất nhiều trang, tôi không thể vừa với tất cả trong một hộp, tôi chỉ cần tìm một hộp khác và tiếp tục đưa các trang vào đó, lặp lại cho đến khi tôi gửi tất cả các trang của mình. Tôi cũng đã viết ra những cái hộp mà tôi đã sử dụng cho tài liệu đó và thứ tự của các hộp để đọc nó theo thứ tự.

Tùy thuộc vào cách tôi sắp xếp các hộp, tôi chỉ có thể có đủ chỗ trong tệp kê khai của tôi cho một số hộp nhất định. Vì vậy, nếu tôi có một căn phòng lớn để lấp đầy, nhưng chỉ một số lượng nhỏ các hộp tôi phải sử dụng các hộp rất lớn để đạt được khả năng phòng.

Vì vậy, trong trường hợp đó tài liệu một trang của tôi sẽ vẫn chiếm một hộp duy nhất, không có gì khác chia sẻ nó.

Tình huống tương tự diễn ra giữa các giải pháp lưu trữ khác nhau. FAT32 chỉ có thể quản lý những gì được coi là một số lượng thấp của "hộp" trên ổ đĩa cứng lớn ngày nay, vì vậy nó kết thúc với rất lớn "hộp" để bù đắp cho điều này.


7
2018-01-20 14:50





Ngoài kích thước cụm, bạn cũng có thể có sự khác biệt do các điều kiện sau:

  • Các tệp nén hoặc mã hóa có thể sử dụng hết dung lượng khác với kích thước tệp hợp lý.
  • Các tệp được liên kết sẽ báo cáo n số lần liên kết gấp lần kích thước của tệp cho kích thước tệp hợp lý, nhưng không gian vật lý được sử dụng thường ít hơn.

6
2018-01-20 17:42



Nói chung, điều đó có thể đúng. Nhưng trong trường hợp của tôi, đơn vị phân bổ cao là vấn đề. - vfsoraki
Yup Tôi chỉ đang cố gắng thêm vào câu trả lời bằng cách đưa ra nhiều lý do có thể cho sự khác biệt. - Archimedes Trajano