Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    info@proxmox.su
    +7 (495) 320-70-49
    Заказать звонок
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Телефоны
    +7 (495) 320-70-49
    Заказать звонок
    0
    0
    0
    Аспро: ЛайтШоп
    • +7 (495) 320-70-49
      • Назад
      • Телефоны
      • +7 (495) 320-70-49
      • Заказать звонок
    • info@proxmox.su
    • Москва, Бакунинская улица, 69с1
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Proxmox Виртуальная Среда
    Сделать `compress-force=zstd:3` стандартом для BTRFS?

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Сделать `compress-force=zstd:3` стандартом для BTRFS?, Proxmox Виртуальная Среда
     
    A.R.
    Guest
    #1
    0
    31.01.2024 12:29:00
    Привет! Я выбрал BTRFS, так как пользуюсь им с тех пор, как он появился в (Open)SUSE, и поэтому выбрал его и для Proxmox. Заметил очень низкую степень сжатия на дисковых образах — всего несколько процентов. Легко проверить это, используя compsize (пакет btrfs-compsize). По умолчанию Proxmox задает для раздела BTRFS опцию монтирования compress=zstd:3. Эта опция проверяет, можно ли сжать файл при создании и когда записываются первые блоки. Если сжать можно, то сжимается весь файл. Если нет — сжатию не подлежит ни один(!) из последующих блоков необработанного образа. Как выяснилось, дисковые образы для моих виртуальных машин (FreeBSD, различные Linux и Windows) не очень хорошо сжимаются в начале, но позже сжимаются очень хорошо. Я внес изменения в fstab и запустил btrfs filesystem defragment -r -czstd /var/lib/pve/local-btrfs/images/ и другие (образы) хранилища с очень хорошими результатами сжатия, что позволило сэкономить примерно 40% дискового пространства. К тому же, поскольку доказано, что сжатые диски BTRFS обычно обеспечивают более высокую скорость ввода-вывода, виртуальным машинам будет немного лучше в плане IO. Поэтому я подумал, возможно, было бы лучше использовать compress-force=zstd:3 в качестве стандартной опции монтирования для томов BTRFS, чтобы воспользоваться преимуществами сжатия BTRFS?
     
     
     
    A.R.
    Guest
    #2
    0
    01.03.2024 00:40:00
    Конечно, сделаю. Я откладывал это, потому что у меня жутко медленно создаются резервные копии моих mv's. Подумаю, почему так. Открываю ещё одну тему, чтобы разобраться в этом.
     
     
     
    alexskysilk
    Guest
    #3
    0
    01.03.2024 01:41:00
    Это может привести к довольно неприятным последствиям для скорости записи. Лучше оставить алгоритм сжатия, чтобы он сам решал.
     
     
     
    RolandK
    Guest
    #4
    0
    01.03.2024 13:03:00
    Это может привести к довольно неприятным последствиям для скорости записи. В каком смысле? LZO невероятно быстрый, а ZSTD тоже быстрый на современных процессорах.

    Лучше позволить алгоритму сжатия решать, но эвристики сжатия в Btrfs отвратительны, особенно при использовании с большими виртуальными дисковыми файлами, используемыми в качестве "блочного хранилища". Почему сжатие для этих файлов должно решаться только на основе первого блока данных? (Что делает стандартный алгоритм сжатия Btrfs) https://marc.info/?l=linux-btrfs&m=170853747617447&w=2 https://bugzilla.proxmox.com/show_bug.cgi?id=5250#c6
     
     
     
    alexskysilk
    Guest
    #5
    0
    01.03.2024 17:38:00
    Потому что не сжимаемые данные существенно замедляют запись, когда их пытаются пропустить через алгоритм сжатия; в итоге они получаются даже больше, чем оригинал. Даже если алгоритм подсказок (hinting algorithm) недостаточно хорош, в целом лучше оставить подозрительный файл не сжатым, чем наоборот — и это объясняет, почему так настроено по умолчанию.
     
     
     
    A.R.
    Guest
    #6
    0
    01.03.2024 18:42:00
    BTRFS действительно пытается сжимать все данные. И, следовательно, есть некоторая потеря в скорости записи. Однако, если блок (128 КБ) не поддается сжатию, он будет храниться без сжатия. Так что он не станет больше. Есть также дополнительный штраф из-за размера блока в 128 КБ. Небольшая запись приведет к записи 128 КБ. Однако, по крайней мере, в моей системе, я заметил неожиданное замедление чтения. К моему удивлению, ведь теоретически должно быть быстрее. Запуск pv zstd3_compressed_disk.raw > /dev/null на системе без запущенных виртуальных машин дал среднюю скорость 268MiB/s для 300-гигабайтного файла. Несжатая копия делала это со скоростью 1,5GiB/s. Разницы между raid1 и raid0 не обнаружено. Поэтому лучше перевести последнее в конфигурацию jbod. Так что для меня с zstd:3 по крайней мере, есть еще одна проблема. Нужно больше исследований. Это может быть связано с процессором, памятью, более поздними ядрами, разными настройками? Пока не знаю. Думаю, что два Intel Xeon E5-2630 v4 (20) @ 3.100GHz не могут быть причиной.
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

    Конфиденциальность Оферта
    © 2026 Proxmox.su
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры