Вопрос о жестком диске, «искать» и «читать» в ОС Windows

Question

Кто-нибудь знает, когда физически влияет на жесткий диск при вызовах «поиск» и «чтение»?

Если быть более точным, я знаю, что у жесткого диска есть какая-то магнитная игла, которая используется для считывания данных с магнитных пластин. Итак, мой вопрос, когда стрелка перемещается в место считывания?

Перемещается ли он при вызове метода windowsApi «поиск» (независимо от того, было ли выполнено реальное чтение), или «поиск» просто запоминает виртуальный указатель, а физическое движение стрелки выполняется только тогда, когда » читать "метод называется?

Редактировать : Предположим, что данные, запрошенные с жесткого диска, отсутствуют ни в одном из кешей (кеш жесткого диска, Os Cache, Ram и все, что еще это может быть)

Answer 1

Хотел вырвать этот вопрос из вашего поста

Когда стрелка фактически перемещается в место считывания?

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

• Внутренний кеш жесткого диска
• Кэши уровня ОС
• Кэши уровня программы
• Кэш уровня API

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

Answer 2

Предположение в вопросе «Предположим, что данные, запрошенные с жесткого диска, не существует ни в одном из кешей (кеш жесткого диска, Os Cache, Ram и все, что еще это может быть)» трудно предположить и относительно редко. Даже в этом случае существует только слабая связь между операциями ввода-вывода файла пользовательского режима и операциями физического запоминающего устройства.

В различных библиотеках Windows имеется множество функций ввода-вывода в пользовательском режиме. Одними из самых старых являются функции низкоуровневого ввода-вывода библиотеки C . Есть также функции потокового ввода-вывода библиотеки C , классы C ++ iostreams и классы управляемого ввода-вывода . Также есть другие интерфейсы ввода / вывода, которые являются частью других пакетов.

Как правило, все библиотеки ввода-вывода пользовательского режима построены поверх функций ввода-вывода файлов Win32 , включая CreateFile () , SetFilePointer () , ReadFile () и WriteFile () .

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

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

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

Это становится еще сложнее, когда рассматриваются записи. Зачастую записи сопровождаются сбросом, который, как предполагает разработчик приложения, доставит данные до физического носителя. Разработчики часто предполагают, что когда сбрасывающий вызов возвращает успех, данные гарантированно сохраняются на устройстве хранения. Это далеко не так, поскольку устройства и драйверы часто игнорируют скрытые вызовы.

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

Answer 3

Головка жесткого диска (игла) начинает двигаться, и диск начинает вращаться (если он еще не вращается) при операции read. В операции seek нет движения головы или раскрутки.

Обратите внимание, что головка может перемещаться не последовательно над диском, даже если вы read последовательно используете файл, т. Е. read 2-го, 3-го и т. Д. 512-байтового блока может привести к удалению головки далеко, даже если нет вмешивающихся seek с. Частично это связано с тем, что файл фрагментирован в файловой системе или из-за того, что микропрограмма имеет переназначение номеров секторов (т. Е. Логический сектор 5 не находится между логическими секторами 4 и 6) для компенсации ошибок неправильных блоков.