Hacker News Digest

• Обсуждение началось с замечания о том, что ссылка с якорем в обход дубликат-детектора HN указывает на баг в самом HN, который стоит починить.
• Участники обсуждали, стоит ли TernFS в продакшене на практике, особенно в сравнении с Lustre и CephFS, и упоминались такие темы как лицензия, дисклеймер о поддержке и отсутствии RDMA и страйпинга.
• Несколько комментаторов отметили, что TernFS не предоставляет никаких преимуществ перед существующими решениями, и что она не является распределённой, а потому не может заменить Lustre, CephFS или даже ZFS.
• Также было отмечено, что TernFS не имеет никакой фичей, которые бы отличали его от других систем, и что она не является open-source, что делает её непригодной для HPC-сообщества.
• В конце обсуждение сошлось на то, что TernFS не предоставляет никаких преимуществ перед существующими решениями, не является open-source, и не имеет никаких уникальных фичей, кроме как маркетинговая страница.

Судя по данным, жесткие диски действительно стали надежнее. Исследование Backblaze, ведущего поставщика облачных сервисов, показывает, что современные диски служат дольше и стабильнее работают в течение жизненного цикла.

Первоначальная модель "ванны" (bathtub curve) предполагала три фазы: ранние отказы, стабильный период и рост отказов по мере износа. Но данные Backblaze за 13 лет показывают, что современные диски начинают с минимальным числом ранних отказов, затем работают годами без сбоев, и только позже начинают увеличивать частоту отказов. Это больше похоже на пологий склон, чем на ванну.

В частности, средний возраст дисков в пуле Backblaze увеличился с 6-8 месяцев в 2013 году до 6-7 лет в 2024. При этом годовая норма отказов снизилась с 6,39% в 2014 году до 1,17% в 2024. Это демонстрирует значительное улучшение надежности, даже с учетом роста объема данных и изменения состава пула дисков.

Основные выводы:

• Современные диски имеют минимальные ранние отказы, что указывает на улучшенный контроль качества.
• Период стабильной работы удлинился, иногда до 8 лет и более.
• Даже при увеличении срока службы, годовая норма отказов снижается, что подтверждает улучшение надежности.

Это подтверждается данными Backblaze, которые включают миллионы дней работы диска. Тенденция ясна: диски не просто служат дольше; они стабильнее на протяжении всего срока службы.

• Обсуждение охватывает широкий спектр тем: от анализа отказов жестких дисков и их долговечности до стратегий резервного копирования и восстановления данных, включая использование ZFS, RAID и облачных хранилищ.
• Участники обмениваются личным опытом и мнениями о надежности различных производителей и моделей HDD и SSD, а также обсуждают влияние условий эксплуатации на срок службы накопителей.
• Обсуждаются практические аспекты, такие как стоимость, энергопотребление и плотность хранения данных, а также влияние технологических усовершенствований на эти параметры.
• Участники также затрагивают тему долгосрочного хранения данных, включая использование оптических носителей, магнитной ленты и облачных сервисов, и обсуждают их достоинства и недостатки.
• В обсуждении также поднимается вопрос о том, какие факторы влияют на отказы накопителей и какие меры можно предпринять для обеспечения целостности данных, включая использование корректных файловых систем и регулярное тестирование состояния накопителей.

Четыре года назад я с коллегами снял 3-минутный ролик, в котором 12 USB-флешек и ZFS спасают мир. Видео стало культовым: более 100 000 просмотров, демонстрации на выставках, в блогах и докладах. Но качество на YouTube оставляло желать лучшего, а оригинальный файл в 720p исчез вместе с сервером Sun Mediacast. Я перезалил ролик на Vimeo, где теперь доступны обе версии: английская и немецкая.

ZFS по-прежнему уникален: за секунды конфигурируемый пул, математическая целостность, копирование-на-запись, мгновенные снапшоты и клоны. И это всё ещё не имеет себе равных.

• Пользователи обсуждают, как технологии за последние 15 лет изменились в плане производительности: сервер 2007 года с 4 ядрами и 16 ГБ ОЗУ сегодня выглядит как ноутбук, а 24 ТБ дискового пространства теперь можно получить на одном диске.
• Обсуждается, почему дистрибутивы по-прежнему используют EXT4 вместо ZFS, несмотря на его преимущества в сжатии, контрольных суммах и защите от битрот.
• Участники спора отмечают, что ZFS не может быть включён в ядро Linux из-за лицензионных ограничений, что мешает ему стать стандартной файловой системой.
• Также поднимается вопрос о том, что рост объёма HDD замедлился и не оправдал ожиданий 1980-х годов.

Автор успешно развернул самодельный S3-совместимый сервер на 10 ТБ, используя б/у Framework-ноутбук без экрана и внешний JBOD-массив дисков. В качестве ПО выбраны ZFS для файловой системы и Garage S3 для объектного хранилища. Система стабильно работала автономно несколько месяцев, накопив 10 ТБ данных, а после перезагрузки и обновления Garage с v1 до v2 продолжила работу без сбоев.

Изначально возникали проблемы из-за хранения метаданных SQLite на JBOD, подключённом по USB, что вызывало ошибки ZFS при высокой нагрузке. Решением стало перенос метаданных на внутренний накопитель ноутбука. Проект демонстрирует, что даже нестандартные конфигурации могут быть надёжными при грамотной настройке.

• Обсуждаются альтернативы для создания домашнего NAS: использование старого ноутбука Framework в корпусе Cooler Master, Raspberry Pi с LVM2, Dell T30 с ZFS или готовые решения вроде Ubiquti.
• Сравниваются S3-совместимые объектные хранилища: Minio (критика из-за урезания бесплатной версии), Garage (простота настройки), Ceph (сложность, но гибкость) и SeaweedFS (меньше ручной конфигурации).
• Поднимаются вопросы о конфигурации ZFS (использование RAIDZ1, зеркал, отправка снапшотов) и её пригодности для USB-подключений, а также альтернативах вроде btrfs.
• Обсуждаются сценарии использования самодельного S3: бэкапы (включая гибридные сценарии с AWS Glacier), хранение логов, APK и медиатеки.
• Высказываются опасения по поводу надежности JBOD over USB, рисков потери данных при случайном отключении и отсутствия избыточности для метаданных.

Автор столкнулся с критической проблемой при шифровании пула ZFS: после переноса зашифрованных снапшотов с промежуточного пула sneakernet обратно на основной old данные оказались нерасшифровываемыми. Оказалось, что ZFS неявно создаёт зависимость от encryptionroot — исходного пула, где данные были впервые зашифрованы. В данном случае этим пулом был sneakernet, а не old, поэтому при попытке расшифровать данные на old система не смогла найти нужный ключ.

Ключевая деталь: ZFS передаёт метаданные о encryptionroot при операциях send/receive, даже если данные отправляются в raw-формате. Это привело к тому, что после удаления промежуточного пула sneakernet данные на old стали недоступны, так как система искала ключ от уже несуществующего источника. Автору удалось восстановить доступ, модифицируя исходный код ZFS для ручного создания bookmark и обновления метаданных, что подчёркивает важность понимания внутренней работы encryptionroot перед выполнением сложных операций с шифрованием.

• Пользователи обсуждают сложности и риски использования нативного шифрования ZFS, приводя примеры потери данных из-за ошибок в управлении ключами и снимками.
• Поднимаются вопросы о сравнении ZFS с альтернативами (LUKS+mdadm, Storage Spaces), отмечая преимущества ZFS в эффективности сжатия и производительности, но критикуя его сложность и отсутствие дружелюбного интерфейса.
• Обсуждается важность тестирования резервных копий и необходимость осторожности при использовании зашифрованных наборов данных, особенно при смене паролей или ключей.
• Упоминаются случаи успешного использования ZFS в течение многих лет без потерь данных, но с оговорками о необходимости строгого следования документации.
• Критикуется reliance на Stack Overflow и ИИ для решения сложных задач, поскольку это может привести к необратимым ошибкам из-за некорректных советов.

Файловая система Bcachefs полностью удалена из основного ядра Linux, начиная с версии 6.18. Это решение связано с тем, что разработка переместилась во внешний модуль DKMS, что сделало встроенную версию устаревшей и потенциально вызывающей путаницу. Ранее, в релизе 6.17, система уже была помечена как внешне поддерживаемая.

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

• Пользователи выражают разочарование удалением bcachefs из основной ветки ядра Linux из-за конфликта между его разработчиком и сообществом.
• Обсуждаются технические последствия перехода на DKMS-модуль: необходимость настройки для Secure Boot, потенциальные проблемы с будущими обновлениями ядра.
• Участники сравнивают bcachefs с другими файловыми системами (Btrfs, ZFS), отмечая его потенциал, но критикуя текущую производительность и стабильность.
• Основная причина удаления видится не в технических недостатках, а в неспособности сопровождающего соблюдать правила разработки ядра.
• Высказываются надежды на возврат bcachefs в основную ветку в будущем с другим сопровождающим и после достижения большей стабильности.

В PostgreSQL 18 появилась поддержка асинхронного ввода-вывода (AIO), что позволяет эффективнее использовать хранилище. Основные параметры для настройки — io_method и io_workers. По умолчанию io_method = worker использует пул процессов для выполнения операций ввода-вывода, что обеспечивает кроссплатформенность и стабильность. Альтернатива io_uring эффективнее, но работает только на Linux и может быть недоступна в некоторых контейнерах из-за проблем безопасности.

Значение io_workers = 3 слишком консервативно для серверов с большим количеством ядер. Рекомендуется увеличивать его пропорционально числу CPU, особенно для интенсивных рабочих нагрузок. Например, на системе с 64 ядрами можно установить 16–32 воркеров. Важно тестировать настройки под конкретную нагрузку, так как универсального решения нет.

• Ожидание тестирования новой функции async I/O на базах данных в Azure с использованием ZFS для повышения производительности последовательного сканирования.
• Обсуждение выбора метода worker по умолчанию вместо io_uring из-за его универсальности и проблем безопасности с io_uring в некоторых средах.
• Вопрос о причинах более низкой производительности io_uring в сравнении с worker в некоторых бенчмарках и является ли это ошибкой или ограничением технологии.
• Дебаты о целесообразности использования CoW-файловых систем (например, ZFS, btrfs) для Postgres и сжатия на уровне ФС против встроенного сжатия СУБД.
• Уточнение, что новая функция async I/O сейчас применяется только для последовательных и bitmap-сканирований, но не для индексных.

RedoxFS — это файловая система по умолчанию для операционной системы Redox, вдохновлённая ZFS, но адаптированная под микроядро. Она заменила монолитный драйвер ZFS, который не подходил из-за архитектурных ограничений. Система поддерживает копирование при записи, контрольные суммы данных и метаданных, прозрачное шифрование и стандартные атрибуты файлов Unix.

Ограничения включают размер файла до 193 ТБ и до 4 миллиардов файлов на томе. RedoxFS совместима с Redox и Linux через FUSE, а также поддерживает полное шифрование диска на уровне загрузчика. Это пример того, как современные концепции хранения данных адаптируются под безопасные и модульные операционные системы.

• Высказываются опасения по поводу сложности и надежности создания собственной файловой системы, сравнимой с ZFS или btrfs, для проекта Redox OS.
• Обсуждаются технические проблемы интеграции монолитной архитектуры ZFS с микрокернельным дизайном Redox, а также возможные альтернативы.
• Отмечается, что Redox OS является в большей степени исследовательским проектом и инкубатором идей для экосистемы Rust, а не готовой к производству ОС.
• Поднимаются вопросы о практической применимости Redox на реальном железе, поддержке оборудования и лицензионных ограничениях.
• Упоминаются другие нишевые ОС и файловые системы (например, Genode, HAMMER2) как возможные источники вдохновения или альтернативы.

Disk Utility в macOS Monterey 12.0.1 по-прежнему не может проверять и восстанавливать APFS-тома и контейнеры из-за ошибки размонтирования. Проблема сохраняется с момента появления APFS и усугубилась в последней версии системы: утилита выдаёт бессмысленные сообщения об ошибках вместо признания бага. Интересно, что HFS+ тома остаются unaffected.

Обходное решение — запуск в режиме Recovery для проверки загрузочных томов или прямое использование терминальной команды fsck_apfs. Paradoxically, Disk Utility может размонтировать том вручную, хотя не способен сделать это автоматически во время проверки. Рекомендуется сначала размонтировать том через интерфейс, затем выполнить fsck_apfs -y для восстановления или -n для проверки, включив снапшоты опцией -S при необходимости. Для зашифрованных томов можно использовать -l или разблокировать без монтирования через diskutil apfs unlockVolume.

• Пользователи столкнулись с проблемами файловой системы APFS в macOS, включая невозможность изменения размера разделов и повреждение резервных копий Time Machine
• Критикуется низкое качество файловых систем Apple (HFS+, APFS) и сетевых функций, особенно при работе с Samba
• Отмечается отсутствие реакции Apple на сообщения о багах и приоритизация функций для массового пользователя в ущерб остальным
• В качестве рабочих решений упоминаются утилиты fsck_apfs и diskutil unlock volume для исправления ошибок
• Обсуждаются исторические причины проблем (отказ от ZFS) и предлагаются альтернативы вроде NFS вместо Samba

• bcachefs переведён в статус externally maintained — Линус отметил, что новые изменения в mainline маловероятны, но немедленного удаления файловой системы из ядра не планируется.
• Суть конфликта: не лицензия и не технические проблемы, а личные разногласия Линуса и других разработчиков с автором bcachefs Кентом Оверстритом.
• Возможные сценарии
  • Найти нового мейнтейнера, который будет выступать посредником между Кентом и ядром.
  • Риск: такой человек может выгореть, повторив конфликт «по доверенности».
  • Альтернатива — форк ядра без участия Кента, но Линусу это, судя по всему, неинтересно.
• Позиция Кента: он не хочет перекладывать ответственность на коллег-разработчиков, чтобы не потерять ещё одного инженера, и настаивает на контроле качества релизов, так как сам обрабатывает большинство баг-репортов.

• Btrfs по-прежнему не догнал ZFS по надёжности и функционалу, а уход Josef Bacik из Meta усиливает тревогу за его будущее.
• bcachefs остаётся в ядре, но из-за конфликта Kent Overstreet с процессом слияния патчей его обновления теперь могут идти вне основного дерева (DKMS/сторонние репозитории).
• Участники обсуждают высокий «bus-factor» bcachefs (разработка почти одним человеком) и сравнивают ситуацию с ZFS, который стабильно работает на FreeBSD и некоторых Linux-дистрибутивах.
• Некоторые пользователи рассматривают переход на FreeBSD или возврат к проверенным схемам LVM+XFS из-за нестабильности btrfs и проблем bcachefs.

• Почему Pi?
  На слабом железе быстрее всплывают ошибки конфигурации, поэтому эксперимент с TrueNAS на Pi 5 — отличный способ учиться.

• Проблема: нет UEFI
  Pi официально не поддерживает UEFI. Используем форк rpi5-uefi.

• Подготовка Pi 5

  1. Обновите EEPROM до ≥ 2025-06-09 (sudo rpi-eeprom-update -a, при необходимости переключитесь на beta-канал).
  2. Скачайте последний релиз rpi5-uefi, распакуйте содержимое .zip в FAT32-раздел microSD.
  3. Вставьте карту, подключите HDMI, включите Pi. Должен появиться EDK2 Boot Manager.

• Установка TrueNAS

  1. Скачайте ARM-образ TrueNAS (например, 25.04.2) с truenas-releases.jmay.us.
  2. Запишите ISO на USB-накопитель (Etcher).
  3. Загрузитесь с USB через UEFI Boot Manager.
  4. Установите TrueNAS на любой диск, кроме microSD и установочной флешки (второй USB или NVMe).

• Кто-то давно отказался от TrueNAS/FreeNAS в пользу самостоятельной настройки Samba+NFS+ZFS на мини-ПК.
• Многие считают Raspberry Pi слабым и ненадёжным для NAS: проблемы с SATA/USB, отсутствие ECC, низкая пропускная способность.
• Другие успешно годами держат Pi-4 с Ubuntu+Samba+Jenkins, но используют внешние USB-хабы и не нагружают систему.
• TrueNAS критикуют за громоздкий UI, «лагающие» бэкапы Time Machine и лишний оверхед на слабом железе.
• Часть участников предпочитают готовые решения (QNAP, Synology) или Proxmox+ZFS на Intel N100: быстрее, стабильнее, проще.

Tribblix — ретро-дистрибутив на базе illumos от Питера Трибла.
Свежее: 13 июля 2025 — релиз Milestone 37 (x86, варианты Vanilla и LX).
SPARC: 29 июля 2025 — обновление m32→m33; свежие установки пока через m32 ISO.
SPARC-CD: 15 мая 2025 — ISO m32 помещается на CD.
Поддержка 32-битного железа полностью прекращена. SPARC-версия тестируется слабо, x86 стабилен.
Скачать, установить и использовать можно по ссылкам на сайте.

• Участники обсуждают нишевые ОС (Tribblix, Dragonfly BSD, Haiku, RISC OS, 9front, MINIX) и их «невидимость» на фоне мейнстрима.
• Solaris Zones/LX-контейнеры хвалят за удобство, но установка Illumos-дистрибутивов часто страдает из-за проблем с USB3 и современным «железом».
• Поднимается идея слоя совместимости Linux-драйверов, но критика: это влечёт GPL-проблемы и наследование архитектурных ограничений Linux.
• Совместимость ZFS: пулы Illumos читаются Linux/FreeBSD, но не наоборот, если используются новые фич-флаги OpenZFS.
• Tribblix предлагает 30+ оконных сред, включая CDE и OpenLook, но без старого DeskSet.