Re: btrfs?

[Artem Chuprina]

artiom -> debian-russian@lists.debian.org  @ Sat, 3 Nov 2018 16:10:09 +0300:

 > Пользуюсь ZFS на Debian Linux с 17 года в NAS, пока всё ok. Две системы
 > подобной сложности вряд ли нужны. Одна в продакшне, другая между альфа и бета
 > версиями уже долго, потому если требуется подобный функционал, ясно что
 > выбирать.

Ну вот у меня, например, при загрузке системы упорно не монтируется один
из томов ZFS. Если залогиниться после загрузки и сказать zfs mount -a,
то молча монтируется. Отличается от остальных тем, что там попрошено
case insensitive имена файлов (это exchange, в первую очередь для винды)
и задействованы ACL.

Как следует разобраться с проблемой руки не доходят, ибо сервер на шкафу
и монитор к нему цеплять неудобно.

Офф-бэнд дефрагментацию блочного уровня ZFS, в отличие от btrfs, не
умеет. Под ин-бэнд требования к железу невменяемые. А прочие плюшки ZFS
по сравнению с той же ext4 как-то применить не удается — машинка
слабенькая, без ECC, диск один, так что чексуммы все равно лучше держать
внешние, и проверять после скидывания на бэкапный винт.

При этом поддержка ext4 в линуксе не в пример лучше :) Включая,
например, тот момент, что дистрибутивный пакет умеет цеплять ZFS только
если инитом работает systemd, а systemd инитом весьма хреново
работает. Описанная проблема с нецеплянием одного из томов — не
единственная проблема с systemd на этой машине. Это я уж молчу про танцы
с рутом на ZFS. Я их один раз станцевал, но результат мне не шибко
нравится.

Re: btrfs?

[artiom]

Пользуюсь ZFS на Debian Linux с 17 года в NAS, пока всё ok. Две системы 
подобной сложности вряд ли нужны. Одна в продакшне, другая между альфа и 
бета версиями уже долго, потому если требуется подобный функционал, ясно 
что выбирать.


02.11.2018 18:19, Artem Chuprina пишет:

Угу, осознал. Всем спасибо, переформатировал в ext4 и ограничусь
перелинковкой средствами jdupes. Из положительного: в процессе чтения
про дедупликацию у btrfs выяснил, что существуют готовые инструменты для
такой перелинковки (не зависящие от btrfs), не надо писать :)

  >> Граждане, а как у нас нынче с надежностью btrfs? А другими тараканами?

  > Пару лет назад оно вело себя странно. Данные вроде не терял из-за нее,
  > но периодически приходилось делать rebalance. Сейчас живу с ней (ядро
  > 4.18) и вроде всё устраивает. Кроме того, она активно используется в
  > качестве backend для sbuild очень много у кого.


  > [gq@dwarf:~/ya/sdc]$ mount | grep btrfs
  > /dev/mapper/dwarf-root on / type btrfs 
(rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
  > /dev/mapper/dwarf-chroot on /srv/chroot type btrfs
  > (rw,relatime,compress=zlib:3,ssd,space_cache,subvolid=5,subvol=/)
  > /dev/mapper/dwarf-home on /home type btrfs 
(rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
  > /dev/mapper/dwarf-tmp on /mnt type btrfs 
(rw,relatime,ssd,space_cache,subvolid=5,subvol=/)

  >> Или ну его пока нафиг, и пожить на старой доброй ext4? Задача - ФС под
  >> домашний файловый/бэкапный сервер. 8 TB. Его собственное содержимое
  >> бэкапится, увы, пока нерегулярно. Рейд тоже пока увы. Во-первых,
  >> нетбабла (диск такого объема не три копейки стоит), а во-вторых, в той
  >> машинке быстрый SATA-выход один.
  > Под надежный сторадж я использую ext4. Он же надёжный =)

  >> А вот косой взгляд на инструменты out-of-band deduplication для btrfs
  >> как раз вызывает интерес к оной файловой системе. Поскольку там немало
  >> бэкапов, и порой файлы в них переезжают, эта функциональность
  >> представляется нелишней. Расслабиться на тему "ну и что, что сотню
  >> гигабайт переложили и потрогали, к завтрему перелинкуется" было бы
  >> приятно.

  > Вот с этим как-то всё непонятно: тоже всё хотел использовать, но то
  > утилита требовала каких-то особых танцев, то грозила потерей данных, то
  > падала с непонятной диагностикой. В итоге так и не заюзал.