Тестирование двенадцати файловых систем в Linux
В прошлый раз мы тестировали производительность файловой системы ReFS в Windows 10. Там мы затронули некоторые ФС из мира Linux, которые показали достаточно вялые результаты, поскольку из-за ограничений Windows чтение и запись были недостаточно хорошо реализованы. На сей раз подобная несправедливость будет устранена, теперь роли меняются, и файловые системы NTFS, FAT32 и exFAT уже сами становятся гостями. Методика тестирования была усовершенствована, теперь все операции выполняются специальным скриптом, с точностью до миллисекунды замеряющим время, затраченное на определенную операцию. Кроме того был изменен набор данных, вместо поочередного копирования групп различных файлов проводится копирование сразу всех файлов разных типов. Также тестирование теперь не ограничивается только жестким диском, здесь были задействованы более актуальные в настоящее время твердотельные и flash накопители. На каждом из них для размещения тестовых данных был создан раздел объемом 4 Гб, вторым устройством для перемещения данных выступал созданный в оперативной памяти раздел объемом 2304 Мб с файловой системой TMPFS. Поскольку flash-память имеет ограниченное количество циклов перезаписи, то в оценке производительности на данном типе носителей участвовали только нежурналируемые файловые системы.
реклама
Тестовая система:
- Процессор: Xeon E5440 @ 3.4 ГГц
- GIGABYTE GA-P35-DS3L
- Оперативная память: 3584 МБ DDR2-800
- Жесткий диск: Seagate Barracuda 7200.10 3250410AS 250 ГБ
- Твердотельный накопитель: SanDisk SDSSDHII-120G-G25 120 ГБ
- MicroSD карта SanDisk Ultra 16 Гб UHS-I, поключенная с помощью адаптера MXT
- Ubuntu 16.04 x64 с последними обновлениями
Набор данных:
- 100 MP3 файлов — 681,3 Мб
- 880 JPEG изображений 268,8 Мб
- 4 видеоролика в формате MP4 — 492,7 Мб
- 1 ISO образ — 583 Мб
- Суммарный объем: ~2 Гб
реклама
Краткая характеристика участников тестирования:
EXT2 — расширенная версия первой файловой системы EXT для ОС на ядре Linux.
EXT3 — журналируемая EXT2.
реклама
EXT4 — значительно расширенная по функционалу EXT3.
BTRFS — прогрессивная файловая система, использующая СУБД-подобную структуру , а также предлагающая множество современных опций.
F2FS — файловая система от Samsung, предназначенная для использования на flash-памяти.
ReiserFS — журналируемая ФС от компании Namesys, позволяющая изменять свой размер на лету без размонтирования.
XFS — высокопроизводительная 64-битная журналируемая файловая система, созданная компанией Silicon Graphics.
JFS — 64-битная журналируемая ФС, разработанная IBM с прицелом на высокую производительность, надёжность и масштабируемость для многопроцессорных компьютеров.
HFS+ — файловая система, использующаяся в macOS.
NTFS — ФС для Windows NT, выросшая из HPFS, совместной разработки IBM и Microsoft для OS/2.
FAT32 — усовершенствованная версия файловой системы FAT для DOS и Windows.
exFAT — расширенная версия FAT32, предназначенная для flash-накопителей.
Результаты тестов:
Итак, для начала запишем наши данные на жесткий диск с гораздо более быстрой оперативной памяти. Считывание происходит моментально, а вот скорость записи служит характеристикой быстродействия конкретной файловой системы для данного типа накопителя.
Новая файловая система F2FS демонстрирует отличный результат, опережая своих оппонентов. За ней следуют продвинутые журналируемые ФС, в основном использующиеся в NIX системах. Гости из Windows, а также устаревшие EXT2 и EXT3 заметно отстают.
Теперь проделаем тоже самое, но уже с быстрым твердотельным накопителем.
Разрыв между первым и замыкающим участниками заметно вырос. На сей раз в лидерах созданная профессионалами Sun Microsystems система XFS, которая показала результат близкий к максимальной пропускной способности интерфейса SATA-II. BTRFS, все еще считающая в некоторых аспектах не совсем стабильной, находится в нижней части списка. Работающая в пользовательском пространстве с помощью специального драйвера, NTFS показала почти в четверо более низкий результат, чем XFS.
А теперь данные будут переноситься наоборот с дисков в ОЗУ. Так как запись происходит очень быстро, то распределение файловых систем в диаграмме будет зависеть от их производительности при считывании.
Ситуация похожа на ту, которая была продемонстрирована в первом тесте. Но тут FAT32 поднялась сразу на семь позиций, а на ее место переехала BTRFS. Устаревшие EXT2 и EXT3 снова замыкают список.
Видно, что разница сократилась, поскольку и твердотельный накопитель и оперативная память довольно быстрые устройства, и одно лишь это устраняет различные недостатки, присущие каждой их файловых систем. XFS выдала просто ошеломительный результат, практически уперевшись в пропускную способность SATA-II. Более усложненная BTRFS на второй позиции. Несмотря на прослойку в виде FUSE, NTFS заняла довольно почетное место.
Настала очередь flash-накопителей.
exFAT обошла F2FS в тесте записи примерно на 18%. EXT2, как и в предыдущих испытаниях, плетется в конце.
Ну и, наконец, чтение с flash-памяти.
FAT32 показывает, кто здесь царь. Несмотря на почтенный возраст, она и не собирается сдавать своих позиций. К сожалению максимальный размер файла в FAT32 ограничен четырьмя гигабайтами, что совершенно не подходит для тех же фильмов в высоком качестве. Однако, ее замена в лице exFAT отменяет данный изъян ценой всего лишь десятипроцентной потери производительности.
И ради интереса был проведен еще один тест с участием только RAM-дисков (копирование ISO-образа).
Мир Linux открывает перед пользователями Windows множество граней, одной из которых является наличие гораздо большего количества различных файловых систем. Каждая из них имеет свои достоинства и недостатки, кто-то силен в одних ситуациях, кто-то в других. И в проведенном тестировании мы попытались выявить данное распределение сил.
В результате наших проверок выяснилось, что более новые и хорошо отлаженные файловые системы стремятся показать более высокую производительность. И наоборот, устаревшие системы уменьшают скорость выполнения операций чтения-записи. Но данное правило не всегда строго выполняется, так как характеристики конкретной файловой системы могут не всегда соответствовать определенным в текущий момент условиям использования, для которых подходит пусть менее передовая, но более подходящая система.
Разумеется в подавляющем большинстве случаев нет возможности менять файловую систему одномоментно с изменившимися критериями эксплуатации. Но в этом и не будет особой необходимости, если заранее оценить рабочее окружение и возможные сценарии использования и лишь затем принимать решение о выборе файловой системы.
Подпишитесь на наш канал в Яндекс.Дзен или telegram-канал @overclockers_news — это удобные способы следить за новыми материалами на сайте. С картинками, расширенными описаниями и без рекламы.
Выбираем файловую систему независимую от ОС
Всем привет. Недавно я задался вопросом как организовать обмен файлами между операционными системами. Предположим, я хочу установить сразу три основные ос на своём ноутбуке: линукс, виндовз и хакинтош. Каждая ос предназначается для своих задач: Линукс — для работы и программирования, винда — для игр и хак — просто для разных экспериментов.
Поскольку я создаю обучающие видео ролики о линуксе, мне удобнее работать именно на нём. Но монтировать хочется попробовать в «финальном вырезе». Уж очень мне приглянулась идея магнитной ленты времени.
Так вот, задача стоит такая: нужен раздел на системном накопителе, причём с такой файловой системой, которая поддерживается на чтение и запись всеми перечисленными операционками. На этом разделе будут храниться скачанные из интернета файлы и меж-операционные проекты.
Как такая задача решалась мной раньше? Раньше я использовал только винду с линуксом, поэтому задачи обмена с apple os не возникало. Конечно, хотелось использовать открытую и родную фс для линукса — ext4. Но на винде её смонтировать непросто. Нужно устанавливать бесплатный (но проприетарный) Paragon ExtFS for Windows. И ладно, если бы это работало, но к сожалению данное ПО повреждает вам раздел с линуксом. Напоролся пару раз, и всякое желание пользоваться этим по пропало.
А вот виндовая фс под линуксом читается и пишется без проблем. Нужно всего лишь установить ntfs-3g драйвер. Он работает в юзерспейсе. Файловая система проприетарная, но решение работает.
Теперь же я хочу использовать ещё и хакинтош, и хочется разобраться какие ещё есть варианты для решения этой задачи, кроме ntfs.
На самом деле вариантов немного. Давайте разберёмся, какие есть файловые системы, и какие из них являются более или менее универсальными.
Fat32 — всем известная древняя фс, является самой универсальной в плане переносимости, но и самой убогой в плане ограничений. Была разработана давно, не поддерживает файлы размером более 4 Гб. Проприетарная. Для моих задач не подходит.
Ntfs — родная фс для винды, проприетарщина. Линукс, как я уже писал выше, её поддерживает с помощью стороннего драйвера (ntfs-3g). Мак нативно её не понимает, хотя можно доустановить соответствующее по. Есть несколько вариантов, как платных, так и бесплатных. Ни один из них мне не нравится. ntfs-3g работает в userspace (с медленной скоростью), а платные решения — платные.
Hfs+ — одна из худших фс, когда либо созданных. Родная для мак ос, но нисколько не универсальная. Можно примонтировать на линуксе, а для винды опять же есть платные решения — в пролёте.
Ext4 — одна из правильных фс, родная для линукс. Но в плане монтирования в неродных ос — опять проблемы. За платные решения для хакинтоша и для винды опять просят денег. Есть и бесплатные решения, к примеру ext2fsd, но этот драйвер не умеет писать в ext4. В пролёте.
Udf — одна из правильных фс, поддерживается нативно всеми ос. Эта фс была бы лучшим вариантом, если бы не компания apple. Изначально udf создавалась для оптических носителей, но она может быть спокойно использована на обычном жёстком магнитном диске. НО! Из-за того, что яблочники не реализовали поддержку этой фс с раздела, вся задумка отменяется. Даже последняя мак ос Х поддерживает данную фс только если всё блочное устройство не имеет таблицы разделов. На гитхабе есть скрипт format-udf, который может подготовить носитель специальным образом: в начальном блоке данных прописывается mbr, говорящий что раздел начинается прямо там же где и сам mbr. Т.е. накопитель как бы одновременно и с таблицей разделов (то что понимает винда), и вроде как и без таблицы разделов. Этот способ предполагает что носитель будет внешний, а мне нужно сделать exchange раздел именно на внутреннем накопителе. Так что данный вариант тоже в пролёте.
exFat — проприетарщина, но нативно работает как в винде, так и в маке. Это очень хорошо. А что в линуксе?
Эта фс использовалась для sd карт на андроидах, а там у нас линукс ядро. Производители реализовали драйвер exfat для linux ядра и никому его не показывали. Но некто в интернете слил на гитхаб их код. Было понятно, что это воровство, и в таком виде код в ядро попасть не мог. Однако, в этом коде сообщество нашло куски gpl кода, что разумеется, требовало раскрытия всех исходников, т.е. это было уже воровство у сообщества со стороны компании samsung. Через некоторое время самсунг выпустили этот код под gpl лицензией.
Спрашивается, а почему тогда данный драйвер не поддерживается из коробки? Потому что его нет в ядре. Мердж этого кода (пусть и gpl-ного) в mainline — это по сути троян от мелких (из-за патентов). Торвальдс это понимает, и, понятное дело, ядро не отравит.
В линуксе монтировать exfat можно либо с помощью exfat-fuse драйвера, либо с помощью exfat-nofuse. Конечно, лучше nofuse, так как он будет работать быстрее. Но его придётся собирать каждый раз при обновлении ядра. Благо, для автоматизации этой задачи есть механизм dkms.
Я останавливаюсь на exfat. Да, проприетарщина, но ничего не поделаешь. Зато всё нативно работает, и “танцы с бубном” отсутствуют: во всех трех операционных системах есть нативная поддержка и возможность поставить эту фс именно на раздел. Ограничения в 4 Гб нет. И в целом, это решение достаточно простое.
Надеюсь, вы узнали что-то новое для себя и выберите подходящий вариант исходя из ваших нужд.
Апдейт 4 февраля 2020:
Оказывается раздел с exfat невозможно ни растянуть, ни сжать. Причём даже на самой винде. Не учёл этот момент при выборе решения. Если нужно изменить размер раздела — придётся только бекапить данные в другое место и пересоздавать раздел уже с нужным размером.
С UDF в этом плане дела не лучше. Вот здесь лежит табличка, описывающая возможности по работе с разделами в gparted.