Чи є сенс ставити btrfs на lvm?


12

Це OpenSUSE Leap 42. У мене є комп'ютер із 2x SATA HDD накопичувачами на 500 ГБ і для його прискорення я вклав у систему невеликий накопичувач SSD 30 Гб . Під час встановлення жорсткі диски відключалися, оскільки вони плутали інсталятора (і мене). Після створення системи я досить легко обміняв каталог / home на логічний том XFS (я використовую LVM в першу чергу, щоб легко додати простір). Потім / opt заповнили (хром і ботанікулу), і я хотів поставити це на об'єм на HDD. Тому я створив том і відформатував його за допомогою BTRFS. Після декількох подряпин по голові - @ subvolumesв fstab змусив мене читати на BTRFS, я зробив те, що мені потрібно - / зараз вибираю розмір 100 ГБ.

Але питання полягає в тому: чи є сенс форматувати об'єм LVM за допомогою btrfs? Вони по суті є системами об'ємної обробки.

Для ілюстрації я вставляю fstab (# коментарі показують мої зміни) та vgscan + lvscan вихід:

~> cat /etc/fstab

UUID=1b511986-9c20-4885-8385-1cc03663201b swap swap defaults 0 0
UUID=30e20531-b7f1-4bde-b2d2-fab8eeca23af / btrfs defaults 0 0
UUID=30e20531-b7f1-4bde-b2d2-fab8eeca23af /boot/grub2/i386-pc btrfs subvol=@/boot/grub2/i386-pc 0 0
UUID=30e20531-b7f1-4bde-b2d2-fab8eeca23af /boot/grub2/x86_64-efi bt

rfs subvol=@/boot/grub2/x86_64-efi 0 0
UUID=3e103686-52e9-44ac-963f-5a76177af56b /opt                 btrfs      defaults              0 0
#UUID=30e20531-b7f1-4bde-b2d2-fab8eeca23af /opt btrfs subvol=@/opt 0 0
UUID=30e20531-b7f1-4bde-b2d2-fab8eeca23af /srv btrfs subvol=@/srv 0 0
UUID=30e20531-b7f1-4bde-b2d2-fab8eeca23af /tmp btrfs subvol=@/tmp 0 0
UUID=30e20531-b7f1-4bde-b2d2-fab8eeca23af /usr/local btrfs subvol=@/usr/local 0 0
UUID=30e20531-b7f1-4bde-b2d2-fab8eeca23af /var/crash btrfs subvol=@/var/crash 0 0
UUID=30e20531-b7f1-4bde-b2d2-fab8eeca23af /var/lib/libvirt/images btrfs subvol=@/var/lib/libvirt/images 0 0
UUID=30e20531-b7f1-4bde-b2d2-fab8eeca23af /var/lib/mailman btrfs subvol=@/var/lib/mailman 0 0
UUID=30e20531-b7f1-4bde-b2d2-fab8eeca23af /var/lib/mariadb btrfs subvol=@/var/lib/mariadb 0 0
UUID=30e20531-b7f1-4bde-b2d2-fab8eeca23af /var/lib/mysql btrfs subvol=@/var/lib/mysql 0 0
UUID=30e20531-b7f1-4bde-b2d2-fab8eeca23af /var/lib/named btrfs subvol=@/var/lib/named 0 0
UUID=30e20531-b7f1-4bde-b2d2-fab8eeca23af /var/lib/pgsql btrfs subvol=@/var/lib/pgsql 0 0
UUID=30e20531-b7f1-4bde-b2d2-fab8eeca23af /var/log btrfs subvol=@/var/log 0 0
UUID=30e20531-b7f1-4bde-b2d2-fab8eeca23af /var/opt btrfs subvol=@/var/opt 0 0
UUID=30e20531-b7f1-4bde-b2d2-fab8eeca23af /var/spool btrfs subvol=@/var/spool 0 0
UUID=30e20531-b7f1-4bde-b2d2-fab8eeca23af /var/tmp btrfs subvol=@/var/tmp 0 0
UUID=30e20531-b7f1-4bde-b2d2-fab8eeca23af /.snapshots btrfs subvol=@/.snapshots 0 0
UUID=c4c4f819-a548-4881-b854-a0ed62e7952e /home     xfs defaults 1 2
#UUID=e14edbfa-ddc2-4f6d-9cba-245d828ba8aa /home                xfs        defaults              1 2

~>

# vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "r0data" using metadata type lvm2
  Found volume group "r0sys" using metadata type lvm2

# lvscan
  ACTIVE            '/dev/r0data/homer' [699.53 GiB] inherit
  ACTIVE            '/dev/r0sys/optr' [100.00 GiB] inherit

Після відповіді: Дякую, зараз я розумію ключові відмінності. Для мене LVM справді кращий для управління простором з будь-якими файловими системами поверх нього, але BTRFS слід використовувати для специфічних для нього функцій - переважно знімків. У простому домашньому користуванні, можливо, краще триматися подалі від нього. У мене було занадто багато горя, що управляє простором на невеликому приводі, але я думаю, що простір буде з'їдений також на великих дисках.

Відповіді:


11

Можливо, це пояснює (до речі, з вікі btrfs)

Підтомник у btrfs не є тим самим, як логічний том LVM або підпункт ZFS. З LVM логічний том є блоковим пристроєм сам по собі (який може, наприклад, містити будь-яку іншу файлову систему або контейнер, наприклад, dm-crypt, MD RAID тощо) - це не так з btrfs. Підпункт btrfs не є блоковим пристроєм (і не може розглядатися як один), а підпотоком btrfs можна вважати простір імен файлів POSIX. Доступ до цього простору імен можна отримати через підшипник файлової системи верхнього рівня, або його можна встановити самостійно.

див. також https://btrfs.wiki.kernel.org/index.php/FAQ

Взаємодія з розділами, диспетчерами пристроїв та логічними томами

Btrfs має підтомники, це означає, що мені не потрібен логічний диспетчер томів, і я можу створити велику файлову систему Btrfs на сирому розділі?

На це питання немає жодної відповіді. Ось питання, над якими слід замислюватися, коли вибираєте необроблені розділи або LVM:

  • Продуктивність
    • сирі розділи трохи швидші, ніж логічні томи
    • btrfs робить оптимізацію запису (послідовне записування) через підсистему запису файлів підсистеми файлів виграє від цього алгоритму створення декількох файлових систем btrfs, кожна в іншому LV, означає, що алгоритм може бути неефективним (хоча ядро ​​все одно буде виконувати деяку оптимізацію на блоковому пристрої рівень)
  • Змінення розміру та переміщення файлової системи в Інтернеті на різних пристроях: команда pvmove від LVM дозволяє файлові системи переміщатися між пристроями під час роботи в Інтернеті
    • необроблені розділи можна переміщувати до іншого стартового циліндра лише в режимі офлайн
    • необроблені розділи можна збільшити лише за наявності вільного місця після розділу, тоді як LVM може розширити LV на вільний простір будь-де в групі томів - і він може змінити розмір в Інтернеті
  • обмеження розміру підтомного / логічного обсягу
    • LVM зручний для створення логічних томів фіксованого розміру (наприклад, 10 МБ для кожного користувача, 20 ГБ для кожного зображення віртуальної машини тощо)
    • на даний момент підтомники не застосовують таких жорстких обмежень розміру, хоча майбутня функція qgroups вирішить цю проблему

.... FAQ продовжує пояснювати сценарій, у якому LVM + BTRFS має сенс


Дякую, я зараз розумію ключові відмінності. LVM справді кращий для управління простором з будь-якими файловими системами, розташованими поверх нього, але BTRFS слід використовувати для специфічних для нього функцій - переважно знімків. У простому домашньому користуванні, можливо, краще триматися подалі від нього.
r0berts
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.