Почему проверка диска Ext4 намного быстрее, чем NTFS?

У меня сегодня была ситуация, когда я перезагружал свой компьютер, и он сказал, что мне нужно проверить диск на предмет целостности. Примерно через 10 минут (при завершении «1%») я сдался и решил дать ему поработать, когда я вернусь домой.

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

Итак, как Ext4 выполняет проверку диска так быстро? Есть ли огромный прорыв в этом после выхода NTFS (~ 10 лет назад)?

Примечание. Диск NTFS составляет ~ 300 ГБ, а диск Ext4 - ~ 500 ГБ. Оба наполовину полны.

Существует две основные причины разницы в производительности и две возможные причины. Во-первых, основные причины:

Увеличение производительности ext4 по сравнению с NTFS

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

Что касается того, почему ext4 на самом деле работает лучше, чем NTFS, то это можно объяснить множеством причин. Например, ext4 напрямую поддерживает отложенное размещение. Опять же, прирост производительности зависит строго от используемого вами оборудования (и в некоторых случаях может быть полностью сведен на нет).

Уменьшенные требования проверки файловой системы

Файловая система ext4 также способна выполнять более быстрые проверки файловой системы, чем другие эквивалентные файловые системы журналирования (например, NTFS). Согласно странице Википедии:

В ext4 нераспределенные группы блоков и разделы таблицы inode помечаются как таковые. Это позволяет e2fsck полностью пропустить их при проверке и значительно сокращает время проверки файловой системы, поддерживаемой ext4. Эта функция реализована в версии 2.6.24 ядра Linux.

А теперь две возможные причины:

Сами файловые системы проверяют утилиты

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

Фрагментация диска

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

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

Он (ext4) может все еще стать фрагментированным, но гораздо менее, и не обязательно таким образом, который сильно влияет на производительность чтения / записи, как в NTFS. В NTFS данные записываются в первые открытые блоки по пути головы.

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

Кроме того, почему серверы обычно не используют его, поскольку на сервере, где данные постоянно записываются и читаются с диска 24/7, происходит более интенсивный ввод-вывод.

Кроме того, я не уверен, но если chkdskпроверяет целостность каждого файла (что я считаю, и это и fsckделает), то это также будет медленнее по сравнению с тем, что я только что описал о фрагментации в NTFS.

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

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

Я не знаю, почему ваша файловая система ext4 проверяла себя один раз в неделю, но, вероятно, (надеюсь) это произошло не из-за сопоставимого кризиса, который повторялся еженедельно. Вероятно, это была просто обычная проверка работоспособности, а не полная проверка согласованности.