[2Silvy] Btrfs

Хотелось бы так же услышать мнение всех кто тестировал btrfs.

//Let's fs flame begin ;)

он и сейчас есть ) драйвер стабильный и вполне пригодный

btrfsprogs не очень, fsck например может не проверять диск и падать с segfault
плюс ключики несовместимы с стандартными опциями

хотя у меня все по умолчанию, балансированием метаданных и подключением-отключением дополнительных разделов к ФС я не стала заниматься,

реально мне нужна быстрая более-менее надежная ФС с возможностью нормального сжатия (ФС райзер4 с сжатием мне не очень понравилась, а вот btrfs - самое то)

И много это сжатие ресурсов отнимает?

И самое главное -- сильно сжимает?

Я тестировал,причём / Херня ,вернулся на Рейзер.Ускорения я субьективно не заметил,а тормоза при первом перечитывании базы портежа очень даже.+ поимел кернел-паник при каком-то обновлении системных утилит.Нафиг,пусть дальше пилят.

там gzip
без возможности выбора между lzo/gzip/bzip2 (?) как в рейзер


как gzip'ом пакуете - вот так и занимает ресурсы, естественно что для временных файлов/ компилирования и т п такая ФС не очень пригодна. В остальных случаях - практически незаметно, чтение - почти также как и на ФС без сжатия, запись -сколько процессор выдает по gzip , такая и скорость

btrfs
$ dd if=/dev/urandom of=testfile bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 35.41 s, 3.0 MB/s

$ dd if=/dev/zero of=testfile bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 1.59873 s, 65.6 MB/s

$time lzcat ~/dump_before_switch/gamedb_20090414-15.sql.lzma > testfile
3.82user 0.36system 0:08.56elapsed 48%CPU
52%cpu - на сжатие при записи ушло соответственно, запись 8 секунд против 4 секунд на ext3 ( 100 Mb .sql файл)


ext3
$ time lzcat ~/dump_before_switch/gamedb_20090414-15.sql.lzma > testfile
3.75user 0.46system 0:04.40elapsed 95%CPU
(комментарий выше)

$ dd if=/dev/zero of=testfile bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 2.76952 s, 37.9 MB/s
(а с сжатием в 2 раза быстрее !)

$ dd if=/dev/urandom of=testfile bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 34.3362 s, 3.1 MB/s
(по сути данные из urandom не сжимаемые, скорость оказалось такой же как и с сжатием)

Linux 2.6.29.1-lu #1 SMP PREEMPT i686 Intel(R) Celeron(R) M processor 1.70GHz GenuineIntel GNU/Linux

сжатие 100 Мб SQL с gzip - 10.01user 0.41system 0:10.62elapsed 98%CPU ~ 10 Mb/s

копирование того же файла на btrfs
0.00user 0.57system 0:02.63elapsed 20%CPU на cp / = 80% на btrfs ~ 30 Mb/s

насчет сильно не скажу, статистика только по сравнению df и du
но ляпов с тем что 50 Мб раздувает до 2 Гб как с райзером нету )


3126158 Kb du
1621332 Kb df

~ 50%

Вобщем стоит попробовать.

Оно нормально работает.

да,
но на $HOME я не решилась, только на то что легко будет восстановить или не жалко
в целом у меня в /opt стоит ООО и КДЕ4 - запускаются достаточно быстро ) несмотря на сжатие, а может наоборот как раз благодаря ему )

Короче говоря сливает райзеру4 пополной что и следовало ожидать.

fanatism is not good

а перед тем как что-то ляпнуть - выложите хотя бы простенькие тесты

и не забывайте про разницу в конфигурациях, у меня ноут с

P4 Celeron 1.7 (Dothan) так что если сравнивать цифры с C2... ну это некорректно

Кстати, как это MS не догадались запатентовать сжатые тома (их реализация в win95 -- DoubleSpace ЕМНИП)

Я высказал свое мнение и фанатизм тут нипричем. При использовании райзер4 в течении полугода
1 не пропало ни одного файла
2 скорость чтения по сравнению с ext3 была в 3 раза выше, записи процентов на 20 - в пределах погрешности измерения, так что можно считать одинаковая но по крайней мере не меньше
3 при сборке портов время было сопостоваимо с тмпфс
4 на бинарниках занимаемое место было в 2,5-3 раза меньше
5 увеличение скорости загрузки было видно на глаз

Единственной причиной ухода было то что я не вижу будущего у райзера4.

во-первых doublespace появилось гораздо раньше и не у МС
drvspace dblspace ultrastor(?) еще что-то было, пионерами были далеко не МС в этом направлении.

во-вторых там несколько иное сжатие, сам сжатый том по сути архив подключаемый как том, из OSS аналогов можно назвать например fuse-zip (c) gaa @ LOR ^_^
Хотя fuse-zip делает работу по изменению архива при его отмонтировании, а dblspace
в фоне, но тем не менее - работа с сжатым томом , по сути работа с архивом

в btrfs/ext2+compress/ntfs сжатие идет отдельных файлов, на файл ставится флажок "сжатый" , из fuse аналогов можно назвать fuse-compress (кривовато сделано правда)

reiser4 где опция сжатия определяется при создании ФС не знаю что использует.....

в btrfs сжатие включается при монтировании раздела (опция compress в fstab)

1) аналогично с btrfs
использую с момента выхода ядра 2.6.28 (отдельный драйвер)

2) у меня медленный винчестер, но я тоже могу сказать что по скорости btrfs превосходит ext3

3) кеш диска ?) сжатие есть? какое ? lzo ? цифры тестов в студию )

4) аналогично с btrfs, gzip он в любой ФС gzip ) хотя опции могут быть чуть различны
к btrfs сжатие подключается намного легче чем к райзер4

5) аналогично с btrfs


про будущее - да ... а btrfs уже в ядре.


btrfsprogs очень сырые, но это допилят.

Спасибо за разъяснение

>3) кеш диска ?) сжатие есть? какое ? lzo ? цифры тестов в студию )

Кормить тролей ? - фик вам.

как невежливо
слив засчитан, любые аргументы без цифр нерелевантны, а раз не хотите выкладывать...

я вот почему то не стесняюсь делать тесты на P4 Celeron 1.7
хотя его современный эквивалент (Atom 1.7) мне кажется должен бы быть и побыстрее

Не вежливо потому что вижу как раз фанатизм в твоих высказываниях. И что значит - не хотите выкладывать ? я давно перешел обратно на райзерфс, мне что сейчас срочно создать раздел и проводить нелепые тесты по сжатию random ? тестов в интернете много и достатчно обширных где есть ext3 и reiser4, есть с чем сравнить, правда c brtfs вместе я не встречал - видимо слишком хороша чтобы ее с чем то сравнивать :)

PPS: ну и по хорошему - вот эти "тесты" на самом деле ничего не значат

по хорошему нужно брать bonnie++ например
делать на одном и том же диске , в одном и том же месте (поочередно) ФС для сравнения и делать одинаковые тесты, после чего сравнивать результаты из которых действительно можно делать какие-то выводы, а то тому что выше - сравнивать теплое с мягким )

сами влезли, у меня спросили мое мнение и мои впечатления, мне удобно этим пользоваться, никакого фанатизма.

>сами влезли, у меня спросили мое мнение и мои впечатления
милочка - я никуда не влезал, это публичный форум если ты еще не заметила. Оставь свой номер телефона или любой другой персональный контакт и веди там приватные беседы.

Угу ещё фотку в купальнике с макбуком и можно в модераторы выдвигать :)

Есть ли возможность поставить атрибуты наподобие "обязательно сжимать"/"никогда не сжимать" на файлы или директории?

кажется нет
в fuse-compress была возможность определять маски для исключений или сжатия.

http://btrfs.wiki.kernel.org/index.php/Main_Page
если что то вот вики

>> kerosinkin

когда я вижу что xxx в 3 раза быстрее yyy я прозреваю чей-то наглый гон, если не сказать хуже. А когда начинают обгонять tmpfs, то я задумываюсь, дружит ли автор с умом и понимает ли он вообще что он тестирует.

ну так у таких _на глаз_ все в три раза быстрее, больше...


у меня в профайле ссылочка на картинку-комикс про таких )

> http://btrfs.wiki.kernel.org/index.php/Main_Page

Спасибо. Ни слова о такой возможности. Похоже, сжатие пока можно включать-выключать только для всего раздела сразу.

Загляни в мой профайл - если что, пароль 123. Пользуйся :)

2 Silvy: покажи опции монтирования. Манов всё ещё нет, а что-то связное нагуглить не удалось.

"-o compress" - опция монтирования для использования сжатия.

Что я заметил за несколько часов пыток:

1) Запись мелких плохо сжимаемых ogg(3-7 мегов) на BtrFS в среднем на 6-8% быстрее, нежели на ext3.

2) Файл нулей записывался с заметно возросшей скоростью: 140 мегов/с против ~50 у плохо сжимаемых файлов. В цифре 140 прозреваю ограничение проца, ибо полуторогиговый файл нулей был сжат до 7 мегов - тут много времени на запись не потратишь :)

3) Запись больших mpeg/avi(500-1500 мегов) показывает всё те-же 50 мегов/с - чуть лучше, чем у ext3 (48 мегов/с).

4) Двухгиговый снимок раздела с установленным Арчем записывался чуть быстрее - ~59 мегов/с - почти максимум для раздела. Ext3 показал 48 мегов/с на этой операции.

5) Оно, сцуко, жрёт процессор! +30% на каждое ядро в лучшем случае. И это только чтение... Запись - иногда сжирает одно ядро полностью.

6) п.5 - работать невозможно! Гном тормозит!

Копировалось с первого винта на второй. dd if=/dev/zero of=<подоытный раздел> даёт не больше 62 мегов/с.

Самое страшное: оно куда-то использует два гига, и не отдаёт. Ужас!

а какой процессор и размер раздела сделали?

5) оно ж не постоянно ест..
6) у меня вполне прилично на /opt и celeron 1700 Mhz

/dev/sda7 /opt btrfs nodev,compress,relatime 0 0

C2D, 4M cache, 2.13GHz(занижена до 1.6).

Размер подопытного раздела - 10 гигов. Проверил на 150 гиговом, там также 2 гига "исчезли" - говорит место закончилось.

З.Ы. Лучше продолжить в теме, на первой странице толксов :)

с размером не поняла, у меня ничего никуда не сьелось
#df -h
                               total   used  free
/dev/sda7              31G  1.6G   29G   6% /opt
# du -sh /opt
3.1G    /opt

/dev/sda7:
 Timing cached reads:   668 MB in  2.00 seconds = 334.29 MB/sec
 Timing buffered disk reads:  106 MB in  3.03 seconds =  34.95 MB/sec

запись случайных малосжимаемых данных из tmpfs
c cжатием
536870912 bytes (537 MB) copied, 21.0382 s, 25.5 MB/s

то же самое но без сжатия на ext3 раздел
536870912 bytes (537 MB) copied, 18.5038 s, 29.0 MB/s


скорость чтения 
разброс - 5-22 Mb/s
средняя - 3.01 GB in 00h03m35.73s:   14.33 MB/second


загрузка процессора в это время
Cpu(s):  2.0%us, 36.8%sy,  0.7%ni,  0.0%id, 59.9%wa,  0.3%hi,  0.3%si,  0.0%st
максимальная
Cpu(s):  2.3%us, 85.4%sy,  0.3%ni,  0.0%id, 10.6%wa,  0.7%hi,  0.7%si,  0.0%st


model name      : Intel(R) Celeron(R) M processor         1.70GHz
cpu MHz         : 1700.000
cache size      : 1024 KB
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up bts
bogomips        : 3401.11

эх, мну таки решился на reiser4 под файлопомойку/хранилище статического контента (только чтение). пока доволен, всё по-простому, без шифрования и т.п. на бтр поползу (если) к концу года наверное...

Silvy, спасибо, Ваши выкладки по статистике гораздо честнее мусора "интернет изданий" и прочей макулатуры...

ну авторы "мусора" так или иначе преследуют какую-то цель, я просто выкладываю то , что есть, возможно с неточностями из за того что эксперимент сравнительно небольшой и недолгий, либо потому что было внешнее влияние в момент эксперимента, например какая-либо программа захотела что-то прочитать или записать в этот момент, хотя кеши диска я сбрасываю для тестов


В любом случае , статистика "интернет изданий" это одно, впечатления других - другое и и то и другое на самом деле всего лишь повод для того чтобы попробовать и сделать свои выводы уже из личного опыта :)

Вам тоже спасибо за оценку