Мы регулярно рассказываем про новости XFS, файловой системы, как и многие другие подсистемы ядра, разрабатываемой под контролем наших коллег. Файловая система, несмотря на свой возраст, до сих пор обладает серьезным потенциалом, и, например, упоминается специалистами Google среди файловых систем ближайшего будущего. Наши коллеги разделяют это мнение, и после перехода на XFS, как фс по умолчанию в RHEL 7, мы планируем использовать именно ее по умолчанию в Fedora Server (в совокупности с другими высокотехнологичными решениями, такими, как LVM).

Наш коллега, инженер Red Hat, Dave Chinner, мэйнтейнер XFS, недавно выступал на конференции Vault 2015 в Бостоне. Он сделал интересный доклад по истории файловой системы, ее ближайшему будущему, и будущему всех фс в целом.

В заставляющем задуматься и, как обычно, веселом докладе на конференции Vault, Dave Chinner рассказал об истории XFS, ее текущем статусе, и тем, как могут развиваться файловые системы.

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

История

В начале 1990х, "до того, как я узнал, что такое SGI", говорит Chinner, системы хранения начали превосходить объемы, которые можно было адресовать с помощью 32 битов. Extent File System (EFS), существовавшая файловая система на SGI Unix, IRIX, поддерживала лишь 32-битные адреса. В то же время начали появляться 64-битные микропроцессоры с массивной многопроцессностью, а вот системы с поддержкой сотен дисков показывали посредственные результаты.

XFS была разработала, чтоб исправить эти недостатки. Буква "X" обозначала лишь "не определено" ("undefined"). Новая, неопределенная фс, xFS, должна была обладать довольно большим количеством возможностей: быстрое восстановление после сбоев, большие файловые системы как с разреженными (sparse), так и с непрерывными (contiguous) файлами, и директории с большим количеством файлов. ФС должна поддерживать терабайтные и петабайтные объемы в обозримом будущем.

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

Старейший найденный недавно баг, сказал Dave, был возрастом в 19 лет.

Первый продакшен-релиз XFS был сделан в декабре 1994 года, одновременно с релизом IRIX 5.3. В середине 1996го XFS стала фс по умолчанию в IRIX 6.2. К тому времени дисковый формат уже пережил четыре версии. Уже те ранние версии обладали "feature mask", позволявшей в конкретных случаях включать или выключать различные функции фс. Их устанавливали в момент создания системы с помощью mkfs, и эту маску учитывали при различных операциях. Эта функциональность делает XFS особенно гибкой.

За годы IRIX, т.е. вплоть до конца 1990х, система получила различные новые фичи. В 1997 году была добавлена поддержка аппаратных RAID-массивов, что позволило фс выравнивать свою физическую структуру в соответствии с геометрией нижележащего хранилища. В 1999 исходная структура директорий устарела, так что пришлось добавить вторую версию поддержки директорий, что повысило масштабируемость до десятков миллионов файлов. Тут Chinner сообщил, что лично пробовал директорию с 350 миллионами файлов, но он не рекомендует повторять его опыт, т.к. запустить ls на такой директории заняло примерно 12 часов.

Переориентация на Linux

Сразу после этого разработка XFS в IRIX замедлилась. SGI сместил приоритеты на большие NUMA-машины и распределенный IRIX. Разработка сместилась с XFS на новую кластерную фс, CXFS. Но в SGI также появилась новая продуктовая линейка на базе Linux, на котором не было фс с возможностями XFS. Поэтому в Австралии, Мельбурн, была сформирована новая команда разработчиков, чтобы перенести XFS на Linux.

В 2000м году XFS выпустили под GPL. Первый стабильный релиз XFS вышел в 2001м. А в 2002м XFS включили в Linux 2.5.36.

Одним из неприятных побочных эффектов включения XFS и других фс в Linux стало быстрое разрастание того, что Dave назвал "автогонки Bonnie++". Энтузиасты использовали утилиту для бенчмарков фс, не разбираясь в деталях работы самой фс. Это привело к тому, чтоб они крутили ручки настройки, не понимая, что изменяют. Основная проблема в том, что Google до сих под подсовывает в результаты поиска посты и хаутушки того времени.

Поэтому, если кто-нибудь соберется потюнить производительность XFS, то он(а) скорее всего начнет с постов того времени, что приводит к бесконечным "noatime,nodiratime,logbufs=8 meme" в параметрах монтирования XFS.

Некоторые участники нашего проекта подчеркивают вредоносность протухших хаутушек, появляющихся в поиске сверху, и большим количеством которых по наивности и непониманию проблемы гордятся некоторые недалекие представители ряда других сообществ. Если проблема решается неким алгоритмом действий, то почему бы ее не решить на уровне дистрибутива, вместо написания инструкции по ее обходу? [прим. перев.]

В начале 2000х Linux-версия XFS стала разбегаться по функционалу от версии для IRIX. Все началось с групповых квот. В 2002 году была добавлена вторая версия формата журналирования, что помогло улучшить производительность операций с метаданными. В том же 2002м появилась функция удаления кластера inode ("inode cluster delete") и настраиваемый размер секторов. В 2004м были унифицированы версии для Linux 2.4 и Linux 2.6, и расширена feature mask. Биты в ней закончились, и последний выделенный бит показывал, что необходимо загрузить дополнительную маску.

Серьезное достижение было в 2004 году, когда SUSE выпустила SLES 9 с полной поддержкой XFS. Это было серьезной проверкой всей работе, проведенной SGI. В этот момент выступления кто-то выкрикнул из зала, что SLES 8, вышедшая в 2001м, уже поддерживала XFS, что сильно удивило Дэйва.

В середине 2000x, во время "filesystems wars" распространялись различные слухи и сплетни про XFS (и про другие фс). Dave в слайдах к своему выступлению привел несколько примеров высказываний о "магических" фичах XFS, таких, как, например, большие конденсаторы в источниках питания SGI, которые должны были помочь XFS не терять данные при сбоях питания, зануление данных после операции unlink, чтобы восстановление удаленных файлов было невозможно, и зануление всех открытых файлов при некорректном отключении. Это все неправда, конечно, но эти слухи стали частью фольклора XFS.

Еще больше функционала было добавлено в 2005-2006 годы. Например, хранение расширенных аттрибутов в inode, что привело к улучшению производительности в SAMBA поверх XFS на порядок. Это время стало критической точкой, когда XFS для Linux начала превосходить XFS для IRIX. На Linux 2.6.16, с помощью XFS добились пропускной способности в 10 гигабайт/c на 24-процессорной машинке Altix.

Несколько лет спустя начались т.н. "O_PONIES wars". Dave обратил внимание аудитории на баг в Launchpad, описывающий повреждение XFS при неких условиях. Чтобы обойти багу, необходимо было просто вызвать fdatasync() после переименования файла, но для этого требуется пропатчить приложение. Тикет закрыли с WONTFIX, но никого из разработчиков XFS не спросили. В конце концов оказалось, что это действительно ошибка в XFS, которую исправили год спустя.

У коммьюнити вокруг того дистрибутива действительно плохой контакт с разработчиками. А тогда им было еще сложнее психологически обратиться к разработчикам за помощью, т.к. тогда постепенно нарастало их неприятие, и среди наших коллег был популярен грязный спорт - "найди их представителя, спрятавшегося за аккаунт на gmail.com, в нашей багзилле и поглумись". Понятно, что это не помогало наладить им отношения с нами, и, как результат, они полностью отделились. Это, конечно, никому особой пользы не принесло [прим. перев.]

Переориентирование на сообщество

В 2009 году наступили плохие времена. SGI распустила команду по разработке XFS. Компания теряла деньги с 1999. Сообщество взялось за поддержку XFS, пока SGI реорганизовывалось. Даже тогда SGI периодически поддерживало XFS, вплоть до конца 2013. Dave не упомянул, что основную работу в течении этого периода делали разработчики из других компаний, такие, как он сам. Он сказал, что однажды он поехал на выходные посмотреть на гонки, а когда вернулся, то узнал, что его выдвинули в мэйнтейнеры.

Мы `рассказывали вам об этой истории </content/xfs-в-rhel-7>`__, которая `закончилась положительно </content/Компания-sgi-прекратила-поддерживать-xfs-в-linux>`__ [прим. перев.].

С тех пор, как была распущена команда XFS, разработка фс стала вестись сообществом. Однако разработка не замедлилась. Как раз наоборот, ускорилась. Но работа велась не только по добавлению кода, но и по его удалению - было выброшено прилично всего.

Dave задал риторический вопрос - является ли XFS до сих пор той большой раздутой штукой от SGI? Он продемонстрировал график количества строк кода в XFS в каждом релизе Linux. Из него видно, что размер кодовой базы XFS начал падать начиная с версии 2.6.14, достиг минимума в версии 3.6, начал расти вплоть до версии 3.15 или около того, и держится на том уровне с тех пор. Текущий размер (примерно 70 килострок) кодовой базы меньше, чем уровень, с которого все началось измеряться с версии 2.6.12 (около 75 килострок). А вот график для btrfs пересек график XFS в версии 3.5, достиг размера в 89 килострок и растет дальше - никакого выхода на плато и близко не видно.

Dave перечислил топ-разработчиков XFS, лидером среди которых является Christoph Hellwig, за которым сразу идет сам Chinner. Он особо упомянул ранних разработчиков XFS, Adam Sweeney и Doug Doucette, указав, что они выполнили огромный объем работы в довольно короткое время. Тут он процитировал Isaac Newton ("If I have seen further than others, it is by standing upon the shoulders of giants."), сказав, что XFS появилась не вследствие его усилий, но благодаря работе других разработчиков в этом списке.

Сейчас в XFS ведется работа по выделению разреженных блоков inode (sparse inode chunk allocation), что требуется для GlusterFS и Ceph, унификация API для квотирования, reverse mapping во внутренних B-trees (причины для этого обнаружились на недавно прошедшем LSFMM саммите). Также был добавлена поддержка reflink-ов для по-файловых снапшотов, улучшена дефрагментация, и поддержка DAX. Dave сообщил, что прямо сейчас идет полно работы.

Ближайшее будущее

Находясь в самом центре работы над всем этим, Dave попытался обрисовать ближайшие лет пять разработки XFS. Ранее, в 2008 году, он уже делал что-то подобное, выложив кое-какие планы на сайт XFS.org. С тех пор все фичи, которые он описал в тех текстах, были вычеркнуты из списка, ну, кроме reverse B-trees, которые пока реализованы на 95%. Поэтому сейчас настало время попланировать на будущее.

Уже существуют технологии хранения данных, которые тянут разрабочиков фс в разные стороны. Черепичная магнитная запись (Shindled magnetic recording, SMR) и persistent memory радикально изменят системы хранения данных. Определяющим моментом для разработчиков, будет необходимость найти более-менее приличный вариант работы существующих фс поверх SMR и/или устройств "persistent memory". Однажды кто-то предложит фс, которая будет предназначена для этих систем, и она сметет все другие с рынка.

В течение следуюших лет пяти от XFS потребуется лучшая интеграция с блочными устройствами, поверх которых она работает. Им необходимо обмениваться информацией между собой. Это позволит, например, улучшить подержку "thin provisioning" (технология, позволяющая выделять ресурсов больше, чем фактически присутствует, предполагая, что запрашивающий необязательно использует весь объем ресурсов сразу - подход используется много где, например, в LVM, что было `фичей Fedora 20 </content/И-опять-новые-фичи-fedora-20>`__). Также это поможет при "offloading" операций клонирования блоков, копирования и их сжатия. Само собой, есть и другие варианты использования такой интеграции, включая лучшую поддержку снапшотов на уровне фс.

Повышение надежности, это еще одна область, где XFS нуждается в помощи. Восстановление зависших объектов (без записи в журнале) может быть реализуемо при полноценной работоспособности B-tree reverse mapping. Это также позволит восстанавливать примонтированную фс, без необходимости размонтировать ее для проверки. Когда будет найдено повреждение, затронутая им часть фс может быть просто изолирована для восстановления. Это позволит сделать XFS самовосстанавливающейся.

Объем работы, который нужно провести, довольно большой. Хотя Dave предполагает, что это будет реализовано в течении ближайших пяти лет, вряд ли ему в одиночку удастся осилить это в указанный срок. Он бы выполнил эту работу в течении лет шести-семи, сказал он с усмешкой.

Еще дальше

Но нам нужно планировать чуть дальше. Если смотреть на динамику изменения объемов и времени доступа "вращающихся грампластинок", то мы увидим, что 8 гигабайт и 7 миллисекунд в середине 1990х сменилось на 8 терабайт и 15 миллисекунд в середине 2010х. Если по этим двум точкам построить график, то мы увидим, что в середине 2030х у нас будет 8 петабайт (8000 терабайт) с 30 миллисекундами доступа.

Обращаем ваше внимание, что для соответствия графиков нужно выбрать логарифмическую шкалу для объемов и линейную для времени доступа [прим.перев.]

Развитие SSD-устройств стартовало от медленных, ненадежных и дорогущих 30-гигабайтников в 2005 году. Те дисковые накопители стоили примерно 10$ за гигабайт, а современный стоечный трехюнитовый SSD-массив на 512 терабайт стоит дешевле 1$ за гигабайт, и позволяет получить до 7 гигабайт/с пропускной способности. Проведя графики по этим двум точкам мы получим к 2025 году трехюнитовые массивы SSD в 8 экзабайт (8000 петабайт) по 10 центов за гигабайт.

SSD-диски обладают неоспоримыми преимуществами (емкость, энергопотребление, производительность), и вполне уже могут посоревноваться по цене. Но persistent memory будет еще емче и быстрее, и все еще доступна по цене. Тем не менее, Dave полагает, что пройдет еще лет пять, пока мы увидим распространение систем на базе persistent memory.

Он предупреждает, что мемристоры могут изменить все планы раз и навсегда.

Эти предсказания подразумевают, что нынешние системы на "вращающихся грампластинках" будут массово заменяться. XFS (и, кстати, прочие фс) должны следовать туда, куда их тянет оборудование. SSD-железо увеличит объемы, масштабируемость, производительность гораздо больше, чем SMR. Хотя, конечно, большинство фоток котиков в интернете вскоре будет храниться на SMR-устройствах.

Коту уже все равно на чем вы будете хранить его фотки

8 экзабайт, это примерно совпадает с ограничением XFS по предельному размеру. На самом деле 64-битное адресное пространство может закончиться для фс в ближайшие 10-15 лет. Многие полагают, что 128-битная адресация, используемая в ZFS, это безумие, но на самом деле, это не так уж и безумно.

В 2015-2030 годах XFS упрется в ограничения по объему и адресному пространству. Она также будет архитектурно ограничиваться из-за задачи по поддержанию совместимости с "вращающимися грампластинками". Архитектура XFS будет несоответствовать развивающимся технологиям устройств хранения того времени.

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

Существует жесткое ограничение на время жизни фс, да и SMR будет вытеснено другими технологиями.

Исходя из опыта Btrfs, GlusterFS, Ceph, и т.п. мы знаем, что фс требуется 5-10 лет для взросления. Получается, что для XFS ближайшие 5-7 лет будут последними. В течение ближайших 20 лет XFS будет устаревшей технологией. Кстати, это же верно для всех прочих нынешних фс. Dave признал, что он может и не прав, но если он все-таки прав, то мы сейчас наблюдаем последний период разработки всех основных фс Linux.

[Автор хотел бы поблагодарить Linux Foundation за помощь в поездке на конференцию Vault]

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