Когда пользователь программы не скопирует большой файл на те же окна физического диска, выполните следующий алгоритм:

1. Read a piece of data from disk.
2. Write a piece of data to disk.
3. Do points 1. and 2. until whole file is not written fully.

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

Это все очевидно. Так можно ли настроить файловую систему Windows, чтобы сначала скопировать большой файл на диск "кеша", а затем скопировать его обратно в оригинал, когда файловая система получит команду копирования на том же физическом диске?

1 ответ1

0

Нет, это невозможно без изменения системного кода.

Кроме того, я думаю, что вы переоцениваете потери времени, связанные со сканированием и поиском из исходного физического адресного пространства и целевого физического доступа на диске.

если только система не испытывает острую нехватку ОЗУ, то, как вы говорите, "кусок", который вы читаете, является довольно большим, во время которого произошло только одно сканирование / поиск. Остальное - последовательное чтение. Эти данные отправляются на контроллер ввода-вывода, а затем на системную шину, помещаются в буфер в ОЗУ, а затем в модуль ввода-вывода ЦП для обработки. это продолжается до тех пор, пока буфер не будет очищен, а затем процессор дает команду записать данные на диск. В этот момент мы получаем другое сканирование / поиск, чтобы найти адресное пространство назначения, и начинаем последовательную запись.

поэтому, вообще говоря, время последовательного ввода-вывода READ/WRITE будет уменьшать время произвольного доступа для переключения местоположений. Чем больше показание "части", тем меньше времени всей операции используется для изменения положения головок.

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

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

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


Изменить: Что касается того, что поможет вам, рассмотрите возможность получения небольших SSD (возможно, 32 ГБ) и использовать его для кэширования ввода-вывода. Windows заполнит его автоматически, так как у него есть время и возможность, и чем больше файлов вы кешируете, тем меньше времени вы тратите на чтение с диска (хотя чем больше кеш, тем больше требуется управление кешем).

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

или, что лучше всего, если вам не нужна огромная емкость, получите SSD и решите проблему!

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