Ресурс Phoronix провёл (http://www.phoronix.com/scan.php?page=article&item=btrfs_lzo...) тестирование производительности реализации файловой системы Btrfs при работе в трех режимах: без сжатия данных, со сжатием при помощи метода ZLib и со сжатием с использованием метода LZO, поддержка которого была добавлена в недавно вышедшем Linux-ядре 2.6.38 (http://www.opennet.me/opennews/art.shtml?num=29919).В тесте 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 ра...URL: http://www.phoronix.com/scan.php?page=article&item=btrfs_lzo...
Новость: http://www.opennet.me/opennews/art.shtml?num=29959
Первый раз сходил по ссылке на Фороникс. Результат интересный. По крайней мере на некоторых задачах на некоторой аппаратуре есть большой смысл выбирать LZO.В переводе ошибка. В FS-Mark LZO показал почти такой же результат, как без сжатия, это Zlib опережает их на 33%.
Кто-нибудь пользовался IntelliJ IDEA c btrfs? Стоит ли включать сжатие, и вообще даст ли btrfs преимущество над ext4?
Если твоей целью служит потеря данных, то на данный момент времени бтрфс даст неоспоримое преимущество над ехт4. Потом в рассылке напишешь мольбу о помощи. Там разработчики любят разбирать что и как, чтобы потестить получше. Глядишь, через пару лет формат фс и утвердят, а еще через пару лет выпустят фсчк :) А там и федора 14 выйдет, где бтрфс по умолчанию, чтобы еще лучше потестить. Тогда, конечно, преимуществ над ехт4 будет поменьше, но зато нужных для работы, а не для теста.
В целом согласен, но Fedora 14 уже вышла :) Так что btrfs по умолчанию - это Fedora 16 или 17 ;)P.S. Периодически пробовал btrfs начиная с 12ой федоры (или даже раньше?). В общем, оно работает и даже неплохо... но не всегда. У меня в btrfs виртуальная машинка в qemu-kvm грузилась минут 20 против 20 секунд под ext4. :) А вот во всех остальных случаях никаких проблем, одна беда - мне виртуальные машинки важнее.
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" ты не прав.
А зачем сжатие для IntelliJ IDEA?
Для скорости. Ну и многогигабайтные кеши с индексами если меньше занимать будут — тоже приятно.
> А зачем сжатие для IntelliJ IDEA?Скорость. Размер данных на диске не так важен, но время индексирования и работы с свн хотелось бы уменьшить. Тут важна запись и чтение тысяч мелких файлов. Судя по тестам самих JetBrains на ext4 работает раза в два быстрее чем на ntfs. Если btrfs быстрее ext4 на записи большого количества мелких файлов, то это будет огромный плюс для меня.
Использую btrfs несколько месяцев, потерь данных не наблюдал, так что хватит писать фигню. Работает шустрее ext4. OS - Debian.
Вот если бы ты написал "использую пару лет на тысяче рабочих станций и сотне серверов и никаких проблем", тогда бы это что-то значило. А так... маловато данных для статистики.P.S. Это справедливо не только для btrfs, но и для любой другой FS.
>... Работает шустрее ...если только NFS по модему 14400/MNP5/NONE
Попробуй виртуалки поклонировать.
# qemu-img clone
# VBoxManage clonehd
# VBoxManage convertfromrawиз QEMU снапшота, применить изменения: Ctrl+Alt+1, commit all
---
Может уже исправили, а в октябре так и было.
И меня всё это так затрахало, все эти попугай - BTRFS/ZFS/ext4/POHMELFS,
что конвертнул нахрен всё обратно, в XFS, сплю спокойно. :)
На твоём месте я бы как раз побеспокоился, если тебе дороги данные, т.к. XFS очень критична к программным и аппаратным сбоям, включая сбои электросети и источников бесперебойного питания.
> На твоём месте я бы как раз побеспокоился, если тебе дороги данные,
> т.к. XFS очень критична к программным и аппаратным сбоям, включая сбои
> электросети и источников бесперебойного питания.Угу... пока глюки были везде, кроме XFS.
А откуда беруться данные для чтения-записи в тестах? Они ведь все-таки синтетические. Если из /dev/urandom - тогда тут у сжатия шансов не должно быть никаких, если из /dev/null - тогда ясно откуда 9х. Или там все-таки приближенные к реальности файлы?