LINUX.ORG.RU

Fedora 33 Test Week — Btrfs

 , ,


0

3

Проект Fedora анонсировал проведение «Test Week» (недели тестирования). Мероприятие продлится с 31 августа по 07 сентября 2020 года.

В рамках «Test Week» все желающие приглашаются протестировать следующий релиз Fedora 33 и отправить результаты разработчикам дистрибутива.

Для тестирования необходимо установить систему и выполнить несколько стандартных операций. Затем необходимо отчитаться о результатах через специальную форму.

Согласно wiki мероприятия, тестирование допускается проводить в виртуальной машине. Для тестирования доступны сборки архитектур x86 и aarch64.

Основной акцент предстоящей недели сделан на Btrfs. В Fedora 33 эта файловая система будет предлагаться установщиком по умолчанию. В предыдущих версиях Fedora по умолчанию предлагалась файловая система ext4.

В числе особенностей Btrfs по сравнению с ext4, стоит отметить следующие:

  • Copy-on-write. В случае с файловой системой ext4, новые данные записываются поверх старых. Btrfs позволяет записывать новые данные, оставляя старые данные в неприкосновенности. Благодаря этому появляется возможность восстановить систему или данные в случае сбоя.

  • Snapshots. Эта технология позволяет сделать “снимок” файловой системы для последующего отката изменений.

  • Subvolumes. Файловая система Btrfs может быть разбита на так называемые subvolumes (субтома).

  • Поддержка компрессии, что позволяет не только сжимать файлы, но так же снизить число обращений к диску.

Анонс:
https://fedoramagazine.org/contribute-at-the-fedora-test-week-for-Btrfs/

Русскоязычная поддержка: в Matrix-чате #russianfedora:matrix.org

>>> Подробности

Copy-on-write. В случае с файловой системой ext4, новые данные записываются поверх старых. Btrfs позволяет записывать новые данные, оставляя старые данные в неприкосновенности. Благодаря этому появляется возможность восстановить систему или данные в случае сбоя.

Звучит так, что с ext4 после сбоя система не восстанавливается, что есть откровенная чушь.

anonymous ()
Ответ на: комментарий от anonymous

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

cross_platform ()
Ответ на: комментарий от cross_platform

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

Петросян.JPG

anonymous ()
Ответ на: комментарий от anonymous

Не могли бы вы, так сказать, немного элеборейтнуть (eleborate) вашу мысль.

cross_platform ()

Благодаря этому появляется возможность восстановить систему или данные в случае сбоя.

вот только полноценных инструментов для восстановления после сбоя до сих пор нет

eternal_sorrow ★★★★★ ()

Зачем это на десктопе? А, ну да, надо же потестить для другой шапочки (IBM)

Vault_Boy ()
Ответ на: комментарий от Vault_Boy

На десктопе Btrfs очень даже нужна. Если вы используете компьютер в качестве рабочего инструмента, то вы должны оценить возможность практически моментального восстановления работоспособности в случае сбоя.

cross_platform ()
Ответ на: комментарий от anonymous

С Btrfs или LVM такие случаи - это контролируемый хаос. Другой вопрос, что Btrfs обеспечивает быстрый откат, а вот LVM более задумчив.

cross_platform ()
Ответ на: комментарий от anonymous

остаётся, только, надеяться, что, таких, случаев, не, будет..

Я починил

anonymous ()
Ответ на: комментарий от anonymous

плохо ты починил: вот, на - на кончике ещё осталась

anonymous ()
Ответ на: комментарий от cross_platform

Есть подозрение что вы не до конца понимаете как происходит апдейт, но я с удовольствием послушаю как по вашему апдейт прерванные на средине приведет к неспособности загрузиться. Хотя не исключаю что у некоторых систем управления пакетами апдейты сломаны by design

st4l1k ★★ ()
Последнее исправление: st4l1k (всего исправлений: 2)
Ответ на: комментарий от cross_platform

Вполне загрузится, у ext4 же атомарная запись - либо записалось, либо нет

anonymous ()

В Fedora 33 эта файловая система будет предлагаться установщиком по умолчанию

Осталось сделать systemd-boot загрузчиком по умолчанию, переписать dnf на плюсы и получится годнота во все поля.

qtm ★★ ()
Ответ на: комментарий от cross_platform

Если вы используете компьютер в качестве рабочего инструмента, то вы должны оценить возможность практически моментального восстановления работоспособности в случае сбоя.

А lvm на кой придумали ?

Btrfs глючный и ненужен

anonymous ()
Ответ на: комментарий от st4l1k

Позвольте вопрос? Вам никогда не доводилось читать на форумах, как люди после обновления грузятся в чёрный экран или не могут загрузиться вообще? Вот для этих случаев, в частности, и предусмотрены решения, вроде Btrfs snapshots.

cross_platform ()
Ответ на: комментарий от cross_platform

Lvm очень медленно откатывает snapshot. зато откатывает а бтрфс глючная херь

anonymous ()
Ответ на: комментарий от anonymous

Я понял вашу мысль. Но, btrfs обкатан в production и уже нет причин не доверять этой файловой системе.

cross_platform ()
Ответ на: комментарий от cross_platform

На самом деле это может не сработать, если во время создания снапшота какие-то файлы активно менялись. Скорее всего в снапшот попдет полувалидный файл. Но ребята знают, как важные файлы менять: через переименование.

anonymous ()
Ответ на: комментарий от cross_platform

Доводилось и даже больше, у меня не однократно такое было.(«Не было печали, апдейтов накачали»)

Вот для этих случаев, в частности, и предусмотрены решения, вроде Btrfs snapshots.

Все я понял про что вы ваша манса. Тогда вопрос снимаеться. Я просто подумал что вы про целостность fs что то хотели сказать.
Снимки да полезная вещь при апдейтах.

st4l1k ★★ ()
Последнее исправление: st4l1k (всего исправлений: 1)
Ответ на: комментарий от st4l1k

Ха, ха, шутник, «апдейт прерванные на средине приведет к неспособности загрузиться».

Вот у меня Ubuntu 18.04. Открываем Software&Updates, и устанавливаем галку напротив Nvidia driver. Перезагружаемся и вуа-ля. Загрузка останавливается на Gnome Desktop Manager. Linux для домохозяек, ага.

Как в этом случае поможет Btrfs? Никак, но подозреваю, что если штатное средство позволяет добиться незагружаемости, то уж при сбое питания все что угодно может произойти.

anonymous ()
Ответ на: комментарий от anonymous

Вот именно, часть файлов ядра/загрузчика записалось, а часть нет. В итоге получилась каша из несовместимых друг с другом файлов. А еще файл может быть испорчен. журнал на ext4 не гарантирует сохранность данных, а лишь гарантирует, что файловая система будет цела.

anonymous ()

Перекатился на btrfs на рабочем десктопе буквально сегодня. Пока что привыкаю к управлению subvolume-ами. После zfs с его снапшот/клон с одной стороны проще, с другой - несовсем, ибо сопоставление uuid/id subvolume в некоторых выхлопах делал наркоман - пришлось даже накостылять скрипт проверки места, занимаемого subvolume-ом, где сразу видно и его id и куда он примонтирован. Ну и покоробило, что qgroup для нового subvolume рожается автоматически, а вот при удалении - остаётся висеть «в воздухе», пока сам не подчистишь. Очень ынтерпрайзно, ага...

Привыкшим к zfs с независимыми наборами опций для каждой ФС стоит охладить пыл - опции в btrfs, как я понял, обычно распространяются по принципу «хто первый смонтировал, того и тапки». Для выборочного сжатия и выборочного отключения CoW предлагают выкручиваться с помощью chattr, что у неподготовленного может вызвать взрыв мозга. TL;DR - subvolume в btrfs - просто по функционалу чуть прокачанная директория, не больше. Аналогов zfs volume(блочных устройств со снапшотами) тоже не завезли. Зато радует reflink, тут вам не ZFS, где копирование между ФС внутри пула кладёт болт на CoW.

Короче, вполне себе годная ФС. Помню как плевался от нее в 2015 кажись, ну так за 5 лет она шагнула вперед, совсем детских болячек уже вроде как нет.

Правда в этих ZFS и btrfs пугает отсутствие нормального fsck - его либо нет вообще(как в ZFS, ибо «юзайте scrub и будет вам щастье»), либо он такой из себя не очень(«используйте btrfsck --repair на свой страх и риск! и без бэкапа даже не начинайте!»)

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 2)
Ответ на: комментарий от anonymous

Вот у меня Ubuntu 18.04. Открываем Software&Updates, и устанавливаем галку напротив Nvidia driver. Перезагружаемся и вуа-ля. Загрузка останавливается на Gnome Desktop Manager. Linux для домохозяек, ага.

В контексте btrfs vs ext4. Ваш случай это из разряда блеск и нищета Open Source ))

st4l1k ★★ ()
Ответ на: комментарий от GAMer

https://news.ycombinator.com/item?id=14907771

Редхат берет одну версию ядра и тянет ее годами. BTRFS слишком быстро меняется + в самом редхате не осталось экспертов по ней.

Данный проект (внедрение BTRFS в федору) пропихивают люди из фейсбука. Разрыв шаблона, да?

Midael ★★★★★ ()
Ответ на: комментарий от anonymous

Перед установкой Nvidia драйвера, вам нужно создать snapshot. Если вы загрузились в чёрный экран или не можете загрузиться вообще, откатываетесь на сделанный snapshot при помощи, например, live usb. А если у вас настроен snapper, то он вам предложит загрузиться в сделанный ранее snapshot в меню grub.

cross_platform ()
Ответ на: комментарий от cross_platform

Не знаю, как там в Fedora, но в Suse давно все сделано. При установках ПО делаются снапшоты автоматом, а из граба можно загрузиться на нужный снапшот, а потом восстановиться на него при желании. Кроме того, по умолчанию нужные директории разбиты на subvolumes.

anonymous ()
Ответ на: комментарий от cross_platform

В принципе с live usb можно и без снапшота обойтись. Возможно что с ним удобнее - не надо думать что делать - откатился и все.

Но ведь нужно знать что установка NVidia драйвера - небезопасная операция (чтобы создать снапшот). Раньше в Ubuntu с этим проблем не было.

P.S. Эх, хотел я OpenSuse вместо Ubuntu установить (там btrfs по умолчанию).

anonymous ()
Ответ на: комментарий от cross_platform

Я немного не о том.

Вот смотри, в btrfs qgroup show у нас есть id subvolume-а, к которому привязана группа квоты. UUID-ов нет.

В btrfs subvolume list уже можно увидеть и uuid и parent uuid, и собственно id самого subvolume(если ключи нужные расчехлить). Там уже можно понять где снапшоты, а где нет(и всё равно мне подход с ZFS со статическим именованием снапшотов через @ импонирует больше - ибо он проще).

А теперь на сладкое - как получить аналог вывода df для subvolume-ом btrfs встроенными командами...

Нуууу... как-то так:

#!/bin/bash

# Show mountpoint for all btrfs quota groups

IFS=""
while read LINE; do
        ID=$(echo ${LINE} | awk '{ print $1;'})
        SUBVOLID="${ID/'0/'/}"
        echo -ne ${LINE}
        # Add header
        if [[ "${ID}" = "qgroupid" ]]; then
                echo -ne "\t mountpoint"
        fi
        # If qgroupid is level-0(default) for subvolume...
        if [[ ! "${SUBVOLID}" = "${ID}" ]]; then
                mount | awk /subvolid="${SUBVOLID}"/'{ printf "\t %s",$3; }'
        fi
        echo
done < <(btrfs qgroup show -r -e -p /)

TL;DR - в отличие от ZFS(с командой zfs list, ибо df там тоже выдает дичь как и в btrfs - судя по всем для всех CoW FS это норма), заскриптоваться пришлось побольше

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от Pinkbyte

совсем детских болячек уже вроде как нет.

Судя по переписке в федорином devel с участием одного из разработчиков btrfs, некоторые вещи они по активно дочинивают, например небезызвестный ENOSPC на метаданных.

Привыкшим к zfs с независимыми наборами опций для каждой ФС стоит охладить пыл - опции в btrfs, как я понял, обычно распространяются по принципу «хто первый смонтировал, того и тапки». Для сжатия и выборочного отключения CoW предлагают выкручиваться с помощью chattr, что у неподготовленного может вызвать взрыв мозга.

Там первая опция распространяется на все сабвольюмы раздела. COW отключить можно на директории, либо при создании файла (в virt-manager и около они в этом цикле внесли патч, который выключает COW на новых образах). Но если попадает в снапшот, то включается обратно

Дружественность к пользователю пока так себе. Снапшотов в этом релизе не будет. Графические тулзы от сабволюмов сходят с ума. Может хоть документацию запилят...

Midael ★★★★★ ()
Ответ на: комментарий от cross_platform

Нет. Там показывается только весь размер ФС, мне же нужен размер данных на КАЖДОМ subvolume

Вот пример с рабочей машины:

oas1 ~ #  btrfs filesystem usage /
Overall:
    Device size:                 100.00GiB
    Device allocated:             72.52GiB
    Device unallocated:           27.48GiB
    Device missing:                  0.00B
    Used:                         70.04GiB
    Free (estimated):             28.23GiB      (min: 14.49GiB)
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:              102.62MiB      (used: 0.00B)

Data,single: Size:69.00GiB, Used:68.25GiB (98.91%)
   /dev/mapper/animelover-btrfs   69.00GiB

Metadata,DUP: Size:1.75GiB, Used:913.72MiB (50.99%)
   /dev/mapper/animelover-btrfs    3.50GiB

System,DUP: Size:8.00MiB, Used:16.00KiB (0.20%)
   /dev/mapper/animelover-btrfs   16.00MiB

Unallocated:
   /dev/mapper/animelover-btrfs   27.48GiB

А это - результат моего скрипта:

oas1 ~ # ./btrfs_show_quota.sh
qgroupid         rfer         excl     max_rfer     max_excl parent      mountpoint
--------         ----         ----     --------     -------- ------
0/5          16.00KiB     16.00KiB         none         none ---
0/259        11.35GiB     11.35GiB         none         none ---         /
0/289       210.61MiB    210.61MiB         none         none 1/289       /usr/portage
0/296         1.62GiB      1.62GiB         none         none 1/289       /usr/portage/distfiles
0/297         3.62GiB      3.62GiB         none         none 1/289       /usr/portage/packages
0/298        16.00KiB     16.00KiB     10.00GiB         none ---         /var/tmp/portage_noram
0/304        27.55GiB     27.55GiB     50.00GiB         none ---         /home/pinkbyte/cloud
0/332        16.00KiB     16.00KiB         none         none ---         /home/pinkbyte/torrents
0/334        10.05GiB     10.05GiB         none         none ---         /home
0/353        14.64GiB     14.64GiB         none         none ---         /backup
1/289         5.44GiB      5.44GiB     15.00GiB         none ---

P.S. Так как это была миграция с кучки ext4(и reiserfs на /, лол), которые располагались на LVM - btrfs у меня тоже живет поверх LVM. Да, я извращенец :-)

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

btrfs у меня тоже живет поверх LVM. Да, я извращенец

зато можно делать дабл снапшот

anonymous ()
Ответ на: комментарий от cross_platform

Да ты что! А ты думаешь я не пробовал?

oas1 ~ #  btrfs filesystem usage /
Overall:
    Device size:                 100.00GiB
    Device allocated:             72.52GiB
    Device unallocated:           27.48GiB
    Device missing:                  0.00B
    Used:                         70.04GiB
    Free (estimated):             28.23GiB      (min: 14.49GiB)
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:              102.62MiB      (used: 0.00B)

Data,single: Size:69.00GiB, Used:68.25GiB (98.91%)
   /dev/mapper/animelover-btrfs   69.00GiB

Metadata,DUP: Size:1.75GiB, Used:913.72MiB (50.99%)
   /dev/mapper/animelover-btrfs    3.50GiB

System,DUP: Size:8.00MiB, Used:16.00KiB (0.20%)
   /dev/mapper/animelover-btrfs   16.00MiB

Unallocated:
   /dev/mapper/animelover-btrfs   27.48GiB
oas1 ~ #  btrfs filesystem usage /usr/portage
Overall:
    Device size:                 100.00GiB
    Device allocated:             72.52GiB
    Device unallocated:           27.48GiB
    Device missing:                  0.00B
    Used:                         70.04GiB
    Free (estimated):             28.23GiB      (min: 14.49GiB)
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:              102.62MiB      (used: 0.00B)

Data,single: Size:69.00GiB, Used:68.25GiB (98.91%)
   /dev/mapper/animelover-btrfs   69.00GiB

Metadata,DUP: Size:1.75GiB, Used:913.72MiB (50.99%)
   /dev/mapper/animelover-btrfs    3.50GiB

System,DUP: Size:8.00MiB, Used:16.00KiB (0.20%)
   /dev/mapper/animelover-btrfs   16.00MiB

Unallocated:
   /dev/mapper/animelover-btrfs   27.48GiB

Найдешь 10 отличий?

TL;DR - btrfs filesystem работает в контексте ВСЕЙ ФС, а путь нужен только чтобы определить какую именно ФС смотреть(если у нас их несколько, именно самих ФС, не subvolume внутри). На subvolume оно не смотрит

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 2)

Буквально сегодня поставил на новый комп Fedora Server 33 (EFI, все дефолт, шифрованный корень), получил какого-то хрена XFS на LVM. Благо в XFS завезли reflink=1 по умолчанию, а то бы переставлял.

t184256 ★★★★★ ()
Ответ на: комментарий от t184256

Благо в XFS завезли reflink=1 по умолчанию, а то бы переставлял.

Я смотрю RedHat со своей Stratis реально пинает XFS в правильную сторону :-)

К сожалению для меня невозможность уменьшить размер XFS - это ломающая фича :-(

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от Midael

пропихивают люди из фейсбука

Это-то понятно, неясно, почему IBM/RH позволяют такое творить в своём тестовом полигоне. Всё таки думают когда-то поддерживать её?

GAMer ★★★★★ ()
Ответ на: комментарий от t184256

Буквально сегодня поставил на новый комп Fedora Server 33 (EFI, все дефолт, шифрованный корень), получил какого-то хрена XFS на LVM.

Btrfs только на Workstation включают. Так что всё логично.

alpha ★★★★★ ()
Ответ на: комментарий от Pinkbyte

Вы, вероятно, не совсем правильно пользуетесь командой «btrfs filesystem usage».
Наберите “sudo btrfs subvolume list /”. Эта команда покажет имена субтомов.
И именно эти имена подавайте на вход команде “btrfs filesystem usage название субтома”

cross_platform ()
Ответ на: комментарий от GAMer

почему IBM/RH позволяют такое творить в своём тестовом полигоне

И тут, внезапно и совершенно неожиданно, оказывается что Fedora - это проект сообщества, в котором решения принимаются выборным инженерным комитетом, а не компанией Red Hat.

alpha ★★★★★ ()
Ответ на: комментарий от cross_platform

Мммм... Точно? :-)

oas1 ~ #  btrfs subvolume list / | grep portage
ID 289 gen 1885 top level 5 path portage
ID 298 gen 1350 top level 5 path portage_noram

oas1 ~ #  btrfs filesystem usage portage
ERROR: cannot access 'portage': No such file or directory
oas1 ~ #  btrfs filesystem usage /portage
ERROR: cannot access '/portage': No such file or directory
oas1 ~ #  btrfs filesystem usage /portage_noram
ERROR: cannot access '/portage_noram': No such file or directory
oas1 ~ #  btrfs filesystem usage portage_noram
ERROR: cannot access 'portage_noram': No such file or directory

Как видишь только по полному пути(из выхлопа в предыдущем посте) куда примонтирована сама ФС или подтом что-то работает. Но при этом выдается ОДНА и та же информация - о всей ФС ЦЕЛИКОМ. И это не баг, это фича:

btrfs-filesystem - command group that primarily does work on the whole filesystems 

P.S. Я к слову не один такой велосипедостроитель, на Python всё уже изобрели до меня

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 3)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.