BTRFS. Готова ли к использованию в 16.04?

[Pilot6]

ALiEN175,
Вы все перепутали. При конвертации раздела в другую файловую систему никакие сектора никуда не деваются. Как было, так и осталось.

[Sly_tom_cat]

Кой какие мои персональные выводы из работы конвертатора.

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

Но, как по мне, лучше бы все-таки конвертатор создавал отдельный подтом, и уже в него "собирал" данные из ext4.
Так было бы удобнее ИМХО.

Само собой вернуть ext4 можно будет только с потерей изменений в btrfs, ведь это же снимок.


+++
Про снимки. Эта идея изначально родом из nilfs (на сколько я понимаю). Там впервые была реализована версионность метаданных ФС и на ее основе снимки. Ведь снимок это по сути определенная версия метаданных, тогда как основная фс уходит (своей версионностью) дальше. Однако при этом и данные, связанные метаданными снимка нужно оградить от перезаписи. Т.е. не только метаданные фиксируются, но еще и copy on write включается и все изменения пишутся на новые места. Но, все неизмененное берется со старого места хранения.

[ALiEN]

Pilot6,
может и перепутал, не важно. Может кому-то этот пост поможет. На данный момент есть подозрение, что при конвертации/форматировании системного раздела в btrfs, на этот диск с началом первого раздела на 63 невозможно поставить grub.
на ext4 такой проблемы не было, на btrfs появилась.

[Sly_tom_cat]

ALiEN175, Думаю проблемы установки GRUB в чем то другом...

[ALiEN]

Sly_tom_cat,
это всего лишь мой опыт)

[AnrDaemon]

ALiEN175, честно говоря не понял - при чем тут начало раздела вроде как конвертируется ФС на назделе а не что-то на диске....

Грубу нужно место, чтобы драйвер предзагрузки записать. В 62 сектора он не влезает.

[thunderamur]

Sly_tom_cat,
Pilot6,
Товарищ ALiEN175 не просто так пожаловался, что на то, что груб не ставится когда 1-й раздел с 63 сектора. Я с этим сталкивался ранее https://forum.ubuntu.ru/index.php?topic=269737.0
Образу GRUB с поддержкой btrfs не хватает места.
Пользователь решил продолжить мысль [time]02 Март 2016, 09:31:30[/time]:AnrDaemon,
Ты уже попробовал ZFS? Производительность не сравнивал? По надежности понятное дело пока btrfs не для продакшена, все-таки слишком молода.
Пользователь решил продолжить мысль [time]02 Март 2016, 11:19:26[/time]:В 16.04 доступен пакет apt-btrfs-snapshot

Код: [Выделить]

Automatically create snapshot on apt operations
 
This will create a btrfs snapshot of the root filesystem each time
that apt installs/removes/upgrades a software package.

A commandline tool called "apt-btrfs-snapshot" is also provided
for easy access create/list/delete snapshots.
Крутотень.
Пользователь решил продолжить мысль [time]02 Март 2016, 11:43:23[/time]:В btrfs возможна в будущем поддержка сжатия lz4
При том же коэффициенте сжатия, упаковка немного быстрее, а распаковка почти в 4 (!) раза быстрее!

Код: [Выделить]

Compressor Ratio Compression Decompression
memcpy 1.000 4200 MB/s 4200 MB/s
LZ4 fast 17 (r129) 1.607 690 MB/s 2220 MB/s
LZ4 default (r129) 2.101 385 MB/s 1850 MB/s
LZO 2.06 2.108 350 MB/s 510 MB/s
QuickLZ 1.5.1.b6 2.238 320 MB/s 380 MB/s
Snappy 1.1.0 2.091 250 MB/s 960 MB/s
LZF v3.6 2.073 175 MB/s 500 MB/s
zlib 1.2.8 -1 2.730 59 MB/s 250 MB/s
LZ4 HC (r129) 2.720 22 MB/s 1830 MB/s
zlib 1.2.8 -6 3.099 18 MB/s 270 MB/sТ.о. даже SSD не сможет нагрузить даже 1 ядро процессора при распаковке (чтении).

Также возможно появление lzma - очень медленно, но очень эффективно. Может найти применение для разделов под бекапы, например. Милое дело сливаешь образы без архиватора просто на ФС, которая отлично жмет. При необходимости смонтировал, да пошарил по бекапу. Кстати, пока для этих целей можно использовать zlib - раза в 1.5 эффективнее чем lzo сжимает, но медленнее чуть ли не в 10 раз.

[AnrDaemon]

Поскольку используются одинаковые алгоритмы, по скорости эти FS равны или почти равны.
Разница будет в наборе фич. И не в пользу BTRFS, для меня лично.
Все операции на ZFS рекурсивны по умолчанию. На BTRFS - нет.

[Sly_tom_cat]

AnrDaemon, ну так рекурсивность - как по мне так лучше я сам задам когда надо рекурсивно, бо оно не всегда нужно..

По набору фич ZFS скорее всего пока держит планку, но не надо забывать что btrfs сейчас на гребне - ее пилят, пилят, и пилят сотни разрабов, и фичастость btrfs уже сейчас очень приличная и растет с каждым днем, так что ZFS врятли сможет долго оставаться в одиночестве  на олимпе самой навороченной ФС

И не будем забывать - btrfs родилась как ответ на невозможность поменять лицензионную политику ZFS, которая не позволяет ей быть официально встроенной в ядро. И проект был изначально запланирован как реализация всех "вкусностей" ZFS, но под нормальной лицензией.

thunderamur, apt-btrfs-snapshot - это крутотень, надо будет затестить... больше всего меня интересует трет ли он старые снапшоты - а то так можно снапшотами выжрать место в разделе очень быстро.

[Karl500]

По apt-btrfs-shapshot: есть такой баг https://bugs.launchpad.net/ubuntu/+source/apt-btrfs-snapshot/+bug/1454306 (на сегодня пока не исправлен в 16.04), после небольшой правки, как предложено

Код: [Выделить]

diff /usr/lib/python3/dist-packages/apt_btrfs_snapshot.py-old /usr/lib/python3/dist-packages/apt_btrfs_snapshot.py
122c122
< if not os.path.exists("/sbin/btrfs"):
---
>         if not ( os.path.exists("/sbin/btrfs") or os.path.exists("/bin/btrfs") ): у меня сработало.
Интересная и очень полезная фича, да.

UPD:

Код: [Выделить]

root@test:~# btrfs subvolume list /
ID 257 gen 207 top level 5 path @
ID 269 gen 204 top level 5 path @apt-snapshot-2016-03-02_10:38:30

UPD1: И еще одно соображение. Почитав вот этот небольшой пост http://askubuntu.com/questions/29891/how-does-apt-btrfs-snapshot-work , подумал, что есть еще одна неприятность. Для нормальной работы apt-btrfs-snapshot нужно выносить на отдельные разделы не только /home , но, как минимум, еще и /var (причем, возможно, не весь...).

[Sly_tom_cat]

Пакет btrfs-tools - вообще кривой - у него половина утилит положена в /bin, а не в /sbin как у всех остальных утилит ФС.

Я когда увидел что sudo fsck.btrfs не может быть засунут в initramfs просто линканул его в /sbin/.

Т.е. править не код надо, а сборку пакета.

[Sly_tom_cat]

По поводу паковки разными механизмами. На сколько я разобрался, атрибут compression ставится на каждый каталог (или наследуется - это не разобрался еще). Так вот, такой подход позволяет прямо внутри одной ФС иметь каталоги с РАЗНОЙ степенью компересии!!!

[AnrDaemon]

AnrDaemon, ну так рекурсивность - как по мне так лучше я сам задам когда надо рекурсивно, бо оно не всегда нужно..

Мне - всегда. Я уже за[бибип] править ACL на ext3 после каждого факапа. Чтобы ещё ФС мозги [бибип] - да [бибип] в задницу.

По набору фич ZFS скорее всего пока держит планку, но не надо забывать что btrfs сейчас на гребне - ее пилят, пилят, и пилят сотни разрабов, и фичастость btrfs уже сейчас очень приличная и растет с каждым днем, так что ZFS врятли сможет долго оставаться в одиночестве  на олимпе самой навороченной ФС

И не будем забывать - btrfs родилась как ответ на невозможность поменять лицензионную политику ZFS, которая не позволяет ей быть официально встроенной в ядро. И проект был изначально запланирован как реализация всех "вкусностей" ZFS, но под нормальной лицензией.

Пока не вижу вкусностей. Самой главной фичи нет. Прозрачного наследования.

[Sly_tom_cat]

AnrDaemon, ну я не думаю что в btrfs будут дотошно повторять весь до единого функционал ZFS, и я не думаю что это было бы правильно делать так.

Всетаки btrfs - это самостоятельная ФС и набор фич у нее просто должен быть свой...

Про прозрачное наследование - даже не знаю что это такое - подскажите где почитать, плз.

[AnrDaemon]

Описание NTFS почитай. Или ZFS.

я не думаю что в btrfs будут дотошно повторять весь до единого функционал ZFS

Нахрена она тогда нужна?…