5

При копировании большого количества файлов довольно часто используется несколько потоков с RoboCopy (опция /MT [:n]). Может ли это вызвать фрагментацию на целевом диске? Иногда я использую Beyond Compare для копирования файловых структур, чтобы максимально использовать пропускную способность сети / жесткого диска. Это также способ создания нескольких потоков. Могут ли оба из них вызвать фрагментацию?

4 ответа4

2

Если вы не уверены, вы можете просто проверить скопированные файлы, если они фрагментированы, и если да, то в количестве фрагментов.

Для проверки файла вы можете использовать "Contig" от Microsoft/Mark Russinovich, который позволяет проверять фрагментацию с помощью ключа -a

contig -a <filename>

http://technet.microsoft.com/en-us/sysinternals/bb897428.aspx

2

(Не ответ, но, как новый пользователь, кажется, что я не могу напрямую комментировать предыдущие ответы.)

В ответ на music2myear многопоточные копии, которые не распределяют пространство, действительно могут привести к крайней фрагментации.

Сценарий таков: файл A начинает копирование в блок N на диске. Файл B начинает копирование в блок N+1 на диске. fileC начинает копирование в блок N+2 на диске. Файл A нуждается в другом блоке и копирует в N+3. fileB нуждается в другом блоке и копирует в N+4. И так далее ... до тех пор, пока каждый файл не будет полностью фрагментирован без смежных двух блоков. Файл A оказывается в блоках N, N+3, N+5, N+10, N+13, а не в N, N+1, N+2, N+3, N+4.

ОК, это немного экстрим; это вероятно не становится полностью фрагментированным. Но это иллюстрирует проблему с утилитами многопоточного копирования, которые не выделяют пространство. Тем не менее, я только что попробовал robocopy, включенный в Server 2008R2, чтобы скопировать большое количество файлов разных размеров, и это, похоже, не создавало избыточной фрагментации. (Известно, что предыдущие версии robocopy вызывали крайнюю фрагментацию.) Необходимо дополнительное тестирование.

1

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

Любой диск с высокой скоростью чтения / записи и файлами большего или смешанного размера следует регулярно дефрагментировать, если только вы не используете файловую систему, которая предотвращает фрагментацию.

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

0

я видел это:

  • RE-FORMAT E: как FAT32 (формат M: /FS: FAT32 /Q), поэтому на нем ничего нет
  • Список E: (dir / AE :) и на нем ничего нет
  • Скопируйте только один файл из D: в E: ничего не делая до конца
  • Список E: (dir / AE :) и есть только такой файл
  • Смотрите фрагментацию E: и это ужасно, начало файла находится в середине раздела, и это во многих фрагментах (более 10)

Я также пытался с Robocopy и безуспешно, все еще фрагментируйте это.

если я пытаюсь дефрагментировать после копирования, ничего не делается.

Как этого избежать? Я получил это, выполнив несколько дополнительных шагов ... и используя команду XCOPY /J ...

Я получил это, сделав это:

  • RE-FORMAT E: как FAT32 (формат M: /FS: FAT32 /Q), поэтому на нем ничего нет
  • Список E: (dir / AE :) и на нем ничего нет
  • Скопируйте только один файл из D: в E: без выполнения каких-либо действий до конца (XCOPY / JD:\TEMP\TheFile.Расширение E:\AAA), да, одновременно переименовывая его в AAA
  • Переименуйте его обратно в его настоящее имя (REN E:\AAA TheFile.TheExtension)
  • Список E: (dir / AE :) и есть только такой файл
  • Смотрите фрагментацию E: и файл это всего лишь один фрагмент, никакой фрагментации вообще нет

Я пытался с "копировать" и "robocopy" без успеха.

Я пробовал с "XCOPY /J ..." и преуспел !!!

Зачем? я не знаю ... но по крайней мере с "XCOPY /J ..." и работал, когда имя Dest было изменено !!!

Кажется, что Windows делает что-то ненормальное, когда dest name - это нечто особенное.

Чтобы увидеть то, что я упоминаю, просто попробуйте использовать раздел FAT32 4113MB для хранения 4095MB pagefile.sys !!! и попробуйте сделать это только на одном фрагменте !!! нет способа сделать это нормально !!! но, эй, если из консоли вы переформатируете раздел и используете XCOPY /J pagefile.sys E:AAA, а затем переименуете его ... он останется в одном фрагменте !!!

Надеюсь, что это может помочь другим людям!

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .