Чи має значення використання великого розміру розподілу диска NTFS для спільного доступу до файлів?


9

Я форматую диск, використовуючи NTFS, який буде присвячений як спільний доступ до файлів для користувачів, щоб центрально зберігати свої файли. Файли, ймовірно, будуть великими (від 10 до 100 мегабайт).

Хтось запропонував, що використання великого розміру одиниці розподілу, ніж 4k за замовчуванням (наприклад, 64k), зробить його ефективнішим. Я думаю, що я розумію основний принцип, який стоїть за ним, але я не впевнений, чи він дійсний на практиці. Чи справді це змінить чи це щось, що може спричинити більше проблем, ніж це вирішує?

Відповіді:


9

Більший розмір виділення підвищить продуктивність при використанні великих файлів. Якщо всі вони будуть великими файлами, можливо, це збільшить розмір виділення до 32 КБ або 64 КБ.

Майте на увазі, що чим більше розмір одиниці розподілу, тим більше місця на диску буде витрачено. Це справедливо незалежно від розмірів файлів, що зберігаються на томі. Якщо розмір одиниці розподілу становить 64 К, а ви збережете файл 50 К, 14 К буде витрачено даремно. Якщо ви збережете файл 800K, він буде розділений на 13 фрагментів, але 13-й фрагмент матиме лише 32K даних, що призводить до 32K витраченого дискового простору.

Ресурс для настройки продуктивності накопичувачів NTFS можна знайти тут: http://www.windowsdevcenter.com/pub/a/windows/2005/02/08/NTFS_Hacks.html

Удачі, будь-які подальші питання не соромтеся задавати.

Ліма


Просто пам’ятайте, що це призведе до того, що файли будуть використовувати більше місця на диску (він округлятиме розміри файлів до найближчого повного блоку), тож якщо на диску на диску є проблема, або якщо також буде менше файлів, вам слід уважно поставитися до цього.
Кетрін Макіннес

1
Абсолютно правильно зауважувати, що "файли [будуть] використовувати більше місця на диску", однак не точно орієнтуватися на те, чи будуть файли менших розмірів, а на тому, скільки файлів закінчиться об'єм. Оскільки кожен файл округлюється до найближчого розміру блоку, незалежно від загального розміру файлу, саме велика кількість файлів може призвести до великої кількості витраченого простору.
Я кажу, відновіть Моніку

1
Щоб додати до коментаря @ Twisty: очікуваний витрачений простір = очікуваний # файлів * розмір одиниці розподілу / 2. Отже, якщо я вибираю розмір одиниці розподілу 64k (65,536 байт), і мої файли є величезними, тому у мене всього близько 3000, Я можу розраховувати витратити 3000 * 65,536 / 2 = 98 304 000 байт, або приблизно 98 mb. Цей відхід відомий як внутрішня фрагментація (спасибі, потрібні класи CS).
Джейк

5

Встановлення розміру блоку розподілу може підвищити ефективність доступу до великих файлів, однак навряд чи це помітно поліпшить роботу мережевого файлового файлу, оскільки інші вузькі місця будуть унеможливлювати будь-яку локальну вигоду.

На що слід звернути увагу:

  • файли займуть більше місця, тому якщо у вас багато невеликих файлів, це буде проблемою
  • доступ до невеликих файлів може бути повільнішим, оскільки система одночасно зчитує цілі блоки (тому читання 64Kb для файлу 1Kb, якщо ви використовуєте блоки 64Kb), хоча залежно від поведінки дисків наперед читання, це може бути не помітно.
  • Ви можете виявити, що це насправді шкодить продуктивності, коли шаблон доступу є випадковим і / або існує багато одночасних процесів доступу до ресурсу по мережі

Моя кишка говорить про те, що ви не помітили б великої користі (або шкоди) продуктивності, мудрої у випадках, коли потрібно використовувати, а моя кишка досить велика, тому я не схилюсь з цим сперечатися, тому я би дотримувався менших розмірів кластерів для ефективності використання простору .


0

Я думаю, що загальна ідея полягає в тому, що більший = кращі показники за рахунок місця на диску.

В Інтернеті лунає звук, що зміна розміру за замовчуванням призведе до помилок або помилок кодуваних дискових утиліт, тож ви можете пам’ятати про це, якщо не плануєте робити резервні копії ;-)


1
Уникайте нестандартних дискових утиліт, за винятком операцій відновлення після аварій, які неможливо виконати зі стандартними інструментами. Планування не планувати резервні копії - це планування катастрофи.
thecarpy
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.