Продолжение исследования быстродействия файловых систем при помощи Intel NASPT


В статье, посвященной утилите Intel NAS Performance Toolkit, мы не ограничились только лишь описанием входящих в нее шаблонов тестов, но и провели небольшое практическое исследование. «Подопытным» являлся USB-ВЖД, а предметом тестирования — вопрос, какую из трех доступных файловых систем имеет смысл выбрать в данном случае: FAT32, exFAT или NTFS. Вопрос весьма насущный, тем более что, как выяснилось, быстродействие файловых операций может различаться в зависимости от использованной ФС чуть ли не на порядок.

Однако полученные результаты в точности касались лишь одного случая — USB-накопители на базе винчестеров. А это достаточно большой класс носителей данных, но далеко не единственный. В ВЖД могут использоваться также eSATA или FireWire (первая — все чаще, вторая — все реже), логика работы которых в той или иной степени отличается от USB. Кроме того, свои особенности могут быть и у флэш-накопителей, более популярных, нежели ВЖД. Впрочем, заранее можно предположить, что тут уже картина существенным образом различаться не будет (с поправкой на отличные скоростные показатели самого носителя, конечно), однако и это желательно проверить, дабы окончательно убедиться в справедливости или несправедливости априорных предположений. Кроме того, современные файловые системы предоставляют пользователю определенную гибкость в выборе размера кластера, что не может не сказываться на производительности дисковых операций. Но флэшдрайвами и прочими вопросами мы займемся в следующий раз, а сегодня закончим с винчестерами.

Помогать нам будет недавно изученный Seagate FreeAgent | Xtreme. Главный плюс этой модели — поддержка сразу трех интерфейсов подключения: USB 2.0, FireWire 400 и eSATA. Особенно интересен последний — он не просто самый производительный, но и вообще практически эквивалентен внутреннему SATA. В общем-то, для компьютера (и в плане оборудования, и с точки зрения операционной системы) разницы межды SATA и eSATA вообще нет, так что полученные результаты можно будет в определенной степени распространить и на винчестеры внутренние. Разумеется, не стоит это делать «в лоб»: для тестов мы используем «чистые» накопители, т. е. никак не учитываем степень влияния фрагментации файлов и свободного пространства (а различные файловые системы «страдают» от фрагментации в разной степени). Фрагментация присуща всем устройствам хранения информации, однако для внешних винчестеров ей зачастую можно и пренебречь (ввиду специфики использования степень фрагментации файлов будет относительно невысокой), а вот для внутренних уже на такие сильные упрощения модели идти опасно (особенно если рассматривать наиболее распространенный случай — в компьютере всего один винчестер, целиком отданный под один логический диск). Однако и такие упрощенные условия, все же, лучше, чем ничего.

Кроме того, мы воспользуемся и полученными в прошлый раз результатами ВЖД от Verbatim. Пусть он снабжен только низкопроизводительным с точки зрения сегодняшнего дня USB 2.0, однако последний интерфейс все еще остается весьма актуален — из-за максимальной универсальности: его поддерживают все компьютеры и даже многие бытовые приборы. А вот сказываются ли на выборе файловой системы свойства самого винчестера, пусть даже только в сфере использования одного интерфейса, уже крайне интересно. Ведь оба ВЖД очень разные: емкость их отличается почти в пять раз, низкоуровневые характеристики — тоже в разы. Словом, если разные мосты и винчестеры способны вести себя сильно  по-разному, мы это при помощи тестов заметим. Если нет — то тем лучше.

Для тестирования, как и в прошлый раз, применялся тот же стенд, на котором мы тестируем ВЖД и внешние модули:

  • EpoX 8NPA SLI
  • AMD Athlon 64 3200+ (512K L2)
  • 1 Гбайт РС3200 DDR SDRAM
  • системный винчестер Western Digital WD1600JS
  • контроллер FireWire 800 Tekram TR-1394B
  • Windows XP Pro + SP3

Поддержка USB 2.0 и eSATA — силами чипсета, благо это наиболее производительный из возможных вариант. Опять же — условия максимальным образом подходят и для того, чтобы их распространить на внутренние винчестеры. А скоростные показатели измерялись при помощи Intel NAS Performance Toolkit версии 1.7.0, подробное описание «стандартных» тестов которой уже было сделано в прошлый раз.

Для форматирования накопителей под NTFS и exFAT использовались штатные средства операционной системы. Установки — по умолчанию. Размер кластера, как обычно, составил 4К и 128К байт соответственно. Форматирование ВЖД от Seagate под FAT32 осуществлялось при помощи консольной утилиты fat32format. Опять же — с кластером по умолчанию, т. е. 32К байт. Впрочем, выбор для накопителя, емкостью 1.5 ТБ, при использовании данной программы  вообще не столь уж и велик — либо 32, либо 64К. Поскольку второе значение к стандартным не относится (и может вызывать проблемы с совместимостью) и все равно не совпадает с типичными размерами кластера для NTFS/exFAT, логично не спорить с природой, а ограничиться первым :)

А вот что у нас получилось в конечном итоге.

Операции «внутри» большого файла, очевидно, практически не должны зависеть от файловой системы диска. Этим, кстати, пользуются некоторые тестовые утилиты, способные работать с размеченными винчестерами, измеряя при этом характеристики низкого уровня. Однако «в семье не без урода» — связка «NTFS+USB» на Xtreme работает достаточно медленно, в чем, по-видимому, виноват конкретный контроллер (как мы помним, на более простом FreeAgent | Desk такой деградации производительности в этом подтесте не наблюдается). В остальном же все примерно равны, eSATA заметно быстрее прочих интерфейсов в любом виде (в чем мы уже не раз убеждались), а в прочих случаях последние всю картину и определяют.

При переходе от одного потока чтения к двум производительность закономерно снижается, причем наиболее заметно падение для eSATA. Менее заметная «просадка» для USB и FireWire объяснима — с пола падать уже некуда :) Винчестеры этими интерфейсами и без того «задавлены» достаточно сильно.

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

А вот при записи данных картина очень пестрая, и заставляет вспомнить рекомендации чуть ли не десятилетней давности: на больших томах FAT не эффективна. Впрочем, заметить эту «неэффективность» можно только при задействовании медленных интерфейсов. Да и тома данных должны быть ну очень большими. Однако если оба этих условия выполняются (как в нашем случае) разница в производительности может достигать почти 20%, а это очень много. Но интереснее всего в этом и предыдущем тестах выглядит exFAT — звезд с неба не хватает, но всегда оказывается в худшем случае второй, причем лишь ненамного отставая от лидера. Так что можно сделать вывод, что система удалась :) Причем большинство шаблонов, которые будут изучены чуть ниже, «рисуют» нам такой же расклад, лишь с парой исключений (но достаточно серьезных).

Чтение плюс запись — ничего такого уж интересного и позволяющего сделать существенные выводы.

А вот Content Creation дает нам куда больше информации для осмысления. Во-первых, в очередной раз стоит заострить внимание на то, что при очень низких абсолютных значениях скорости во всех случаях, eSATA быстрее прочих интерфейсов почти вдвое. Хотя, казалось бы, 7-8 МБ/с это семечки, что для USB, что для FireWire, но... А вот что-то осмысленное по поводу файловых систем сказать сложно. Очевидно только, что в связке из медленного интерфейса с емким и быстрым винчестером лучше всего ведет себя NTFS, но и только. Снимаем ограничения интерфейса — эта ФС становится самой медленной. Берем винчестер помедленнней — все становятся вообще одинаковыми в первом приближении.

Для «рабочего» накопителя выбора очевиден — только NTFS. Хотя при отсутствии выбора не так уж плоха и FAT32. А вот поведение exFAT весьма загадочно — при использовании низкоскоростных интерфейсов производительность этой файловой системы на задачах такого типа деградирует катастрофическим образом — более чем на порядок. В прошлый раз нам не с чем было сравнивать, почему и был сделан ошибочный вывод, что exFAT сама по себе неприменима для таких приложений. Как видим — применима. Но только при использовании SATA/eSATA — «традиционные» внешние интерфейсы ей совсем «не по нутру».

Для «работы» с фотоальбомом (как и для прочих изучаемых «работ») определяющим является интерфейс, если он медленный. Причем важной является не только «сырая» скорость, но и прочие факторы — USB и FireWire шины близкой пропускной способности, но вот в этом тесте они отличаются почти в два раза. А вот если ограничения снять, производительность резко вырастает. Но неравномерно — для NTFS в три раза (сравнительно с USB), а для обеих FAT почти в четыре.

В обзоре FreeAgent Xtreme мы попеняли устройству на качество реализации интерфейса eSATA — слишком уж небольшой прирост при копировании больших файлов с накопителя относительно низкоскоростных интерфейсов. Стоит отметить, что это не какая-то ошибка — применение вместо NASPT FC-Test на другой платформе дает сходную картину. Однако несложно заметить, что способ «снять с ручника» Xtreme есть — всего лишь нужно использовать другие файловые системы, и все будет куда ближе к тому, чего можно было ожидать, ориентируясь на низкоуровневые характеристики используемого в ВЖД винчестера. Очевидно, что проблемы у используемого моста есть, и касаются они работы с блоками небольшого размера, почему увеличение размеров кластера позволяет существенно изменить расклад сил в файловых операциях.

При копировании файла на ВЖД картина радикально иная: тут уже проблемы с передачей больших блоков данных по низкоскоростным шинам. Хотелось бы «похвалить» exFAT за более-менее стабильное поведение, но... Не так уж все хорошо при задействовании eSATA, причем такой проигрыш конкурентам у данной системы один из самых серьезных в тестировании.

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

И на десерт копирование большого количества мелких файлов на накопитель. Достаточно стабильно ведет себя NTFS — больших скоростей тут не достигнешь, так что интерфейс неважен, но результаты во всех случаях достаточно приличные. Для exFAT картина веселее — скорости небольшие, но быстрый интерфейс предпочтительнее медленного. А вот FAT32 прекрасно ведет себя только в одном случае — при подключении ВЖД при помощи eSATA. Прочие интерфейсы — тихий ужас. Обычно это объясняют тем, что для внешних накопителей с USB и FireWire, отформатированных под FAT32, не работает кэширование записи в Windows XP и более новых системах. На самом деле это не совсем верно — запись кэшируется. Вот только из соображений надежности и безопасности операционная система производит принудительную запись данных после копирования каждого файла. Особенно печально то, что и обновление таблиц FAT принудительно происходит после каждой операции — именно поэтому на больших томах скорость падает сильнее, чем на маленьких: при одинаковом размере кластера, больше количество последних и, следовательно, больше размер FAT. В нашем случае получилось трехкратное падение производительности при примерно пятикратном увеличении размера раздела, что близко к максимуму, если сравнивать различные ВЖД.

Зачем это было сделано, раз оно так сильно бьет по производительности? Как обычно — выигрываем в одном, проигрываем в другом. Для NTFS сбои в процессе работы менее критичны, благодаря журналированию. Другими словами, если та же операция записи завершится не полностью, мы все равно будем «знать» на каком этапе она оборвалась. Соответственно, какие файлы действительно созданы, а в каких блоках на самом деле мусор и т. п. У FAT таких средств защиты от сбоев нет, так что ранее незавершенные операции, как правило, требовали запуска ScanDisk или другой подобной утилиты — дабы почистить мусор, типа потерянных или пересекающихся цепочек кластеров. Для внешнего же накопителя вероятность не завершить операцию копирования куда выше, чем для внутреннего — ту же флэшку можно задумавшись о прекрасном выдернуть где-нибудь в середине процесса. Windows XP в данном случае хотя бы гарантирует, что то, что было записано до отключения накопителя, действительно на него записано. В общем, теряться данные стали гораздо реже, что плюс. Но вот со скоростью творится подобное непотребство, что минус. К счастью, чаще всего его можно исправить преходом к другим файловым системам, которые либо меньше страдают от такой политики кэширования, либо вообще поддерживают последнее в полном объеме.

Итак, какие можно сделать выводы? Однозначных — почти никаких. Впрочем, в очередной раз подтвердилось сделанное после прошлого тестирования утверждение, что для «классических» внешних интерфейсов в большинстве случаев применение FAT32 может быть оправдано только соображениями совместимости — слишком уж сильно деградирует производительность при записи данных в виде большого количества файлов. И чем больше емкость дисковых томов, тем более это критично. Для высокоскоростных же интерфейсов однозначные выводы сделать сложнее — слишком много факторов нужно учитывать, причем производительность тут уже не всегда будет иметь определяющее значение. Но их совокупность работает совсем не на пользу «старушке», которая приближается уже к своему пятнадцатилетию. Так что выход в свет exFAT можно только приветствовать — единственной серьезной проблемой данной системы можно считать только лишь пока еще ограниченную поддержку.

И еще один вывод из сегодняшнего тестирования — если вам хочется получить максимум от свежекупленного ВЖД, к вопросу выбора файловой системы следует подойти очень ответственно. Например, то, что Seagate FreeAgent всех модификаций медленноваты на операциях копирования при использовании интерфейса eSATA, давно уже общеизвестный факт. Но вот, как оказалось, простой переход с NTFS (выбранной по умолчанию) на FAT32 или exFAT позволяет ему быстро реабилитировать себя. Аналогичное предположение можно сделать и в отношении других накопителей — если они работают не так быстро, как ожидалось, возможно, стоит задуматься о выборе другой ФС. А вот окончательные рекомендации пока делать рановато — необходимо собрать побольше фактического материала, чем мы в ближайшее время и займемся.






Дополнительно

Нашли ошибку на сайте? Выделите текст и нажмите Shift+Enter

Код для блога бета

Выделите HTML-код в поле, скопируйте его в буфер и вставьте в свой блог.