The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Оценка производительности LZO и ZLib сжатия в файловой системе Btrfs

18.03.2011 15:29

Ресурс Phoronix провёл тестирование производительности реализации файловой системы Btrfs при работе в трех режимах: без сжатия данных, со сжатием при помощи метода ZLib и со сжатием с использованием метода LZO, поддержка которого была добавлена в недавно вышедшем Linux-ядре 2.6.38.

В тесте Compile Bench, оценивающем скорость сборки различных проектов, Btrfs c LZO-сжатием обогнал вариант без сжатия в 2.25 раза и вариант с zlib-сжатием в 1.25 раз. В тесте IOZone Btrfs c LZO-сжатием опередил вариант без сжатия в 9 раз, а вариант с zlib-сжатием в 2.4 раза.

В тесте Dbench результаты были примерно одинаковыми. При увеличении числа клиентов в тесте Dbench, а также при проведении текста FS-Mark, варианты с Zlib/LZO показали идентичный результат, опередив конфигурацию без сжатия на 20-22%. При отключении режима sync/fsync в тесте FS-Mark вариант LZO в 3 раза обогнал Zlib и в 7 раз обогнал вариант без сжатия.

В тесте Threaded IO Tester вариант LZO оказался на последнем месте, отстав от zlib на 11%, а от варианта без сжатия на 33%. В тесте AIO-Stress вариант LZO отстал на 10% от варианта Zlib, но обогнал на 10% вариант без сжатия.

  1. Главная ссылка к новости (http://www.phoronix.com/scan.p...)
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/29959-brtfs
Ключевые слова: brtfs, benchmark, zlib, lzo
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (14) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.5, gegMOPO4 (ok), 16:32, 18/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Первый раз сходил по ссылке на Фороникс. Результат интересный. По крайней мере на некоторых задачах на некоторой аппаратуре есть большой смысл выбирать LZO.

    В переводе ошибка. В FS-Mark LZO показал почти такой же результат, как без сжатия, это Zlib опережает их на 33%.

     
  • 1.7, tulskiy (ok), 16:36, 18/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кто-нибудь пользовался IntelliJ IDEA c btrfs? Стоит ли включать сжатие, и вообще даст ли btrfs преимущество над ext4?
     
     
  • 2.10, Drist (ok), 16:47, 18/03/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Если твоей целью служит потеря данных, то на данный момент времени бтрфс даст неоспоримое преимущество над ехт4. Потом в рассылке напишешь мольбу о помощи. Там разработчики любят разбирать что и как, чтобы потестить получше. Глядишь, через пару лет формат фс и утвердят, а еще через пару лет выпустят фсчк :) А там и федора 14 выйдет, где бтрфс по умолчанию, чтобы еще лучше потестить. Тогда, конечно, преимуществ над ехт4 будет поменьше, но зато нужных для работы, а не для теста.
     
     
  • 3.11, dalco (ok), 18:27, 18/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    В целом согласен, но Fedora 14 уже вышла :) Так что btrfs по умолчанию - это Fedora 16 или 17 ;)

    P.S. Периодически пробовал btrfs начиная с 12ой федоры (или даже раньше?). В общем, оно работает и даже неплохо... но не всегда. У меня в btrfs виртуальная машинка в qemu-kvm грузилась минут 20 против 20 секунд под ext4. :) А вот во всех остальных случаях никаких проблем, одна беда - мне виртуальные машинки важнее.

     
  • 3.14, Frank (ok), 19:52, 18/03/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Thu Mar 17 20:28 - crash
    Thu Mar 17 08:16 - crash
    Mon Mar 14 08:12 - crash
    Fri Mar 11 20:26 - crash
    Thu Mar 10 08:10 - crash
    Wed Mar  9 08:20 - crash
    Sun Mar  6 16:36 - crash
    Sun Mar  6 14:27 - crash
    Sat Mar  5 19:40 - crash
    Sat Mar  5 10:59 - crash
    Sat Mar  5 10:44 - crash
    Fri Mar  4 06:31 - crash
    Thu Mar  3 12:07 - crash
    Wed Mar  2 13:55 - crash
    Wed Mar  2 12:54 - crash
    Wed Mar  2 08:10 - crash
    Tue Mar  1 10:30 - crash

    Как тебе такая картинка, впечатляет? Она уже несколько месяцев у меня, только не спрашивай почему - на то есть объективные причины. И это НЕ btrfs :)
    Так вот, несмотря на такие завешивания (чаще всего вис железный и не работают даже magic keys), я не потерял НИЧЕГО за пол года эксплуатации btrfs. Так что насчёт "даст неоспоримое преимущество над ехт4" ты не прав.

     
  • 2.12, iZEN (ok), 19:00, 18/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем сжатие для IntelliJ IDEA?
     
     
  • 3.13, gegMOPO4 (ok), 19:48, 18/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Для скорости. Ну и многогигабайтные кеши с индексами если меньше занимать будут — тоже приятно.
     
  • 3.19, tulskiy (ok), 08:16, 20/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А зачем сжатие для IntelliJ IDEA?

    Скорость. Размер данных на диске не так важен, но время индексирования и работы с свн хотелось бы уменьшить. Тут важна запись и чтение тысяч мелких файлов. Судя по тестам самих JetBrains на ext4 работает раза в два быстрее чем на ntfs. Если btrfs быстрее ext4 на записи большого количества мелких файлов, то это будет огромный плюс для меня.

     

  • 1.15, Paul Rufous (?), 21:41, 18/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Использую btrfs несколько месяцев, потерь данных не наблюдал, так что хватит писать фигню. Работает шустрее ext4. OS - Debian.
     
     
  • 2.16, dalco (ok), 21:54, 18/03/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вот если бы ты написал "использую пару лет на тысяче рабочих станций и сотне серверов и никаких проблем", тогда бы это что-то значило. А так... маловато данных для статистики.

    P.S. Это справедливо не только для btrfs, но и для любой другой FS.

     
  • 2.17, pavlinux (ok), 01:39, 19/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >... Работает шустрее ...

    если только NFS по модему 14400/MNP5/NONE

    Попробуй виртуалки поклонировать.

    # qemu-img clone
    # VBoxManage clonehd  
    # VBoxManage convertfromraw

    из QEMU снапшота, применить изменения:  Ctrl+Alt+1, commit all

    ---
    Может уже исправили, а в октябре так и было.
    И меня всё это так затрахало, все эти попугай - BTRFS/ZFS/ext4/POHMELFS,
    что конвертнул нахрен  всё обратно, в XFS, сплю спокойно. :)

     
     
  • 3.18, IGX (?), 23:58, 19/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    На твоём месте я бы как раз побеспокоился, если тебе дороги данные, т.к. XFS очень критична к программным и аппаратным сбоям, включая сбои электросети и источников бесперебойного питания.
     
     
  • 4.20, pavlinux (ok), 13:00, 20/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > На твоём месте я бы как раз побеспокоился, если тебе дороги данные,
    > т.к. XFS очень критична к программным и аппаратным сбоям, включая сбои
    > электросети и источников бесперебойного питания.

    Угу... пока глюки были везде, кроме XFS.

     

  • 1.21, Анон (?), 08:10, 21/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А откуда беруться данные для чтения-записи в тестах? Они ведь все-таки синтетические. Если из /dev/urandom - тогда тут у сжатия шансов не должно быть никаких, если из /dev/null - тогда ясно откуда 9х. Или там все-таки приближенные к реальности файлы?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру