27 октября 2020 года состоялся релиз Fedora 33 с ядром Linux 5.8, GNOME 3.38, LLVM 11, Python 3.9, Perl 5.32, Mesa 20.2, Java 11 по умолчанию.

Fedora от Red Hat — один из самых популярных в мире дистрибутивов Linux. Он выпускается в нескольких редакциях для конкретных вариантов использования: для десктопа, сервера, облака, а теперь ещё и для Интернета вещей.

Fedora 33 — большой релиз с огромным количеством изменений (список).

XFS — начало разработки 1993 год, фирма Silicon Graphics, в мае 2000 года предстала в GNU GPL, для пользователей большинства Linux систем стала доступна в 2001-2002 гг. Отличительная черта системы — прекрасная поддержка больших файлов и файловых томов, 8 эксбибайт — 1 байт (8*2⁶⁰-1 байт) для 64-х битных систем. Ко всему прочему обладает другими немаловажными особенностями — непрерывные области дискового пространства, задержка выделения пространства и онлайн дефрагментация. Является одной из старейших журналируемых файловых систем для *nix, и содержит в себе наиболее отлаженный, в этом контексте, исходный код.

ReiserFS (Reiser3) — одна из первых журналируемых файловых систем под Linux, разработана Namesys. Имеет некоторые врождённые головные боли, но в целом неплохая система, ведущая отсчёт дней своих с 2001 года. Оговорюсь, что смысл журналируемых систем заключается в дисковых транзакциях, которые последовательно пишутся в специальную зону диска (журнал, он же лог), перед тем как данные попадают в конечные точки файловой системы. Максимальный объём тома для этой системы равен 16 тебибайт (16*2⁴⁰ байт).

Btrfs, файловая система Linux следующего поколения, задуманная Oracle и предназначенная для того, чтобы конкурировать с некоторыми особенностями файловой системы Sun ZFS, только что вошла в состав ядра Linux 2.6.29.

Сегодня утром Линус Торвальдс, наконец, «запихнул» Btrfs в основное ядро.

С этой файловой системой, которая привносит ряд преимуществ по сравнению с EXT4 в ядро Linux, а так же kernel mode-settings и другими особенностями, ядро Linux 2.6.29 видится очень интересным релизом. Подробнее о файловой системы Btrfs можно прочитать на веб-сайте проекта.

PS. Ранее про файловые системы на Хабре была статья, где кратко описываются основные особенности различных FS, в том числе и Btrfs.

Update. Вышел Linux 2.6.29-rc1. Релиз кандидат.

Вышла новая версия файловой системы Btrfs — 0.17.

Спустя полгода после выхода прошлого релиза, выпущена новая версия файловой системы Btrfs — 0.17, на которой будет основан код включенный в состав будущего Linux ядра 2.6.29. Важность версии 0.17 состоит в фиксации дискового формата, который больше не будет меняться, за исключением случаев, связанных с нахождением критических ошибок. Финальный стабильный релиз Btrfs 1.0 будет выпущен в течение 2009 года, хотя изначально он ожидался в конце 2008 года.
Из новшеств Btrfs 0.17 можно отметить:
1. Поддержку прозрачного сжатия данных (mount -o compress);
2. Улучшение механизмов распределения блоков данных;
3. Возможность связывания создаваемых Btrfs разделов с ранее существующими (device seed), при этом ранее существующий раздел используется в качестве каркаса, функционирующего в режиме только для чтения, а изменения в рамках дерева каталогов сохраняются в новом разделе;
4. Улучшение совместного использования блоков на время переноса экстентов. Например, в новой версии значительно лучше обрабатывается ситуация одновременного использования блоков в разных снапшотах, во время записи в COW (Copy On Write) лог;
5. Исправления ошибок и оптимизация производительности.

Новый GRUB может обрабатывать /boot раздел в формате btrfs, так что теперь не нужно иметь отдельный раздел отформатированный в ext2/3/4.

Далее предполагаем, что вся ваша файловая система представлена одной партицией. Если же у вас под каждый раздел /usr/, /var и т.д. создана отдельная партиция то модифицируйте их по отдельности, согласно приведённой ниже инструкции.

Итак, приступим…

Я как гик, всё ещё имею привычки, постоянно эксперементировать с системой: пересобирать, ставить несталбильные RC ядра, включать experimental ветки обновлений. Часто, я бы даже сказал слишком часто ломаю систему (мой личный рекорд, 2 недели без переустановки).

Что значит ломаю? Когда что-то работает крайне нехорошо, например часто вылетающий LibreOffice и Compiz который любит подвисать, я или пытаюсь реконфигурировать систему, но это достаточно долго и муторно.

Собственно, к чему я веду.

Если кто-то так же как я, любит эксперементировать с системой и её надоело каждый раз восстанавливать, то вот вам вариант как я решил эту проблему для себя. Проошу под кат.

how-to или очередной велосипед.

Во время разработки одного проекта возникла необходимость хранить множество файлов (более 4 млн. штук). И их количество продолжало расти. Когда файлов стало более 6 млн., работать с ними стало затруднительно. Даже если разложить их по каталогам и создать разветвлённое дерево, обход даже части этих каталогов занимал часы. Разумеется, вначале никто не задумывался над тем, как все это хранить, и мы использовали обычный винт и ext4. В какой-то момент скорость чтения с этого раздела снизилась до 9MB/sec. Это слишком медленно. Экспериментальный переход на btrfs поднял скорость до 13MB, но такие показатели тоже не впечатляют. SSD для этого никто не собирался использовать да и объём уже перевалил за 1TB. Т.е. всё шло к использованию RAID'ов. Поскольку коммерческий успех проекта был под сомнением, то стоимость нужно было свести к минимуму. Следовательно, реализация должна была быть программной.

Итак, нужно небольшое хранилище — на одном сервере или компьютере, т.е. не более четырех дисков. Хранить нужно небольшие файлы — по 1-3Mb каждый.

Уже было много постов о резервном копировании, особенно много для ОС Linux. Озаботился и я настройкой резервного копирования.
Требовалось создавать бэкапы системы, данных с примонтированного раздела и LVM томов (диски виртуальных машин). Были мысли использовать Bacula, т.к. знаком с ней, но поскольку дома только 1 компьютер клиент-серверная архитектура только создавала бы дополнительные сложности при восстановлении в случае повреждения системы. Значит систему и данные просто копируем, образ LVM раздела создаем с помощью dd. Хотелось делать резервную каждый день (хотя бы данных) и хранить минимум 14 дней. Но поиски готовых и простых решений, удовлетворяющих всем потребностям не увенчались успехом. А значит берем в руки bash и пишем свой велосипед. В этой статье я делюсь тем, что вышло.

Это статья-мануал по скрипту резервного копирования, написанному мной. Скрипт написан на python для Linux. Кому интересно прошу под хабракат.

Много времени прошло с момента когда появилась btrfs. Она еще в разработке. Плюсов заявлено и уже реализовано море. Тут тебе и сжатие прозрачное и снимки одной командой и еще множество плюшек. Пока нет онлайн дефрагментации, но все же хочется попользовать. На root своего ноута-десктопа давно пользую, уже наверно год. Снапшоты спасают от ломаных пакетов и прочего подобного. У одного знакомого на мининоуте еще дольше, так как на его SSD встроенный ничего толком не влазит, а тут сжатие прозрачное. В общем довольно стабильна эта ФС сегодня.

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

А вот появилось обновление — два новеньких SSD, было решено во время переноса системы заодно перейти на btrfs.
Всё отлично — RAID0 для данных RAID1 для метаданных средствами файловой системы, сжатие на лету, корень в одном суб-томе (subvolume), домашняя папка в другом, веб-сайты в третьем. Всё это грузится прямо с UEFI в Linux EFI stub без GRUB и других загрузчиков, работает быстро и удобно.
И вот дошло дело до снимков (snapshot), их я хотел использовать для резервных копий суб-томов средствами всё того же драйвера btrfs.

Поиск выдает несколько релевантных решений, но одни решения слишком громоздки (синхронизация резервных копий, через сеть, создание каких-то репозиториев, вложенных потоков и т.д.) и навязывают свою архитектуру, другие не имеют адекватной ротации резервных копий (можно указать только один интервал и количество копий в нём).

Решение принято — новому инструменту быть!

На прошедшем в начале марте этого года мероприятии Vault, организованным Linux Foundation в Бостоне, было много разговоров о файловых системах и хранилищах. Если думаете, что там не было сказано ничего нового, то вы ошибаетесь.

Недавно, просматривая статью на вики про файловые системы, заинтересовался btrfs, а именно его богатыми возможностями, стабильным статусом и главное — механизмом прозрачного сжатия данных. Зная, как легко жмутся базы данных содержащие текстовую информацию, мне стало любопытно уточнить на сколько это применимо в сценарии использования например с postgres.

Данное тестирование конечно нельзя назвать полным, ибо задействовано только чтение и то линейное. Но результаты уже заставляют поразмыслить на тему возможного перехода на btrfs в определенных случаях.

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

Для тех, кто не хочет тратить время, сразу расскажу про полученные выводы. БД PostgreSQL размещенная на btrfs c опцией compress=lzo, сокращает объем бд в двое (в сравнении с любыми ФС без сжатия) и при использовании многопоточного, последовательного чтения, значительно сокращает нагрузку на дисковую подсистему.

Приветствуем Хабр!

Спешим продолжить неделю хороших новостей из мира Opensource! Праздник на улице адептов открытого ПО продолжается.



Вы должно быть заметили, что с недавних пор в ReactOS ведется серьезная работа над поддержкой различных файловых систем. На текущий момент поддерживается Ext2\3\4, NTFS на чтение (уже готовится патч «на запись»), BTRFS, ReiserFS и FFS готовят к включению. Активно обновляется универсальный драйвер ATA-устройств — UniATA. Все это оживление произошло неспроста.

Дело в том, что мы уже длительное время вели переговоры с корпорацией EMC о возможном сотрудничестве и прилагали все усилия, чтобы доказать наличие скрытого потенциала роста в нашем проекте. В вот наконец было достигнуто принципиальное соглашение о том, что EMC возьмет проект ReactOS под патронаж. Нет, ни о какой потере самостоятельности речь не идет, а только целенаправленном о стимулировании разработки, свободное ПО должно оставаться свободным. Просто в корпорации вслед за примером лидеров в других секторах рынка программного обеспечения с новой силой уверовали в силу открытого ПО и решили не отставать от новейших тенденций.

7 сентября 2016 года около полуночи по московскому времени команда ReactOS продемонстрирует свой «старый» новый релиз операционной системы. Ожидается, что со сцены покажут разные новые прорывные или не очень фишки. Часть информации уже утекла в СМИ, но вы держитесь там, готовьте поп-корн и тухлые помидоры.

16 августа 2016 г. после трёх месяцев разработки состоялся релиз операционной системы ReactOS 0.4.2, нацеленной на обеспечение совместимости с программами и драйверами Microsoft Windows. В списке изменений свежей версии значится более 150 исправленных ошибок.

При активной разработке ПО нередко нужна тестовая база с актуальными данными из боевой базы. Хорошо, если база маленькая и развернуть копию не долго. Но если в базе десятки гигабайт данных и все нужны для полного тестирования, да ещё и посвежее, то возникают трудности. В этой статье я опишу вариант преодоления подобных неприятностей с помощью snapshot-ов btrfs. А управлять работой получившегося комплекса будет systemd – удобный и функциональный инструмент.

ZFS должна быть классной, но меня немного бесит, что она словно застряла в прошлом — даже до того, как её признали крутой и лучшей файловой системой. Она негибкая, ей не хватает современной интеграции с флеш-памятью и она не поддерживается напрямую большинством операционных систем. Но я храню все свои ценные данные на ZFS, поскольку именно она обеспечивает наилучший уровень защиты для условий SOHO (малый офис/домашний офис). И вот почему.

Первая директива систем хранения: не возвращать неправильные данные!

Прим перев.: Автор оригинальной статьи — испанский Open Source-энтузиаст nachoparker, развивающий проект NextCloudPlus (ранее известен как NextCloudPi), — делится своими знаниями об устройстве дисковой подсистемы в Linux, делая важные уточнения в ответах на простые, казалось бы, вопросы…

Сколько пространства занимает этот файл на жёстком диске? Сколько свободного места у меня есть? Сколько ещё файлов я смогу вместить в оставшееся пространство?



Ответы на эти вопросы кажутся очевидными. У всех нас есть инстинктивное понимание работы файловых систем и зачастую мы представляем хранение файлов на диске аналогично заполнению корзины яблоками.

Однако в современных Linux-системах такая интуиция может вводить в заблуждение. Давайте разберёмся, почему.

Привет, Хабр!

Меня зовут Виктор, и в этом году я единственный студент в программе Google Summer of Code на проекте ReactOS. Сегодня я расскажу немного о том, что я делаю в рамках стажировки.

ReactOS поддерживает кучу всяких разных файловых систем для чтения и записи (fat32, ext2, ReiserFS, BTRFS), однако загружаться до сих пор умеет только с раздела, отформатированного в fat32. Этой весной я решил что пора начать исправлять эту ситуацию, и подал заявку на GSoC. И вот, спустя несколько месяцев я пишу этот пост :)

Почему BTRFS? Ответ прост — драйвер файловой системы WinBtrfs на текущий момент самый стабильный и полнофункциональный из всех, что включены в код РеактОС. На данном этапе, мы хотим пофиксить именно баги ядра, которые мешают использовать другие ФС для загрузки, так что баги драйвера ФС нам тут совсем ни к чему.

Привет, Хабр! В этой серии мы продолжаем усиленно дружить драйвер WinBtrfs с ReactOS.


А этот ваш Windows так умеет?