Я ффш0ке от производительности zfs с сжатием gzip-9 на чтение.

Надеюсь ты сбрасывал кеши?

find /opt -type f -exec cat '{}' \; |pv|dd of=/dev/null

ты же просто читаешь содержимое всех файлов.

при чём тут zfs вообще ? :-)

кому какое дело до ФИЗИЧЕСКОЙ скорости чтения твоего жёсткого диска (куда в данный момент всё и упирается у тебя.. потому такой и результат.. особенно становится понятно, учитывая что жёсткий-диск на USB).

всем важнее насколько файловая система быстро решает — типичные для неё манипуляции с файловым деревом..

Вообще от zfs пока в основном положительные впечатления.
Если у кого есть отрицательные отзывы - интересно будет послушать.

ну в BTRFS тоже есть два вида сжатия: ZLIB и LZO (и ведётся работа над LZ4) ..

но только в отличии от ZFS — BTRFS не сломается после обновления ядра :-)

ну а почему ты пытался сравнивать ZFS именно с EXT4 , а не с BTRFS — вот это несовсем ясно (потому что бабка на лавке сказала что BTRFS якобы глючит? ну уж наверно не больше там «глюков» чем в неродной ZFS :))..

но радует что zfs есть теперь и для x32.

Шо есть x32? 32 бита? А зачем оно?!?! :)

Да, сброса кешей не видно - как кешей ОС, так и самого зфс.

Вообще - сжатие в gzip-9 идёт ОЧЕНЬ медленно, на любом процессоре. Вот у себя погонял - 20 мегабайт в секунду при архивации в devnull:

# cat test | pv | gzip -9 > /dev/null
 598MB 0:00:25 [23.9MB/s]

но только в отличии от ZFS — BTRFS не сломается после обновления ядра :-)

У меня reiserfs уже лет пять не ломается и видимо не сломается еще долго, если курды не помогут :)

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

активно использую zfs под задачи виртуализации на основе KVM уже 1,5 года, она значительно облегчила жизнь, а самое замечательное это бекапы и разворачивание виртуалок посредством снапшотов zfs

но только в отличии от ZFS — BTRFS не сломается после обновления ядра :-)

Там где постоянно обновляют ядра zfs не место, это серьёзная ФС для промышленного применения.

пакет: zfs-fuse

выкинь эту какашку и поставь нативный модуль ядра для zfs (ZOL) - http://zfsonlinux.org/

Там где постоянно обновляют ядра zfs не место, это серьёзная ФС для промышленного применения.

Ага, не обновлять ядра — это серьёзно!

(Сарказм)

:-)

а терь выдерни из розетки зфс и расскажи как ты готовил ext4?

Ага, не обновлять ядра — это серьёзно!

Мы, вероятно, немного о разном говорим. Обновлять ядро в рамках, предусмотренных версией дистрибутива можно и нужно, а вот собирать самое свежее ядро явно не стоит.

ещё года 3 и дома она будет можно считать основной, при 128 гб оперативы проблеем с её использованием не будет.

я посмотрю, как часто ты будешь обновлять, если после обновления тебе придётся звонить в ФСТЭК и говорить об этом.

Надеюсь ты сбрасывал кеши?

Нет конечно, да и в случае с нативной zfs всё с нуля делалось. На нативных ext4,xfs даже второй прогон не давал изменений.

посмотри btrfs и тоже удивись.

find /opt -type f -exec cat '{}' \; |pv|dd of=/dev/null
ты же просто читаешь содержимое всех файлов.

Естественно, но банальный обход дерева, открытие и чтение
каждого файла на zfs проходит быстрее.

при чём тут zfs вообще ? :-)

Потому что с этой ФС быстрее всё читается.

кому какое дело до ФИЗИЧЕСКОЙ скорости чтения твоего жёсткого >диска (куда в данный момент всё и упирается у тебя.. потому >такой и результат.. особенно становится понятно, учитывая что >жёсткий-диск на USB).

Те же 10G Физически читаются так:
#dd if=/dev/sdb3 of=/dev/null bs=1048576 count=10240
10240+0 записей считано
10240+0 записей написано
скопировано 10737418240 байт (11 GB), 96,5956 c, 111 MB/c

всем важнее насколько файловая система быстро решает — >типичные для неё манипуляции с файловым деревом..

Вот именно. Надо обойти:
# find . -type d|wc -l
12983
Каталога.
Открыть и прочитать:
# find . -type f|wc -l
129682
Файлов.

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

ну в BTRFS тоже есть два вида сжатия: ZLIB и LZO (и ведётся >работа над LZ4) ..

У меня негативные отзывы. Я ничего не замерял но год жизни (2 года назад взял 2TB USB Винт, поставил btrfs и сжатие. Через пол года использования начало сильно тупить.
Хотя могу и врать - у меня файлы кажется перестали читаться (давно это было). При этом физический диск читался без ошибок.

но только в отличии от ZFS — BTRFS не сломается после >обновления ядра :-)
ну а почему ты пытался сравнивать ZFS именно с EXT4 , а не с >BTRFS — вот это несовсем ясно (потому что бабка на лавке >сказала что BTRFS якобы глючит? ну уж наверно не больше там >«глюков» чем в неродной ZFS :))..

Я сравнил с тем что у меня было на древнем ноуте (xfs) и на настольном компе корень на ext4. Всё остальное в zfs.

пакет: zfs-fuse

выкинь эту какашку и поставь нативный модуль ядра для zfs (ZOL) - http://zfsonlinux.org/

Именно он и стоит на x64 машинке с USB3. Я рассказывал что сейчас и x32 появилось в fuse и видимо прямо в дистре.
Сейчас нативный zfsonlinux уже есть в x32? Раньше небыло.

но радует что zfs есть теперь и для x32.

Шо есть x32? 32 бита? А зачем оно?!?! :)

Увы есть и x32, у меня вон на расстоянии вытянутой руки 8 Машин из которых лишь 2 x64, одна из которых нетбук на атоме.

Да, сброса кешей не видно - как кешей ОС, так и самого зфс.

Где эти кэши у ext4 и xfs? Почему те так тупят хотя прогонял не раз.

Вообще - сжатие в gzip-9 идёт ОЧЕНЬ медленно, на любом >процессоре. Вот у себя погонял - 20 мегабайт в секунду при >архивации в devnull:

# cat test | pv | gzip -9 > /dev/null
598MB 0:00:25 [23.9MB/s]

Другие уровни GZIP не сильно быстрее на деле.

Не спорю.
У меня дома нет постоянно пишущих на диск задач. Если такие встретятся - никто не мешает отключить сжатие на отдельном подтоме.

а терь выдерни из розетки зфс и расскажи как ты готовил ext4?

Никак, так же как и zfs. Я банально поставил фDebian Wheezy на древний ноут и обнаружил что там есть еще и zfs-fuse.

ещё года 3 и дома она будет можно считать основной, при 128 гб оперативы проблеем с её использованием не будет.

Глупости. ZFS прекрасно работает в значительно меньших объёмах памяти.

посмотри btrfs и тоже удивись.

Пару лет назад смотрел. На тему подтомов и сжатия. Поставил на 2T USB винт, но радовался недолго. К сожалению не помню точно какие там были проблемы. Толи тормозить начала после серии xcopy на разные алгоритмы, чтения и удаления или тупо перестали читаться файлы, хотя физически диск читался. Толи оно перестало читаться после сбоя по питанию или висняка... не помню. В общем отрицательный отзы на 2 года назад. Пока устраивает zfs, поэтому btrfs не хочу и трогать.

я посмотрю, как часто ты будешь обновлять, если после обновления тебе придётся звонить в ФСТЭК и говорить об этом.

Ты мне сейчас хочешь рассаказать про стандартизацию? Я разворачивал в банках инфраструктуры на SCO OpenServer и поддерживал это хозяйство, когда доброй половины подписчиков LOR-а ещё в проекте не было.
Сейчас я использую ZFSonLinux на некоторых своих серверах, я продаю свои сервисы и услуги, мне плевать на ФСТЭК, более того, мои требования к доступности сервисов перекрывают их.

Где эти кэши у ext4 и xfs? Почему те так тупят хотя прогонял не раз.

У любой нативной ФС в линухе все просто - echo 3 > /proc/sys/vm/drop_caches

В случае с ZFS - хрен его знает. Для начала слезь с FUSE и перейди на ядерный ZFS - там всё бегает еще веселее. А там можно поиграться с параметрами модуля zfs - zfs_arc_min/zfs_arc_max и для чистоты эксперимента уменьшить этот кеш до минимума. Как его динамически сбросить - хз.

тебе уже 60 что ли?

40

А зачем сбрасывать кэш? Ты же на серверах этого не делаешь :)

Для чистоты эксперимента. Иначе у тебя могут быть частично или полностью кешированные данные - наверняка не узнаешь.

Из всего треда прочитал только заголовок. Ну а что ты хотел? CPU намного быстрее диска, поэтому гораздо быстрее прочитать вдвое меньше + распаковать, чем просто прочитать. И да, это относится к любым ФС, поддерживающим сжатие на лету.

Кстати, а как-то действительно можно узнать сколько и каких именно данных сидит в дисковом кэше в оперативке? Должны же быть какие-то инструменты для этого...

Из всего треда прочитал только заголовок. Ну а что ты хотел? >CPU намного быстрее диска, поэтому гораздо быстрее прочитать >вдвое меньше + распаковать, чем просто прочитать. И да, это >относится к любым ФС, поддерживающим сжатие на лету.

Если скорость чтения винта 100Mb/s а фс чтает 5898239.27 bytes/sec т.е. около 6Mb/s для корневого раздела с 129682 файлам. То это наводит на размышления.

2 года назад взял 2TB USB Винт, поставил btrfs и...

То есть ты сравниваешь ощущения от СОВРЕМЕННОЙ версии zfs с ощущениями от УСТАРЕВШЕЙ версии btrfs? Да? :-)

«Отличная» задумка :) .. Напоминает рекламу Интернет Эксплорера :-)

Глупая твоя голова, год~два года назад над btrfs стоял гриф «пожалуйста не используйте». Сейчас там всё сильно улучшилось..

где тег «я познаю мир»?

Знаешь, что занимает 95% времени при чтении с диска? ВНЕЗАПНО: чтение с диска. А при сжатии вдвое читать нужно вдвое меньше. И что тут удивительного?

Если у кого есть отрицательные отзывы - интересно будет послушать.

мои файлы уже сжаты и/или несжимаемы. Зачем мне zfs?

И да, это относится к любым ФС, поддерживающим сжатие на лету.

…например ext4, только для включения этой бесполезной фичи тоже надо ядро пересобрать.

Кстати, а как-то действительно можно узнать сколько и каких именно данных сидит в дисковом кэше в оперативке? Должны же быть какие-то инструменты для этого...

«сколько» это man free

«каких» это devision by zero.

Если скорость чтения винта 100Mb/s а фс чтает 5898239.27 bytes/sec т.е. около 6Mb/s для корневого раздела с 129682 файлам. То это наводит на размышления.

угу. Учить матчасть вам надо, юноша. 100мбпс это _линейная_ скорость, а есть ещё скорость позиционирования. Т.е. вы не учли время, за которое головка прыгает от дорожки к дорожке.

Попробуйте читать диск командой dd, но не подряд, а по 4К рандомными блоками. У вас и получится 6мбпс.

Сейчас там всё сильно улучшилось..

подтверждаю. Работает даже в слаке искароппки. Хотя я не пробовал.

2 года назад взял 2TB USB Винт, поставил btrfs и...

То есть ты сравниваешь ощущения от СОВРЕМЕННОЙ версии zfs с >ощущениями от УСТАРЕВШЕЙ версии btrfs? Да? :-)

Да, и я это оговорил. Я понимаю что всё движется вперед и когда куплю очередной xTB винт - я попробую btrfs.

«Отличная» задумка :) .. Напоминает рекламу Интернет >Эксплорера :-)

Я не видел этой рекламы и давно не трогал IE, однако по потреблению памяти сейчас все браузеры в отстое. На машинке с 512Mb рамы в интернете сидеть невозможно. Дичайшие тормоза.

Глупая твоя голова, год~два года назад над btrfs стоял гриф >«пожалуйста не используйте». Сейчас там всё сильно улучшилось..

Я мог и наврать и это было не 2 года назад а год назад - когда я купил 3TB винт и синкал туда основной zfs, при очередном синке появились и тормоза и невозможность прочитать файлы. Сейчас появилась мысль еще раз попробовать и рискнуть данными отформатировав копию в btrfs и синкнуть снова. Но зачем оно? Пока zfs устраивает и все эти ресинки занимают прорву времени. Да и вдруг при синке как раз умрет основной винт...

где тег «я познаю мир»?

Ага, и делюсь полученными знаниями здесь.

Знаешь, что занимает 95% времени при чтении с диска? ВНЕЗАПНО: >чтение с диска. А при сжатии вдвое читать нужно вдвое меньше. >И что тут удивительного?

Для того чтобы прочитать это «вдвое меньше» - надо найти где оно валяется, затем прочитать, затем распаковать и только затем отдать пожелавшему.

мои файлы уже сжаты и/или несжимаемы. Зачем мне zfs?

У zfs есть возможность и не сижимать файлы.
При этом её создатели утверждают что она консистентна ВСЕГДА.

угу. Учить матчасть вам надо, юноша. 100мбпс это _линейная_ >скорость, а есть ещё скорость позиционирования. Т.е. вы не >учли время, за которое головка прыгает от дорожки к дорожке.

Вот я и сравниваю 2 разных ФС, в каждой из которых используются эти операции.

Попробуйте читать диск командой dd, но не подряд, а по 4К >рандомными блоками. У вас и получится 6мбпс.

Какой командой?

подтверждаю. Работает даже в слаке искароппки. Хотя я не пробовал.

Это btrfs, а топик про то что в Debian Wheezy есть zfs-fuse искаропки работающий даже на x32.
И при этом он увеличивает скорость даже находясь в файловом контейнере поверх других ФС.

Глупая твоя голова, год~два года назад над btrfs стоял гриф
«пожалуйста не используйте». Сейчас там всё сильно улучшилось..

Кстати про эксперименты: Сейчас в поисках правды нашел свой же 2 летней давности топик: Linux и файловые системы xfs,jfs,ext4,btrfs,squashfs. и вычитал там то из за чего «выкинул» btrfs:

n0mad

В ходе экспериментов btrfs не раз вставал в режим когда часть файлов не читалась. Перезагрузка исправляла ситуацию.
jfs при аварийном завершении всегда не монтировался и требовал длительной починки.
xfs и btrfs пока нормально монтируются при аварийной потере питания.

В том сравнении отсутствовала zfs

«каких» это devision by zero.

Почему это?

А под сколько я имел ввиду не объем... А скажем так - количество файлов.

Для того чтобы прочитать это «вдвое меньше» - надо найти где оно валяется, затем прочитать, затем распаковать и только затем отдать пожелавшему.

да. Причём сначала надо найти номер нужного блока, а потом подвести головку к этому блоку. Второе действие занимает примерно в 1000 раз больше времени, чем первое, и от ФС совершенно не зависит. Зато сильно зависит от случайных причин, и от компактности данных.

И да, если сжать данные вдвое, то вероятность их нахождения на одной дорожке тоже увеличивается вдвое. А это ускорение чтение в 1000 раз.

У zfs есть возможность и не сижимать файлы.

вот и сравнивай ext4 без сжатия с zfs без сжатия

или ext4 со сжатием и zfs со сжатием.

И никак иначе. Просто в твоём сравнении нет смысла.

При этом её создатели утверждают что она консистентна ВСЕГДА.

подумаешь? EXT4 тоже консистентна всегда. Например если оборвать на середине запись в файл, то он автоматически переходит в последние консистентное состояние, т.е. становится пустым, длинной 0 байт.

Вот я и сравниваю 2 разных ФС, в каждой из которых используются эти операции.

дык а что вы удивляетесь, что прочитать 2Гб вдвое дольше, чем 1Гб? Я вам больше скажу: сжатие не занимает времени вообще. Процессор сжимает/разжимает быстрее HDD и параллельно с ним. Т.е. сжатие абсолютно _не тормозит_ чтение.

Какой командой?

лень думать. Напишите скриптик. Hint, случайные числа лежат в $RANDOM.

Мне смысла нет, я и так знаю. А вам хочется разобраться. Вот и разбирайтесь, удачи.