Việc sử dụng kích thước phân bổ đĩa NTFS lớn cho chia sẻ tệp có tạo ra sự khác biệt không?


9

Tôi đang định dạng ổ đĩa bằng NTFS, sẽ được dành riêng dưới dạng chia sẻ tệp để người dùng lưu trữ tập trung vào tệp của họ. Các tệp có thể sẽ lớn (10 đến 100 megabyte).

Có người đề xuất rằng sử dụng kích thước đơn vị phân bổ lớn hơn 4k mặc định (ví dụ 64k) sẽ giúp nó hoạt động tốt hơn. Tôi nghĩ rằng tôi hiểu nguyên tắc cơ bản đằng sau nó, nhưng tôi không chắc liệu nó có hợp lệ trong thực tế hay không. Điều này sẽ thực sự tạo ra sự khác biệt hay đây là điều có thể gây ra nhiều vấn đề hơn nó giải quyết?

Câu trả lời:


9

Kích thước phân bổ lớn hơn sẽ tăng hiệu suất khi sử dụng các tệp lớn hơn. Nếu tất cả chúng sẽ là các tệp lớn thì có thể trả tiền để tăng kích thước phân bổ lên 32KB hoặc 64KB.

Xin lưu ý rằng kích thước đơn vị phân bổ càng lớn, dung lượng đĩa sẽ bị lãng phí càng nhiều. Điều này đúng bất kể kích thước của các tệp được lưu trữ trên ổ đĩa. Nếu kích thước đơn vị phân bổ là 64K và bạn lưu tệp 50K, 14K sẽ bị lãng phí. Nếu bạn lưu một tệp 800K, nó sẽ được chia thành 13 khối, nhưng khối thứ 13 sẽ chỉ có 32K dữ liệu dẫn đến 32K không gian đĩa bị lãng phí.

Có thể tìm thấy tài nguyên để điều chỉnh hiệu suất của các ổ đĩa NTFS tại đây: http://www.windowsdevcenter.com/pub/a/windows/2005/02/08/NTFS_Hacks.html

Chúc may mắn, bất kỳ câu hỏi thêm đừng ngần ngại hỏi.

Lima


Chỉ cần nhớ rằng nó sẽ khiến các tệp sử dụng nhiều dung lượng đĩa hơn (nó sẽ làm tròn kích thước tệp lên đến khối đầy đủ gần nhất), vì vậy nếu không gian đĩa là một vấn đề hoặc nếu cũng sẽ có các tệp nhỏ hơn, bạn nên xem xét cẩn thận.
Catherine MacInnes

1
Hoàn toàn chính xác khi quan sát rằng "các tệp [sẽ] sử dụng nhiều dung lượng đĩa hơn" tuy nhiên sẽ không chính xác để tập trung vào việc liệu sẽ có các tệp nhỏ hơn hay không, mà là có bao nhiêu tệp sẽ kết thúc trên ổ đĩa. Vì mỗi tệp được làm tròn đến kích thước khối gần nhất, bất kể tổng kích thước của tệp đó, đó là số lượng tệp tuyệt đối có thể dẫn đến một lượng lớn không gian bị lãng phí.
Tôi nói Phục hồi lại

1
Để thêm vào nhận xét của @ Twisty: dung lượng bị lãng phí dự kiến ​​= số tệp dự kiến ​​* kích thước đơn vị phân bổ / 2. Vì vậy, nếu tôi chọn kích thước đơn vị phân bổ là 64k (65.536 byte) và các tệp của tôi đều rất lớn nên tôi chỉ có khoảng 3.000, Tôi có thể mong đợi lãng phí 3.000 * 65.536 / 2 = 98.304.000 byte, hoặc khoảng 98 mb. Chất thải này được gọi là phân mảnh nội bộ (cảm ơn, các lớp CS bắt buộc).
Jake

5

Đặt kích thước khối phân bổ có thể cải thiện hiệu suất để truy cập các tệp lớn, nhưng không có khả năng cải thiện hiệu suất của tệp mạng đáng chú ý vì các tắc nghẽn khác sẽ làm giảm bất kỳ lợi ích cục bộ nào.

Có một số điều cần chú ý:

  • các tệp sẽ chiếm nhiều dung lượng hơn, vì vậy nếu bạn có nhiều tệp nhỏ thì đây sẽ là một vấn đề
  • truy cập các tệp nhỏ có thể chậm hơn vì hệ thống đọc toàn bộ các khối tại một thời điểm (vì vậy đọc 64Kb cho tệp 1Kb nếu bạn sử dụng các khối 64Kb), mặc dù tùy thuộc vào hành vi đọc trước của các ổ đĩa của bạn, điều này có thể không đáng chú ý
  • bạn có thể thấy rằng nó thực sự gây hại cho hiệu suất khi mẫu truy cập rất ngẫu nhiên và / hoặc có nhiều quy trình đồng thời truy cập tài nguyên qua mạng

Ruột của tôi gợi ý rằng bạn sẽ không nhận thấy nhiều lợi ích (hoặc gây bất lợi) hiệu quả trong các trường hợp phải sử dụng và ruột của tôi khá lớn nên tôi không có xu hướng tranh luận với nó, vì vậy tôi sẽ sử dụng kích thước cụm nhỏ hơn để đạt hiệu quả sử dụng không gian .


0

Tôi nghĩ rằng ý tưởng chung là lớn hơn = hiệu suất tốt hơn với chi phí không gian đĩa.

Có một tin đồn trực tuyến rằng việc thay đổi kích thước mặc định sẽ khiến các tiện ích đĩa bị mã hóa bị lỗi hoặc không thành công, vì vậy bạn có thể muốn ghi nhớ điều đó nếu bạn dự định không lên kế hoạch sao lưu ;-)


1
Tránh xa các tiện ích đĩa không chuẩn, ngoại trừ trong các hoạt động khắc phục thảm họa không thể thực hiện được bằng các công cụ tiêu chuẩn. Kế hoạch không lên kế hoạch cho các bản sao lưu là lập kế hoạch cho thảm họa.
thecarpy
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.