Russian Fedora

cообщество русскоязычных участников
международного проекта Fedora

Endless представил свой первый продукт!

Это архивная статья

Наш коллега, Jasper St. Pierre, разработчик Wayland, бывший инженер Red Hat и нынешний участник GNOME Design Team, сообщает, что компания, в которой он сейчас работает, Endless Mobile, наконец-то представила свой флагманский продукт.

Компания продолжает дело, начатое OLPC, и предлагает доступный компьютер для всех. Работает он под управлением операционной системы на базе технологий GNOME, а цена начинается с $169.

image0 Компания вышла на Kickstarter со своим проектом, и уже получила желаемое (и довольно умеренное) финансирование. К сожалению, продукт будет недоступен в ряде стран. Эти страны включают в себя Аргентину, Белоруссию, Бирму, Иран, Ирак, Йемен, КНДР, Кубу, Ливан, Ливию, Россию, Сирию, Судан.

Red Hat официально присоединяется к Kronos Group

Это архивная статья

Участник Fedora, разработчик gstreamer и GNOME, Christian Schaller, сообщает в своем блоге, что Red Hat официально присоединяется к организации Kronos Group.

Таким образом компания будет обладать большим влиянием на процесс стандартизации графических API, таких, как OpenGL, OpenCL, Vulkan.

Русскоязычные коллеги-аналитики уже обсуждают эту новость на OpenNET.

Хочется лишь сказать, что давно было пора.

Очередная встреча московского Golang-сообщества - 23 апреля 2015го

Назначена дата очередной встречи московского Golang-сообщества - 23 апреля 2015го.

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

Пропустили тестовый день по виртуализации

Это архивная статья

К сожалению, пропустили тестовый день по виртуализации Fedora 22, и народ уже вовсю присылает результаты (довольно печальные, кстати). Тем не менее, процесс этот практически безостановочный, и вы можете пройтись по списку тестов и прислать ваши результаты даже после завершения тестового дня.

kdbus пробуют включить в Linux 4.1

С осени 2014 kdbus успешно проходит стадии, необходимые для включения в основное дерево. Но до сих пор он был доступен лишь в linux-next, и вот теперь начат процесс включения kdbus в Linux. Если все будет хорошо, то его включат в версию 4.1, но пока kernel-разработчики выдвинули ряд, скажем сразу, довольно серьезных претензий, и вполне может быть, что код опять отправят на доработку.

Наши коллеги с удовольствием наблюдают за развитием событий (например, у Jon Masters в его ленте Google+ и в ленте Google+ проекта systemd).

Очередной meetup от DevOps Moscow - про Ansible (обновление)

Это архивная статья

Поступает уточнение по программе московской встречи по Ansible 16го апреля. Во-1 к нам присоединяется питерское коммьюнити, и мероприятие объявляется московско-питерским. Ну, кое-кто из докладчиков будет из Питера, так что почему бы и не нет? Во-2 к нам едет наш коллега Greg DeKoenigsberg, вице-президент компании Ansible, бывший лидер Fedora Project.

Приходите!

Обновление firmware на материнской плате

Это архивная статья

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

В рамках проекта Coreboot энтузиастами ведется работа по разработке утилиты flashrom, которая позволяет обновлять firmware. Разработчики добились удивительных результатов при минимуме или полном отсутствии помощи от производителей. Мы используем их утилиту в реальных системах, и она работает прекрасно (если материнская плата в списке поддерживаемых). Однако хотелось бы заполучить стандартный механизм обновлений в Linux, независимый от хотелок конкретного производителя, и не требующий перезагрузок в DOS. Для начала Peter Jones, официальный представитель Red Hat в рабочей группе по UEFI, начал работу по реализации вскоре выходящего стандарта UEFI 2.5 в Linux. В этой версии будет предусмотрен механизм для штатного обновления прошивки. UEFI, конечно, становится все сложнее и сложнее, но видимо производителям оборудования так комфортнее - предоставлять стандартный API к сложному firmware вместо документации и исходников к простому и малофункциональному BIOS.

Peter, пользуясь своим положением, сумел достать оборудование, и он с другим нашим коллегой, Richard Hughes, начал работу над стандартным средством обновления. Peter быстро набросал прототип утилиты fwupd для обновления из консоли, а Richard разработал демон для GNOME с тем же названием, о чем он рассказал в своем блоге.

Вероятно, проекты будут как-то унифицированы. GNOME-утилита будет либо устанавливать rpm-пакет с обновлением, либо проверять некоторый web-интерфейс, откуда она будет получать информацию о доступности обновлений и уведомлять пользователя через стандартную систему уведомлений. Сейчас наши парни работают вместе с инженерами Microsoft над полностью системно-независимым стандартом для обновлений. Вероятно впервые Linux будет не вторичной платформой, а полноправным участником стандартного процесса, если вспоминать архитектурные железячные решения.

Самое интересное, что механизм теоретически позволяет обновлять не только системное firmware, но и прошивки на подключаемом оборудовании.

Richard, как proof-of-concept, начал работу над возможностью обновления своего ColorHug с помощью этого API.

Работа наших коллег поможет и другим дистрибутивам. Т.к. GNOME, это система по умолчанию в Ubuntu (они ее кое-как спрятали за единственный самодельный компонент - Unity), то и пользователи этого дистрибутива рано или поздно получат возможность производить надежное обновление системы. Как и обычно, наши улучшения придут туда с небольшим, на год или два, опозданием.

Интереснее выглядила бы перспектива для Coreboot. К сожалению, складывается впечатление, возможно неверное, что разработчики Coreboot долгое время были против UEFI по политическим причинам. Пару лет назад какая-то начальная поддержка UEFI была даже включена в дерево, но затем ее удалили, и текущее состояние дел нам неизвестно. Проект испытывает сильное влияние Google, который активно использует его в своих хромбуках, а в других областях IT мы заметили, что Google не очень заинтересован в поддержке сторонних стандартов, предпочитая делать по-своему, вплоть до создания новых языков программирования. Тем не менее, нужно отметить, что роль Google в проекте очень положительная - они не только наняли многих разработчиков Coreboot, но и продолжают включать в него новый функционал (например, поддержку AArch64, которую продолжают улучшать), и коммьюнити жаловаться не на что. В конце концов, кому надо, тот пусть и пишет патчи.

В отличие от огромного Google, наши коллеги продолжают работать над ПО, использующим возможности UEFI. Мы, таким образом, заходим с другой стороны - через создание нужного нам открытого стандарта, которому будут подчиняться другие заинтересованные лица и организации, и который мы и будем использовать. Недавно, например, в systemd был добавлен gummiboot, и добавлена возможность перезагружаться в режим настройки UEFI.

Насчет настройки - интересно, что почти аналогичную функциональность реализовал Rich WM Jones в своем микрофреймворке.

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

Кстати, недавно gummiboot был исправлен для работы на AArch64.

Самое время, учитывая, что Gigabyte с минуты на минуту начнет выпуск AArch64-оборудования, да и говорят, что Samsung может купить AMD, которые, как вы помните, переходят на ARM

Работа в Parallels

Это архивная статья

С недоумением и печалью некоторые наши коллеги ознакомились с рейтингом работодателей среди студентов - будущих айтишников за 2014 год. С Яндексом на первом месте мы вполне согласны, но дальше местами начинается мрак. И печально там даже не отсутствие желания у студентов творить новое, а желание работать в системных интеграторах и проприетарной компании-производителе офисного пакета, но отсутствие ряда компаний, которые находятся на пике современных технологий. Вот, например, почему студенты и не упомянули дружественную нам компанию, Parallels? Они постоянно ищут молодежь, желающую стать kernel-разработчиками. Скажем сразу, не только непросто назвать российские компании, которые так глубоко влезли в ядро, но и европейские (исключая филиалы Red Hat, конечно). Офис у них довольно далеко от метро, но сложность и интересность задач, и адекватность зарплат вполне могут это скомпенсировать. Ну и плюс возможность защититься в МФТИ по актуальной теме. Просто, конечно, не будет, но интересно, это точно! Пробуйте, пока молоды.

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

Компания была основана в 2000 году. На данный момент штат компании насчитывает более 900 сотрудников, работающих в более чем 15 странах мира.

Основной серверный продукт: Parallels Cloud Server (PCS) - сочетание контейнерной и гипервизорной виртуализации + Parallels Cloud Storage (высокопроизводительное, надёжное и экономичное облачное хранение данных).

Linux Kernel Developer

Project description:
Developing Linux kernel for Parallels Could Server product which combines OS level virtualization solution with hypervisor virtualization solution and cloud storage.
Duties:
  • Development and maintenance of the kernel part of the product (virtualization-enabled Linux kernel)
  • Development of the mainstream Linux kernel
  • New technologies review and adoption for the product

The candidate must meet the following requirements:

  • Higher technical education
  • Like OpenSource as a whole and be in love with Linux
  • Profound knowledge of C
  • Knowledge of x86 architecture
  • Experience in system programming
  • Understanding of processes interaction
  • Knowledge of TCP/IP and Linux network architecture
  • Knowledge of file systems, Linux security model
  • Scripting languages (bash, python, perl)
  • Technical written English

Knowledge and actual experience in any of the following is a plus:
  • Experience in Linux kernel programming
  • Deep knowledge of one or more subsystems of the Linux kernel
  • Knowledge of assembler
  • Knowledge how to use make, patch, rpmbuild
  • Knowledge how to use version control systems (e.g. GIT, CVS, SVN)
  • Knowledge how to use bugs tracking systems (e.g. Bugzilla, Jira)

Компенсация и льготы:

  • Оформление трудовых отношений согласно ТК РФ
  • «Белая» заработная плата. Определяется по результатам собеседования (в зависимости от имеющегося у кандидата опыта и профессиональных навыков)
  • ДМС + Стоматология
  • Бесплатные обеды, ужины, фрукты и кофе брейки
  • Офис расположен в Москве, 5 минут от ст. м. «Отрадное» (корпоративные маршрутки до метро)
  • Помощь при переезде региональным кандидатам
  • Возможность посещать курсы английского языка


Каждого разработчика Parallels, допустившего ошибку, в наказание заставляют подтягиваться прямо в офисе

Rusty Russell уходит из IBM в Bitcoin-стартап

Rusty Russell, kernel-разработчик, известный русскоговорящим линуксоидам по его глумлению над поттерингофобами, когда мы продвигали UsrMove, в прошлом году взял саббатикал на полгода. За это время он занимался творческой деятельностью, связанной с биткойнами. Выйдя на работу, и выступив на ряде конференций, он внезапно занялся известной проблемой Bitcoin - его слабой приспобленностью для микроплатежей.

Исправить эту проблему планируется с помощью нового протокола, Lightning Network. Rusty начал с введения в протокол, оформленного в виде четырех постов в его блоге:

Это неспроста, подумали многие. И действительно, сегодня он объявил в своей ленте Google+, что уходит из IBM в небольшой Bitcoin-стартап, Blockstream.

Мы бы хотели пожелать Rusty успехов в его начинании. Ведь уже довольно значительное количество наших друзей и коллег, начиная с Jeff Garzik и кончая [STRIKEOUT:собутыльниками по общаге] сокурсниками по ВУЗам, начали работать с биткойнами, перспективность которых огромна (например, для финансовых транзакций, устойчивых к любым межправительственным санкциям). К сожалению, в РФ все идет к официальному запрещению биткойнов, а поэтому, если вы хотите стать частью Bitcoin-истории, то наши друзья-юристы настоятельно рекомендуют вам переехать в государство с менее репрессивным законодательством. Например, в те же США, которые уже полтора десятка лет как вот-вот развалятся.

История XFS и будущее фс в целом

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

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

https://lwn.net/images/2015/vault-chinner-sm.jpg

В заставляющем задуматься и, как обычно, веселом докладе на конференции 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-устройствах.

https://igcdn-photos-d-a.akamaihd.net/hphotos-ak-xaf1/t51.2885-15/11017597_446709435480339_411591483_n.jpg

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

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, на который у нас серьезные планы. Конечно, невысокая надежность (на текущий момент, конечно) этой системы мешает нам реализовывать кое-что прямо сейчас, но мы уверены, что ситуация улучшится.