форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

Сообщения по теме

[Сортировка по времени | RSS]

1. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–18 +/–
Сообщение от Unixwaynot linux on 31-Авг-10, 11:39
Вот они патенты) В итоге у линуха современная ФС будет очень не скоро... BTRFS до уровня продакшена еще пилить года три будут, если не больше. А ZFS уже спокойно можно использовать.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	5. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+14 +/–
	Сообщение от ы on 31-Авг-10, 12:18
	У "линуха" все "ФС" современные. И если ходили по ссылке нативная ZFS по скорости во всех тестах сливает ext4/btrfs.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	8. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–6 +/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 12:35
	> У "линуха" все "ФС" современные. И если ходили по ссылке нативная ZFS > по скорости во всех тестах сливает ext4/btrfs. === Реализация ZFS из  OpenSolaris на том же оборудовании продемонстрировала близкие с EXT4 и Btrfs показатели... === Коллега не удосужился прочитать текст новости? Напрасно, коллега, напрасно...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	9. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+12 +/–
	Сообщение от koblin (ok) on 31-Авг-10, 12:49
	В половине тестов ZFS продемонстировала показатели близкие к ZFS-FUSE, что значительно ниже ext4,btrfs... Коллега не удосужился сходить по ссылке?  Напрасно, коллега, напрасно...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	10. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–7 +/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 12:56
	Хм. Загадочная у вас половина. Единственный тест, в котором ZFS/Solaris была в 24 раза медленнее Линуксовых -- это многопоточная рандомная запись. Хотя есть ощущение, что тут проблема не в ZFS, а в каких-то других особенностях ядра. Или таки коллега сам не удосужился сходить по ссылке? Досадно... :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	17. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–3 +/–
	Сообщение от pavlinux (ok) on 31-Авг-10, 13:52
	>Хм. Загадочная у вас половина. > >Единственный тест, в котором ZFS/Solaris была в 24 раза медленнее Линуксовых -- >это многопоточная рандомная запись. > >Хотя есть ощущение, что тут проблема не в ZFS, а в каких-то >других особенностях ядра. > >Или таки коллега сам не удосужился сходить по ссылке? Досадно... :) Девочки не ссорьтесь, дисковые бенчмарки - лажа.   У меня bonnie++ на любой ФС выдаёт 93Mb/sec. (+/-2%) Так что, вся жопа в чипсете->проводе->диске.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	43. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от universite (ok) on 31-Авг-10, 15:44
	Все дело в кривых руках любую конфетку можно испортить кривыми настройками.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	45. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+2 +/–
	Сообщение от pavlinux (ok) on 31-Авг-10, 16:04
	>Все дело в кривых руках >любую конфетку можно испортить кривыми настройками. Причём тут руки, у меня диск ФИЗИЧЕСКИ не умеет быстрее 93 Mb/sec. писать. Так что, пока выбор только по стабильности. Юзаю XFS уж лет 7 (с 2.6.0), пока менять не собираюсь. BTRFS пока сильно грузит проц. EXT2 - ниайс, EXT3 - какой-то недоделыш, EXT4 - слишком поздно появилась, и после Reiser3 и XFS никатит. Reiserfs - хороша, шустра, ставлю на работе и другим, потому что XFS надо настраивать, а так лень :) JFS - лет 5 назад был тормознее XFS и больше проц, с тех пор забил на неё.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	53. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+3 +/–
	Сообщение от XoRe (ok) on 31-Авг-10, 16:55
	>[оверквотинг удален] >Так что, пока выбор только по стабильности. >Юзаю XFS уж лет 7 (с 2.6.0), пока менять не собираюсь. >BTRFS пока сильно грузит проц. >EXT2 - ниайс, >EXT3 - какой-то недоделыш, >EXT4 - слишком поздно появилась, и после Reiser3 и XFS никатит. >Reiserfs - хороша, шустра, ставлю на работе и другим, потому что XFS >надо настраивать, а так лень :) >JFS - лет 5 назад был тормознее XFS и больше проц, с >тех пор забил на неё. Не обескураживает ли то, что главный пилильщик рейзера, так сказать, отстранен от разработки?) Ну я про то, что может ext4 юзать вместо рейзера?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	77. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от pavlinux (ok) on 31-Авг-10, 19:22
	> Ну я про то, что может ext4 юзать вместо рейзера? Ну себе я точно пока не буду, а на другие десктопы - пофиг... почему бы и нет, за одно и потестить на юзерах :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	97. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+2 +/–
	Сообщение от Аноним (??) on 31-Авг-10, 21:45
	>Причём тут руки, у меня диск ФИЗИЧЕСКИ не умеет быстрее 93 Mb/sec. писать. Итого: ты забенчил свой диск а не свойства файловых систем. То есть ты попросту облажался. Так и запишем. >Так что, пока выбор только по стабильности. А попробуй записать 20 000 мелких файлов и директорий "на холодную" (без кеша) с секундомером. А попробуй потом список файлов из этой кашицы с секундомером? А слить 20Гб чушку? А чтоб еще и торентом? Дабы был множественный параллельный доступ к блокам и фрагментация? А потом тестануть скорость линейного чтения файла - не того? Вот если что-то в таком духе проделать - начнет приходить понимание того что не все йогурты одинаково полезны. >Юзаю XFS уж лет 7 (с 2.6.0), пока менять не собираюсь. Неплохая ФС, но некоторые операции с большим числом файлов там тормозные. Алсо гугл помнит наезды про забитие нулями файлов при крахе. Из плюсов - хорошо работает с большими файлами, параллелится на многодисковые конфиги на ура, не склонна к фрагментации, но по иронии до кучи есть дефрагер. Мне он ни разу не требовался, но он есть. Парни из SGI задали фрагментации жару :). >BTRFS пока сильно грузит проц. Ну так его пока еще даже стабильным не объявили. >EXT2 - ниайс, Выбор любителей окаменелостей. Хотя на флешке в принципе как замена FAT читаемая под оффтопиком - сойдет. >EXT3 - какой-то недоделыш, Тормозной. Зато надежный и утилиты для починки упорные - до последнего пыжатся том починить. Там где остальные загибаются, оно может даже что-то отколупать. Избавив вас от копания с хексэдитором и photorec если бэкапа не оказалось. В остальном то же что и ext2. >EXT4 - слишком поздно появилась, и после Reiser3 и XFS никатит. Вполне себе катит. Оно резвее XFS на некоторых операциях. На однодисковых конфигах оно ему особо не уступит. Вообще приятная и резвая ФС, хоть и с архаизмами. И дефрагера нет. Но в целом недурненько. >Reiserfs - хороша, шустра, ставлю на работе и другим, Врагам ее надо ставить. Чтоб когда у них порушится том, они понаблюдали как fsck том окончательно угробит вместо починки. Процент таких воплей vs процент юзающих эту фс как-то не вкусный. ФС для тех у кого есть регулярные бэкапы и упсина. > потому что XFS л надо настраивать, а так лень :) Даже с настройкой некоторые операции с файлами у него довольно тормозные.И, кстати при некоторых операциях XFS не дурак погрузить проц. >JFS - лет 5 назад был тормознее XFS и больше проц, Ни рыба ни мясо. Проц жрет меньше XFS имхо. Но и работает не особо резво. При наличии ext4 и xfs - смысла в нем не так уж много. Просто средненькая такая ФС. Пусть будет, может кому понравится как альтернатива упомянутым при некоторых нагрузках. >с тех пор забил на неё. Мало что потерял наверное.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	103. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от pavlinux (ok) on 31-Авг-10, 23:11
	>>Причём тут руки, у меня диск ФИЗИЧЕСКИ не умеет быстрее 93 Mb/sec. писать. > >Итого: ты забенчил свой диск а не свойства файловых систем. То есть >ты попросту облажался. Так и запишем. На, пиши... # iozone -a -b bench.xls -+u -p -B -e -E > >>Так что, пока выбор только по стабильности. > >А попробуй записать 20 000 мелких файлов и директорий "на холодную" (без >кеша) с секундомером. Дочитай все сообщения до конца. > А попробуй потом список файлов из этой кашицы с секундомером? А слить 20Гб чушку? > А чтоб еще и торентом? Дабы был множественный параллельный доступ к блокам и > фрагментация? А потом тестануть скорость линейного чтения файла - не того? > Вот если что-то в таком духе проделать - начнет приходить понимание того что > не все йогурты одинаково полезны. При таких мутациях, на одной и тоже FS, или даже на одном и том же компе, Вы сами дважды не повторите результат. Даже с погрешностями в измерениях. Кстати, запись и тем более чтение торрента, можно приравнять к RANDOM R/W.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	189. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Аноним (??) on 02-Сен-10, 15:17
	>На, пиши... ># iozone -a -b bench.xls -+u -p -B -e -E И? Если в тестах всех фс получается одинаковое значение - значит ты протестил что угодно кроме поведения ФС при нагрузке. У разных алгоритмов - разные свойства. Ты хочешь доказать обратное? Тогда докажи математически что O(N) == O(log N) == O (1) чтоли. Или с фига ли список файлов линейным списком будет столь же быстр как b-дерево, например? Туда же и битовые карты vs экстенты и прочая. >Вы сами дважды не повторите результат. Даже с погрешностями в измерениях. Да, для торента это и правда будет сделать крайне сложно (придется сгородить целый тестлаб). В таком случае можно собрать усредненную статистику, так что выпады в ту или иную сторону в единичных случаях будут мало влиять, а вот свойства ФС в целом - неизбежно проявятся. >Кстати, запись и тем более чтение торрента, можно приравнять к RANDOM R/W. Не совсем так. Сильно зависит от торент-клиента и его стратегии поведения и настроек. Они разные бывают. Кто-то преаллоцирует файлы целиком, а кто-то - нет. Кто-то делает упреждающее чтение, а кто-то нет. Кто-то буферит получаемые блоки так, а кто-то эдак. Но в целом торент является очень забавным методом посмотреть как ФС ведет себя в тяжелых случаях. К слову, так можно подгадить даже XFS, хоть он и могуче сопротивляется фрагментации.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	122. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от ы on 01-Сен-10, 09:50
	>>EXT4 - слишком поздно появилась, и после Reiser3 и XFS никатит. > >Вполне себе катит. Оно резвее XFS на некоторых операциях. На однодисковых конфигах >оно ему особо не уступит. Вообще приятная и резвая ФС, хоть >и с архаизмами. И дефрагера нет. Но в целом недурненько. дефрагер таки есть e4defrag
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	70. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Аноним (??) on 31-Авг-10, 18:27
	>любую конфетку можно испортить кривыми настройками. Тогда скажите, о Гуру, что мне сделать чтобы FAT32 стал позволять файлы более 4Гб и перестал тормозить на директориях с тысячами файлов. Сменить ФС - не предлагать. Хинт: кроме рук у ФС есть сильные и слабые стороны еще. Вытекающие из особенностей дисковых структур конкретных ФС.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	71. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Аноним (??) on 31-Авг-10, 18:33
	подскажите что надо сделать что бы ext3 смог понимать больше 30к файлов в директории? и что бы попытка сделать cd или readdir в такой директории не заканчивалась большими тормозами ?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	79. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от szh (ok) on 31-Авг-10, 19:34
	> подскажите что надо сделать что бы ext3 смог понимать больше 30к файлов в директории? Сконвертировать ее в ext4. > и что бы попытка сделать cd или readdir в такой директории не заканчивалась большими тормозами ? проверь чтобы -O dir_index было включено (man tune2fs) (после включения возможно надо скопировать файлы в дир снова, не знаю)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	98. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от злодейко on 31-Авг-10, 21:45
	Ничего копировать не надо - можно прогнать fsck с оптимизацией директорий. В зависимости от условий эксплуатации.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	80. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от pavlinux (ok) on 31-Авг-10, 19:35
	>подскажите что надо сделать что бы ext3 смог понимать больше 30к файлов >в директории? >и что бы попытка сделать cd или readdir в такой директории не >заканчивалась большими тормозами ? Ultra320 SCSI   SAS/SAS II в первых двух диски на 15000 об., SSD SLC Внешний PCI-X SATA II контроллер с кэшем поболее. RAID5 замутить
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	86. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от pavlinux (ok) on 31-Авг-10, 19:55
	>подскажите что надо сделать что бы ext3 смог понимать больше 30к файлов >в директории? >и что бы попытка сделать cd или readdir в такой директории не >заканчивалась большими тормозами ? /opt/test # for i in `seq 1 300000`; do echo $i > $i; done; /opt/test # cd / / # time cd /opt/test; time ls | wc -l ; time stat * > /dev/null; cd / real    0m0.000s user    0m0.000s sys     0m0.000s 300000 real    0m1.425s user    0m0.671s sys     0m0.106s real    0m14.958s user    0m9.259s sys     0m4.918s
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	87. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от pavlinux (ok) on 31-Авг-10, 19:55
	>>подскажите что надо сделать что бы ext3 смог понимать больше 30к файлов >>в директории? >>и что бы попытка сделать cd или readdir в такой директории не >>заканчивалась большими тормозами ? > >/opt/test # for i in `seq 1 300000`; do echo $i > $i; done; Ой, я случайно 300.000 написал :) ---------- # hdparm -i /dev/sda Kingston SSDNow V Series 64GB, FwRev=B090522a # cat /proc/mounts | grep root /dev/root / xfs rw,delaylog,nodev,noatime,nodiratime,attr2,noquota 0 0
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	92. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 20:50
	> /dev/root / xfs rw,delaylog,nodev,noatime,nodiratime,attr2,noquota 0 0               ~~~ Читер detected. :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	78. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от MORPEH on 31-Авг-10, 19:27
	fullfat или fastfat использовать
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	159. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Mikula on 01-Сен-10, 15:39
	>>любую конфетку можно испортить кривыми настройками. > >Тогда скажите, о Гуру, что мне сделать чтобы FAT32 стал позволять файлы >более 4Гб и перестал тормозить на директориях с тысячами файлов. Сменить >ФС - не предлагать. exFat http://ru.wikipedia.org/wiki/ExFAT
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	69. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Аноним (??) on 31-Авг-10, 18:22
	>У меня bonnie++ на любой ФС выдаёт 93Mb/sec. (+/-2%) А что ты бенчишь? А то если бенчить чтение RAW девайса то там наверное тоже будет что-то типа 93 мб/сек. Кстати при чтении raw девайса почему-то вообще не важно какая там ФС, скорость почему-то одинаковая. Я что-то делаю не так? :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	88. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от pavlinux (ok) on 31-Авг-10, 20:02
	>>У меня bonnie++ на любой ФС выдаёт 93Mb/sec. (+/-2%) > >А что ты бенчишь? А то если бенчить чтение RAW девайса то >там наверное тоже будет что-то типа 93 мб/сек. Кстати при чтении >raw девайса почему-то вообще не важно какая там ФС, скорость почему-то >одинаковая. Я что-то делаю не так? :) Ой, перепутал не bonnie++, IOZone канешна.. Строка запуска такая: iozone -a -b bench.xls -+u -p -B -e -E
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	142. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от анонимиус on 01-Сен-10, 12:26
	>У меня bonnie++ на любой ФС выдаёт 93Mb/sec. (+/-2%) Я вообще плохо понимаю, чего она выдает. :D Юзаю iozone.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	14. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+5 +/–
	Сообщение от JL2001 (ok) on 31-Авг-10, 13:07
	>> У "линуха" все "ФС" современные. И если ходили по ссылке нативная ZFS >> по скорости во всех тестах сливает ext4/btrfs. > >=== >Реализация ZFS из  OpenSolaris на том же оборудовании продемонстрировала близкие с >EXT4 и Btrfs показатели... >=== > >Коллега не удосужился прочитать текст новости? Напрасно, коллега, напрасно... а если бы коллега посмотрел на первоисточник он бы увидел что нативный солярисный  zfs во многих тестах сливает btrfs в 2-3 раз и ext4 в 10+ раз, и только в некотрых на равне с btrfs, кроме теста PostgreSQL где выигрывает в 2 раза у бтрфс и сильно проигрывает ext4 зы: лично для меня это как-то странно, зфс вроде пилили долго и упорно, неужели почти все усилия ушли в удобство организации дискового пространства а не в быстродействие ?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	15. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+2 +/–
	Сообщение от anonymous (??) on 31-Авг-10, 13:12
	>зфс вроде пилили долго и упорно, неужели почти все усилия ушли в удобство организации дискового пространства а не в быстродействие ? Похоже на то, что в кое-чьем представлении enterprise - это прежде всего админы с квалификацией не выше эникейщика, для которых надо все упрощать. А высокие скорости, высокие нагрузки, быстрое восстановление после сбоя - все это как бы не имеет ничего общего с enterprise.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	55. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от XoRe (ok) on 31-Авг-10, 16:57
	>>зфс вроде пилили долго и упорно, неужели почти все усилия ушли в удобство организации дискового пространства а не в быстродействие ? > >Похоже на то, что в кое-чьем представлении enterprise - это прежде всего >админы с квалификацией не выше эникейщика, для которых надо все упрощать. Ваши намеки неясны, а логика туманна. Озвучьте замысел слов ваших. >А высокие скорости, высокие нагрузки, быстрое восстановление после сбоя - все это >как бы не имеет ничего общего с enterprise. - высокие скорости, - высокие нагрузки, - быстрое восстановление после сбоя Судя по графикам, сейчас ZFS может выдавать любые 2 из трех. Собственно, поэтому комрад и задал вопрос)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	27. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 14:47
	>а если бы коллега посмотрел на первоисточник он бы увидел что нативный >солярисный  zfs во многих тестах сливает btrfs в 2-3 раз Так. Смотрим ещё раз в Фороникс (данные приведены для пары BtrFS:Solaris ZFS): 546,42 : 1296,20 (чем больше, тем лучше) 2110,0 : 660,0 (чем больше, тем лучше) 12,02 : 11,78 (чем меньше, тем лучше) 99,58 : 102,63 (чем больше, тем лучше) 128,97 : ниже погрешности измерений (чем больше, тем лучше) Итого: ZFS показывает БОЛЬШУЮ, чем BtrFS, производительность в ТРЁХ случаях, и МЕНЬШУЮ -- в двух. При, заметим, СУЩЕСТВЕННО меньшей нагрузке на микропроцессор. И вот откуда вы взяли своё утверждение? Ну вот откуда? Монитор барахлит?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	41. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от ы on 31-Авг-10, 15:33
	а нахига так место по-ниже спины то рвать? есть какой-то интерес? в альтруизме вы вроде не замечены были. ps: не забываем, вся эта бодяга проходит на SSD. где экспериментальный бтр по-жизни сливал. при этом zfs должен (по анонсам) порвать всех. а в результате - zfs показывает ведёт себя как генератор случайных чисел. в последнем тесте вообще не отдуплился. вывод: для файлопомоек - мэй би. для всего остального - лучше уж пусть старым, дедовским, но проверенным способом.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	51. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–2 +/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 16:50
	> а нахига так место по-ниже спины то рвать? > есть какой-то интерес? в альтруизме вы вроде не замечены были. Есть. Заткнуть рты особо "хитро читающим". Просто достаёт "журнализм". Берём данные, и делаем из них нужные нам выводы. Меня это раздражает. ;) > не забываем, вся эта бодяга проходит на SSD. > где экспериментальный бтр по-жизни сливал. при этом zfs должен (по анонсам) порвать > всех. Йопта. Ещё один специалист по ZFS. ZFS с SSD работает нормально только тогда, когда на SSD лежит строго одна вещь -- ZFS Intent Log. ZIL. ZIL! А не данные! Вы ж поймите, что SSD на _переписывание_ работает достаточно медленно -- to prevent cell wearing-out. А ZFS переписывать любит. При _дописывании_ блока в конец файла _переписывается_ предпоследний. > вывод: для файлопомоек - мэй би. О, да. Особенно после теста с pgBench'ем. ;) > для всего остального - лучше уж пусть старым, дедовским, но проверенным способом. Да это-то завсегда пожалуйста. Хоть лавсановую перфоленту муравьиной кислотой травите. ;)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	61. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Аноним (??) on 31-Авг-10, 17:43
	Скажите уж честно: вас достает то что в вашей бзде нету ext4 и btrfs. Вот вы и носитесь с ZFS как с писаной торбой. Больше выбирать все-равно не из чего. В итоге приходится скатываться к задоприкрывательским формулировкам вида "Берём данные, и делаем из них нужные нам выводы. Меня это раздражает. ;)". Дескать, это все заговор фороникса и вообще данные не те. Вот такое жопоприкрывательство вместо признания слабых мест конкретной ФС - раздражает. Потому что игнорируется что в мире есть не только ZFS и BSD например и что остальные могут внезапно оказаться лучше. > При _дописывании_ блока в конец файла _переписывается_ предпоследний. Это как? По идее copy-on-write должен записать блок в сторонку а старый вообще не трогать. Или как потом к снапшоту например со старой версией файла откатываться если блок с этими данными уже перезаписан и возврата нет?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	64. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–2 +/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 17:51
	> Дескать, это все заговор фороникса Да в том то и дело, что Phoronix приводит довольно адекватные данные. А вот комментаторы с OpenNet'а их... э-э-э-э-э-э... несколько вольно интерпретируют. :) >и вообще данные не те. Вот такое жопоприкрывательство вместо признания слабых >мест конкретной ФС - раздражает. Потому что игнорируется что в мире >есть не только ZFS и BSD например и что остальные могут >внезапно оказаться лучше. Мир внезапно окажется лучше целиком, если люди перестанут интерпретировать результаты экспериментов таким образом, чтобы они удовлетворяли их ожиданиям. Почти Dag-Erling Coodan Smorgrav. :) >> При _дописывании_ блока в конец файла _переписывается_ предпоследний. >Это как? По идее copy-on-write должен записать блок в сторонку а старый >вообще не трогать. Или как потом к снапшоту например со старой >версией файла откатываться если блок с этими данными уже перезаписан и >возврата нет? Почитайте, как устроен ZFS. При записи блока контрольная сумма его записывается в предыдущий в цепочке -- это исключает появление ошибок в файлах при сбоях в адресации дискового пространства.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	72. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+2 +/–
	Сообщение от ы on 31-Авг-10, 18:36
	>Мир внезапно окажется лучше целиком, если люди перестанут интерпретировать результаты экспериментов таким образом именно. поэтому не понятен ваш предвзятый вывод - "zfs прекрасна в своём торможении". кстати, вы это другим специалистам рассказывайте, а факт - осёл (мир его праху) с zfs требует в минимале 768мб; писибсд - 1гб. и вы можете сколько угодно говорить о "прямых" (но не очень чистых) руках, этот факт сие не изменит.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	81. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 19:40
	> кстати, вы это другим специалистам рассказывайте, а факт - осёл (мир его праху) > с zfs требует в минимале 768мб; Да вы что? OpenSolaris OS native install: 512 MB minimum Только что прочитал на присланном когда-то Sun'ом фирменном диске с OpenSolaris'ом. Ну как же достали "специалисты" с OpenNet'а...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	99. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+1 +/–
	Сообщение от Аноним (??) on 31-Авг-10, 21:55
	>OpenSolaris OS native install: 512 MB minimum Как-то оно конечно работать будет, но если воткнуть ZFS на машину с 512 мегов, забенчить и сравнить с ext4, btrfs или чем там еще на этой конфиге - вы будете опять верещать про то что дескать конфиг хреновый, руки кривые и вообще все п-сы. Потому что на машине с 512 мегами ZFS вообще ничего такого не сможет показать.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	101. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 23:09
	Так. Было утверждение: OpenSolaris требует минимум 768 мегабайт ОЗУ. Было опровержение: Sun Microsystems пишет, что он требует 512 мегабайт. Разговор про бенчмарки вообще шёл?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	110. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+1 +/–
	Сообщение от минона on 01-Сен-10, 04:19
	конечно. тут вообще вся новость про бенчмарки. и рекомендуемое озу таки 768. особенно с дев. хотя это уже и не важно. сдох бобик.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	130. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от Andrew Kolchoogin on 01-Сен-10, 10:27
	> конечно. > тут вообще вся новость про бенчмарки. Но thread не только о них. > и рекомендуемое озу таки 768. особенно с дев. Именно. Однако, обратимся к посту, на который я отвечал: === кстати, вы это другим специалистам рассказывайте, а факт - осёл (мир его праху) с zfs требует в минимале 768мб; === Вам фореграундом по бэкграунду написали -- "требует в минимале". Вот я и написал, сколько OpenSolaris ДЕЙСТВИТЕЛЬНО требует в минимальной конфигурации. А вы с пеной у рта пытаетесь защищать человека, который облажался. ;)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	136. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от минона on 01-Сен-10, 11:29
	глупости. с пеной у рта тут только вы. вам нравится? используйте. чё раскричались то? мне - нет. мне вообще не нравятся фс с сомнительной перспективой, тормозящие и требующие эндцать мегов (гигов) озу только для себя любимой.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	115. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от ы on 01-Сен-10, 08:54
	>Так. > >Было утверждение: OpenSolaris требует минимум 768 мегабайт ОЗУ. >Было опровержение: Sun Microsystems пишет, что он требует 512 мегабайт. И чё? Вон каноникал пишет что для убунты 256 метров хватит. Давайте не путать минимальные требования с рекомендованными. >Разговор про бенчмарки вообще шёл? <К.0.>Ну типа новость о них</K.0>
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	74. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+3 +/–
	Сообщение от Аноним (??) on 31-Авг-10, 18:40
	>Да в том то и дело, что Phoronix приводит довольно адекватные данные. И по ним видно что под рядом нагрузок ZFS сливается. В то время как EXT4 с честью держит большинство нагрузок. И btrfs ряд нагрузок держит лучше. Может быть, дело в том что блочное выделение места вместо экстентов было модно в прошлом веке? >А вот комментаторы с OpenNet'а их... э-э-э-э-э-э... несколько вольно интерпретируют. :) Вы главное в своем глазу бревно не забудьте. >Мир внезапно окажется лучше целиком, если люди перестанут интерпретировать результаты экспериментов таким >образом, чтобы они удовлетворяли их ожиданиям. Почти Dag-Erling Coodan Smorgrav. :) Ну знаете, если в threaded бенче zfs показывает 5 мегов в секунду, сливая и ext4 и btrfs в десятки раз - epic fail дизайна фс под такой нагрузкой - очевиден. Видать нагрузка неудобная оказалась. Наверное потому и рекомендуют гигазы оперативы под буфера - чтобы косяки дизайна фс немеряными буферами вытягивать. >Почитайте, как устроен ZFS. При записи блока контрольная сумма его записывается в >предыдущий в цепочке -- это исключает появление ошибок в файлах при >сбоях в адресации дискового пространства. В какой из док это в таком виде написано? URL? Какие-то странные сведения и странная операция: перезапись - это всегда шанс угробить данные в перезаписываемом блоке. Зачем трогать лишний раз старые блоки, если в таком дизайне ФС они могут потребоваться потом? Вроде ж идея copy-on-write как раз в том чтобы старые данные лишний раз не трогать?!
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	83. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 19:45
	>>Да в том то и дело, что Phoronix приводит довольно адекватные данные. >И по ним видно что под рядом нагрузок ZFS сливается. В то >время как EXT4 с честью держит большинство нагрузок. И btrfs ряд >нагрузок держит лучше. Может быть, дело в том что блочное выделение >места вместо экстентов было модно в прошлом веке? Ну да. Под частью нагрузок сливается один дизайн FS, под частью -- другой. А Ext4 вообще doesn't count -- или ответьте на мой вопрос чуть выше по thread'у про распределение нагрузки по пулу. >>А вот комментаторы с OpenNet'а их... э-э-э-э-э-э... несколько вольно интерпретируют. :) >Вы главное в своем глазу бревно не забудьте. А вы на личности-то не переходите. Я конкретно вам никаких высказываний не адресовал. И помните -- Argumentum ad Hominem -- признанный Epic Fail в полемике. ;) >>Мир внезапно окажется лучше целиком, если люди перестанут интерпретировать результаты экспериментов таким >>образом, чтобы они удовлетворяли их ожиданиям. Почти Dag-Erling Coodan Smorgrav. :) >Ну знаете, если в threaded бенче zfs показывает 5 мегов в секунду, >сливая и ext4 и btrfs в десятки раз - epic fail >дизайна фс под такой нагрузкой - очевиден. Видать нагрузка неудобная оказалась. >Наверное потому и рекомендуют гигазы оперативы под буфера - чтобы косяки >дизайна фс немеряными буферами вытягивать. А вот вам бы я посоветовал дочитать статью на Форониксе до конца. Авторы пишут, что есть подозрение, что это Bottleneck in Nevada Kernel. >>Почитайте, как устроен ZFS. При записи блока контрольная сумма его записывается в >>предыдущий в цепочке -- это исключает появление ошибок в файлах при >>сбоях в адресации дискового пространства. >В какой из док это в таком виде написано? URL? Какие-то странные >сведения и странная операция: перезапись - это всегда шанс угробить данные >в перезаписываемом блоке. Зачем трогать лишний раз старые блоки, если в >таком дизайне ФС они могут потребоваться потом? Вроде ж идея copy-on-write >как раз в том чтобы старые данные лишний раз не трогать?! Охъ. В ZFS Design Guide это написано. На Sun Tech Days сто раз говорилось.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	116. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+1 +/–
	Сообщение от ы on 01-Сен-10, 08:58
	>На Sun Tech Days сто раз говорилось. Я уже по вашим запощенным новостям понял что вы "солярщик", и весь смысл вашей активности заключается в принижение linux и возвышение за счет этого "солярки".
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	129. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от Andrew Kolchoogin on 01-Сен-10, 10:24
	> Я уже по вашим запощенным новостям понял что вы "солярщик", и весь > смысл вашей активности заключается в принижение linux и возвышение за счет > этого "солярки". Я так понимаю, что напал на "красноглазого". ;) Объясняю в 121'й раз: мне совершенно наплевать, как называется технология -- UNIX, Windows, VxWorks, или как либо ещё. Мне совершенно наплевать, кто и как эту технологию разрабатывает -- open source она, не open, GPL, BSD, APL, MPL или любой другой лицензии. И когда люди начинают сравнивать технологии не с позиций цифр в тестах (а я специально трижды перечитал статью с Фороникса и выписал с неё цифры тестов нативных технологий, а не костылей, типа FUSE/etc.), а с позиций того, кто _автор_ технологии, и её _лицензии_ -- меня это приводит в состояние кататонического ступора и когнитивного диссонанса одновременно. :) Ну ведь ёжику понятно, что если Ext4 повесить поверх LVM'а, а в ZFS выключить подсчёт контрольных сумм (чтобы скомпенсировать overhead'ы), то ZFS надерёт Ext4 задницу по полной программе за счёт агрессивного кеширования. Но! "One can be arbitrarily fast if data integrity isn't a question". (C) ZFS Evil Tuning Guide. Поэтому сравнивать Ext4 и ZFS -- это сравнивать автомобиль с самолётом. В ZFS есть сквозная data integrity, в Ext4 -- нет и не предвидится. Поэтому сравнение здесь непоказательно. А данные по сравнению BtrFS и ZFS я привёл в самом начале thread'а -- сравнение, увы, не в пользу BtrFS. ;) И линуксячьи хомячки могут хоть на пузе извертеться -- всё равно не в пользу. ;)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	134. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от ы on 01-Сен-10, 10:57
	>> Я уже по вашим запощенным новостям понял что вы "солярщик", и весь >> смысл вашей активности заключается в принижение linux и возвышение за счет >> этого "солярки". > >Я так понимаю, что напал на "красноглазого". ;) Отлично, надо объявить опонента красноглазым, это оправдает свой фанатизм. >Объясняю в 121'й раз: мне совершенно наплевать, как называется технология -- UNIX, >Windows, VxWorks, или как либо ещё. Мне совершенно наплевать, кто и >как эту технологию разрабатывает -- open source она, не open, GPL, >BSD, APL, MPL или любой другой лицензии. что ты делаешь на этом ресурсе? >И когда люди начинают сравнивать технологии не с позиций цифр в тестах >(а я специально трижды перечитал статью с Фороникса и выписал с >неё цифры тестов нативных технологий, а не костылей, типа FUSE/etc.), а >с позиций того, кто _автор_ технологии, и её _лицензии_ -- меня >это приводит в состояние кататонического ступора и когнитивного диссонанса одновременно. :) Однако забыл выписать цифры с ext4, видимо из-за когнитивного диссонаса. >Ну ведь ёжику понятно, что если Ext4 повесить поверх LVM'а, а в >ZFS выключить подсчёт контрольных сумм (чтобы скомпенсировать overhead'ы), то ZFS надерёт >Ext4 задницу по полной программе за счёт агрессивного кеширования. Если танк доработать напильником то получится самолет и то не факт. >Но! "One can be arbitrarily fast if data integrity isn't a question". >(C) ZFS Evil Tuning Guide. Поэтому сравнивать Ext4 и ZFS -- >это сравнивать автомобиль с самолётом. В ZFS есть сквозная data integrity, >в Ext4 -- нет и не предвидится. Поэтому сравнение здесь непоказательно. Да да, побольше английского, ничего на сказав вы можете получить эффект что ваш опонент испугается и убежит. > >А данные по сравнению BtrFS и ZFS я привёл в самом начале >thread'а -- сравнение, увы, не в пользу BtrFS. ;) да ну? >И линуксячьи хомячки могут хоть на пузе извертеться -- всё равно не >в пользу. ;) Откровено ведь грубите.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	178. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–2 +/–
	Сообщение от Школьник (ok) on 01-Сен-10, 22:27
	>Отлично, надо объявить опонента красноглазым, это оправдает свой фанатизм. Слово "солярщик" первым употребили именно вы. >что ты делаешь на этом ресурсе? Я вот всегда думал, что опеннет - прежде всего для инженеров. А уж какие у них убеждения в глубине души - это второй вопрос. До тех пор, пока они не обсуждают здесь оффтопик, все хорошо. Или я неправ? >Да да, побольше английского, ничего на сказав вы можете получить эффект что >ваш опонент испугается и убежит. Если у вас проблемы с чтением английского, воспользуйтесь Google Translate. Инженерам, которые работают в области IT, без знания английского делать в отрасли нечего. А та английская фраза, которую он привел, вполне себе в тему. >>И линуксячьи хомячки могут хоть на пузе извертеться -- всё равно не >>в пользу. ;) > >Откровено ведь грубите. Кому как. Лично я бы предпочел срач с Луговским с его незабвенным "удавись, мразь" в свой адрес любой другой беседе с дураком, который меня будет называть "милостивый государь" и во всем со мной соглашаться. Первое как-то информативнее.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	184. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Аноним (??) on 02-Сен-10, 12:57
	>Ну да. Под частью нагрузок сливается один дизайн FS, под частью -- другой. И что характерно - схемы с экстентами в целом работают лучше чем схемы с поблочным выделением. Загнать в ж можно любую, но варианты с экстентами более жопоупорны. Поэтому практически все фс новой разработки используют экстенты. Кстати они есть в ext4 и в btrfs но их нет в zfs. Может быть это одна из причин ее тормознутости в ряде бенчей? >А Ext4 вообще doesn't count -- или ответьте на мой >вопрос чуть выше по thread'у про распределение нагрузки по пулу. А мозг включить и подумать? Распределением нагрузки на несколько дисков может заниматься как сама ФС так и иной слой под ней, например. И в линухе есть где развернуться на этот счет. Да, может это и менее удобно, но вполне реализуемо в случае если оно надо. Странно что такая простая истина так трудно доходит. >А вы на личности-то не переходите. Не буду. Но если кто-то тормозит - я в своем праве отметить этот факт. >А вот вам бы я посоветовал дочитать статью на Форониксе до конца. >Авторы пишут, что есть подозрение, что это Bottleneck in Nevada Kernel. Ага, а если взять бсд - при сливе начнуть бухтеть что фс в системе без году неделя и еще не отлажена. Что ж тогда брать то? Сферический zfs в вакууме? И вообще, zfs у самого по себе bottleneck-ов найдется. Загнать его в Ж с его блочной аллокацией вообще судя по всему ни проблема ни разу. >Охъ. В ZFS Design Guide это написано. На Sun Tech Days сто >раз говорилось. Почитаю, перепроверю. Странное какое-то решение - лишний раз блоки данных трогать.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	105. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от universite (ok) on 31-Авг-10, 23:31
	>а в результате - zfs показывает ведёт себя как генератор случайных чисел. > >в последнем тесте вообще не отдуплился. >вывод: для файлопомоек - мэй би. >для всего остального - лучше уж пусть старым, дедовским, но проверенным способом. Неплохо ведет ZFS raid1 в работе с nginx+php+php-fpm+Mysql Юзеры сидят, работают и не жужжат.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	137. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от минона on 01-Сен-10, 11:31
	дык как обычно. пусть ещё только попробуют пожужжать.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	185. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Аноним (??) on 02-Сен-10, 13:09
	>Неплохо ведет ZFS raid1 в работе с nginx+php+php-fpm+Mysql А сравнивалось с чем? Ни с чем, как обычно? Ну так это неинтересно тогда. Я тоже могу что-то сгородить и вещать как это хорошо. Вот только большой вопрос как мое решение будет в сравнении с другими. А так сабжевую связку может запустить даже неглупый школьник. А вот грамотно выбрать решение из всего арсенала имеющихся так чтобы оно оптимально вписалось в задачу - школьник уже не сможет.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	42. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+1 +/–
	Сообщение от ы on 31-Авг-10, 15:42
	ну типа тестов больше чем пять, и есть еще ext4 про которую вы умалчиваете.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	49. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 16:44
	> ну типа тестов больше чем пять В остальных тестах ZFS/Solaris не участвовала (или Phoronix не привёл данные). > и есть еще ext4 про которую вы умалчиваете. Сравнение ZFS (BtrFS) с Ext4 -- это сравнение самолёта с автомобилем. Ext4 _ничего_ не умеет. В своё время в -CURRENT FreeBSD v5 была такая IFS -- iNode File System. Так она по производительности вообще всех рвала в тряпки. ;) Можете поковыряться и посмотреть, что это было. ;)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	58. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Аноним (??) on 31-Авг-10, 17:30
	>В остальных тестах ZFS/Solaris не участвовала (или Phoronix не привёл данные). Свинство, факт. >Сравнение ZFS (BtrFS) с Ext4 -- это сравнение самолёта с автомобилем. Ext4 >_ничего_ не умеет. А ничего что в Linux нужные слои типа райдов и управления томами - есть? При необходимости ext4 начинает уметь и райды и добавление томов в пул. Менее изящно но вполне работает. >В своё время в -CURRENT FreeBSD v5 была такая IFS -- iNode >File System. Так она по производительности вообще всех рвала в тряпки. >;) Можете поковыряться и посмотреть, что это было. ;) Кому-то нужны лулзы, а кому-то работать. С линухом работать приятнее - там всегда под задачу есть что выбрать. А бздуны выбирают из ZFS и UFS, при том первый очень не любит некоторые типы нагрузок, характерных для серверов а второе - ископаемое. Итого - zfs может претендовать на сильно некоторые файлопомойки. Если оракль патентами размахивать не начнет.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	63. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–2 +/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 17:47
	>> В остальных тестах ZFS/Solaris не участвовала (или Phoronix не привёл данные). > Свинство, факт. Или из страха?-) >> Сравнение ZFS (BtrFS) с Ext4 -- это сравнение самолёта с автомобилем. Ext4 >> _ничего_ не умеет. > А ничего что в Linux нужные слои типа райдов и управления томами > - есть? При необходимости ext4 начинает уметь и райды и добавление > томов в пул. Менее изящно но вполне работает. Да? Ext4 может распараллеливать нагрузку между пятью дисками в пуле? Ext4 может сказать об этом другим слоям? > Итого - zfs может претендовать на сильно некоторые файлопомойки. Победив в pgBench'е. Чудесная логика. Вы файлы в BLOB'ах держать предлагаете?-)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	73. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+1 +/–
	Сообщение от ы on 31-Авг-10, 18:39
	>Или из страха?-) угу. кольчугина испугались. >Победив в pgBench'е. Чудесная логика. Вы файлы в BLOB'ах держать предлагаете?-) не иначе - результат испуга
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	82. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–2 +/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 19:42
	А вы не сливайтесь, не сливайтесь. :) Я не кусаюсь. :) Так что, может ваша хвалёная Ext4 распределять нагрузку по пяти дискам пула?-) Или хотя бы сказать об этом соответствующему Layer'у?-)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	93. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Аноним (??) on 31-Авг-10, 21:20
	>Так что, может ваша хвалёная Ext4 распределять нагрузку по пяти дискам пула?-) Сама по себе она конечно этого не умеет. Однако можно ведь собрать скажем страйп из 5 дисков и тогда при достаточной интенсивности операций с файлами, особенно если это большие объемы или несколько потоков - доступ будет размазан на все диски. Сами догадайтесь почему. Эффективность по скорости будет не сильно хуже иных вариантов. А какая дискам разница кто там на одновременно читаемые/записываемые блоки попилил - уровень ФС или тот кто изображает райд? >Или хотя бы сказать об этом соответствующему Layer'у?-) А тут все зависит от целей. Если цель - решить задачу то есть 1000 возможностей. А если цель встать в позу и сказать "фи, гадость" - есть 1000 отговорок. Вам видимо важнее второе.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	94. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 21:37
	Нет, друг мой, stripe -- это плохо. И вот почему. Вы себе представляете работу с дисковым массивом таким образом: системный администратор берёт хрустальный шар, внимательно смотрит в него, и в его голове автоматически появляются сведения, где ему нужно приобрести пять одинаковых (для stripe это важно!) дисков, и какого они должны быть объёма. Не подскажете ли, у кого можно такой хрустальный шар на время одолжить?-) У меня есть несколько вещей, которые мне срочно надо узнать. ;) А на самом деле всё происходит совсем не так. У нас есть дисковая полка (или сервер с местом под 8..16 HDD). Мы в него вставляем 3 диска. Делаем RAIDZ. Оно у нас живёт. Кончается дисковое место -- мы вставляем ещё 3 диска (возможно, другого объёма, чем первые три -- диски-то совершенствуются!) Понятное дело, что некоторое первое время они практически не загружены -- но ZFS постепенно "размазывает" данные на наши шесть дисков. Причём не поровну, а так, чтобы сбалансировать I/O по всем каналам (она же на всех уровнях присутствует, эта ZFS, так что знает, на какой физический канал контроллера сколько пишется). И плевать, что у дисков геометрия разная, что скорость работы разная... Всё равно результат будет правильным. Кончились? Что ж, давайте ещё троечку добавим... ;) Идея ясна? А вы -- stripe... ;) Умеет Ext4 (+всё, что угодно там) такое?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	95. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 21:42
	> Делаем RAIDZ. Или mirror, или просто тома. Это неважно. RAIDZ -- это я так, чтобы надёжность хранения была.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	100. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от злодейко on 31-Авг-10, 21:56
	>Нет, друг мой, stripe -- это плохо. И вот почему. > >Вы себе представляете работу с дисковым массивом таким образом: системный администратор берёт >хрустальный шар, внимательно смотрит в него, и в его голове автоматически >появляются сведения, где ему нужно приобрести пять одинаковых (для stripe это >важно!) дисков, и какого они должны быть объёма. как связан размер страйпа и размер диска? Расскажите уж нам?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	102. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 23:11
	> как связан размер страйпа и размер диска? Расскажите уж нам? URL на производителя контроллера, который может сделать stripe на диски с разными объёмами, не потеряв при этом ни байта, покажите уж нам?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	118. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от ы on 01-Сен-10, 09:12
	>> как связан размер страйпа и размер диска? Расскажите уж нам? > >URL на производителя контроллера, который может сделать stripe на диски с разными >объёмами, не потеряв при этом ни байта, покажите уж нам? Опа на, и как это связано с: >где ему нужно приобрести пять одинаковых (для stripe это важно!) дисков, и какого они должны быть объёма. Путаетесь в показаниях товарищ Эндрю.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	127. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от Andrew Kolchoogin on 01-Сен-10, 10:13
	> Опа на, и как это связано с: >> где ему нужно приобрести пять одинаковых (для stripe это важно!) дисков, и какого они >> должны быть объёма. Напрямую. Вам это неочевидно?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	131. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от ы on 01-Сен-10, 10:29
	>Напрямую. Вам это неочевидно? Нет. Вы хотите сказать что я не могу сделать raid с дисками 146Гб и 250Гб?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	173. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от злодейко on 01-Сен-10, 20:34
	>> как связан размер страйпа и размер диска? Расскажите уж нам? > >URL на производителя контроллера, который может сделать stripe на диски с разными >объёмами, не потеряв при этом ни байта, покажите уж нам? откуда появилось "не потерять ни байта"??? для блочных raid-систем иногда можно пожертвовать 2/3 размера - если важно получить большое кол-во IOPS-ов с LUN-а - мелкие LUN рулят 8-)) и почему вы считаете что при размазывании данных по разным дискам это место потеряется? Оно может использоваться не оптимально например 8-)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	120. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от ы on 01-Сен-10, 09:21
	>Идея ясна? А вы -- stripe... ;) Умеет Ext4 (+всё, что угодно >там) такое? умеет, только это называется lvm.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	128. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–3 +/–
	Сообщение от Andrew Kolchoogin on 01-Сен-10, 10:15
	>> Идея ясна? А вы -- stripe... ;) Умеет Ext4 (+всё, что угодно >> там) такое? > умеет, только это называется lvm. Что умеет LVM? Сообщать файловой системе, в какой части тома теперь модно блоки аллоцировать? Вы эту дурь больше не курите. Это плохая дурь. :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	138. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от минона on 01-Сен-10, 11:33
	это уже не важно. оппонент почил в бозе. ну и zfs с ним.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	139. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от ы on 01-Сен-10, 11:36
	Ты бы хоть википедию прочел, хотя бы первые две строчки http://ru.wikipedia.org/wiki/LVM Прежде чем писать ахинею.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	186. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Аноним (??) on 02-Сен-10, 14:28
	>Вы себе представляете работу с дисковым массивом таким образом: системный администратор берёт >хрустальный шар, внимательно смотрит в него, и в его голове автоматически >появляются сведения, где ему нужно приобрести пять одинаковых (для stripe это >важно!) дисков, и какого они должны быть объёма. Нормальный администратор в общем то может прикинуть решение задачи, избавив всех остальных от баттхерта вида "внезапно кончилось место". Потому что как правило в энтерпрайзе закупка новых комплектующих, особенно серверных - занимает некое время. Достаточно чувствительное. Поэтому да, админы энтерпрайзов должны уметь forward thinking. >Не подскажете ли, у кого можно такой хрустальный шар на время одолжить?-) >У меня есть несколько вещей, которые мне срочно надо узнать. ;) Ну, если хрустального шара нет - тогда LVM есть :). В итоге изгалиться - можно. Вариантов комбинирования девайсов и слоев достаточно много. Под задачу всегда можно что-то придумать. Да, может быть будет менее удобно в администреже но - вполне работоспособно. >А на самом деле всё происходит совсем не так. У нас есть >дисковая полка (или сервер с местом под 8..16 HDD). Мы в >него вставляем 3 диска. Делаем RAIDZ. Оно у нас живёт. Кончается >дисковое место -- мы вставляем ещё 3 диска (возможно, другого объёма, >чем первые три -- диски-то совершенствуются!) А что помешает сделать примерно то же самое по смыслу средствами LVM например? EXT4 вообще деталей не узнает. Она только сможет отрасти на какимто образом увеличившийся девайс. Может это и менее удобно но вполне работоспособно. >Понятное дело, что некоторое первое время они практически не загружены > -- но ZFS постепенно "размазывает" данные>на наши шесть дисков. Я что-то пропустил и в zfs уже сделали возможным сдвигать часть данных существующих файлов на новые диски пула как в бтр? Или это имелось в виду что в процессе работы оно постепенно размажется? >Всё равно результат будет правильным. Да, особенно правильным он будет если захотеть диск из пула изъять :). В бтрфс такая ситуация кстати предусмотрена и эта фс может относительно просто и быстро убрать все данные с конкретного диска. А в zfs оно как, сделано уже? >Идея ясна? А вы -- stripe... ;) Умеет Ext4 (+всё, что угодно >там) такое? А почему бы и нет? Можно нагородить что-то похожее по смыслу скажем через LVM и все что ext4 увидит - девайс отрос и можно увеличить размер ФС, а как оно там внутрях было сделано - вообще не ее проблемы. Менее удобно и возможно менее оптимально, но ничего такого невозможного.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	119. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от ы on 01-Сен-10, 09:19
	>А вы не сливайтесь, не сливайтесь. :) Я не кусаюсь. :) > >Так что, может ваша хвалёная Ext4 распределять нагрузку по пяти дискам пула?-) >Или хотя бы сказать об этом соответствующему Layer'у?-) Офигеть! С фига ли файловая система по сути структура данных, должна что-то распределять. Этим напрямую занимается планировщик VFS. http://www.opennet.me/base/sys/linux_vfs.txt.html Хотя наверное это трудно понять "трушным солярщикам" когда операционка поддерживает более чем одну файловую систему.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	123. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–3 +/–
	Сообщение от Andrew Kolchoogin on 01-Сен-10, 09:59
	> С фига ли файловая система по сути структура данных, должна что-то распределять. Видите ли. Layer Separation имеет свои плюсы и свои минусы. Такой подход -- с фига ли файловая система должна понимать, на каком media она вообще живёт -- безусловно, имеет право на существование, хотя трушным линуксоидам, как правило, слабо себе представляющим, что внутри белого (или любого другого цвета) ящика, который они называют компьютер, есть масса различных компонентов. Но этот подход -- путь в тупик. :) Мы его один раз уже проходили с UFS: когда-то давно в BSD disklabel и в UFS superblock можно было написать особенности геометрии диска, и UFS старалась писать данные в такие сектора, чтобы минимизировать количество оборотов "тарелки" диска при чтении. Сейчас эти параметры считаются устаревшими, и современный код UFS в них не смотрит (да и особенности строения винчестеров таковы, что такой параметр, как количество секторов на дорожке, просто бессмыслен, т.к. оно везде разное) -- в результате получаем sub-optimal performance. При разработке ZFS эти грабли учли, и всё-таки решили оптимизировать распределение аллоцируемых блоков на уровне файловой системы. Видимо, на то были причины у инженеров Sun.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	132. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от ы on 01-Сен-10, 10:37
	>> С фига ли файловая система по сути структура данных, должна что-то распределять. > >Видите ли. Layer Separation имеет свои плюсы и свои минусы. >Такой подход -- с фига ли файловая система должна понимать, на каком >media она вообще живёт -- безусловно, имеет право на существование, хотя >трушным линуксоидам, как правило, слабо себе представляющим, что внутри белого (или >любого другого цвета) ящика, который они называют компьютер, есть масса различных >компонентов. То есть вы хотите сказать что ваш уровень знаний выше чем у трушных линуксойдов, и все линуксойды сплошь тупые и не знают потроха компьютера? >Но этот подход -- путь в тупик. :) Такой тупик что по скорости работы превосходит в десятки раз "нетупиковую" и не гибкую ZFS. >Мы его один раз >уже проходили с UFS: когда-то давно в BSD disklabel и в >UFS superblock можно было написать особенности геометрии диска, и UFS старалась >писать данные в такие сектора, чтобы минимизировать количество оборотов "тарелки" диска >при чтении. Имено так всегда отвечайте на вопросы, когда нечего сказать по существу, всегда не в тему, но с кучей умных слов, может быть у ваших опонентов случится переполнение буфера, и вы сойдете за умного. Когда говорят про линуксовый io планировщик VFS, всегда говорите про бздевый UFS, какая разница что он  вообще никак не связан с темой.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	187. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Аноним (??) on 02-Сен-10, 14:58
	>Видите ли. Layer Separation имеет свои плюсы и свои минусы. Поэтому то и есть ext4 и есть btrfs. >трушным линуксоидам, как правило, слабо себе представляющим, что внутри белого (или >любого другого цвета) ящика, который они называют компьютер, есть масса различных >компонентов. Левые набросы. Представлять себе для сбора LVMом желаемой конфиги придется, даже получше любителей zfs-а. Так что толсто - незачет. >Но этот подход -- путь в тупик. :) А это только время покажет. Кстати на уровне дизайна в бтрфс больше возможностей для управления томами. >Мы его один раз уже проходили с UFS: когда-то давно в BSD disklabel и в >UFS superblock можно было написать особенности геометрии диска, и UFS старалась >писать данные в такие сектора, чтобы минимизировать количество оборотов "тарелки" диска >при чтении. Левый бред. EXT4 при юзеже LVM вообще не знает из чего оно там собрано. Все что она видит - некий том. Который может увеличиваться по желанию админа, например. А сколько там девайсов составляют том и как они скомпонованы ФС вообще не знает. Так что вы привели строго инверсный пример. Вы сами себя и оспариваете чтоли? :) >Сейчас эти параметры считаются устаревшими, и современный код UFS в них не >смотрит А код ext4 не смотрит в то как слеплен девайс LVM. Более того - точную геометрию диска или флешдиска ни одна ФС как вы уже заметили узнать не может. Поэтому performance всегда будет ниже идеала. Просто потому что в большей части случаев ФС не будет владеть информацией достаточной для удачного (для диска) раскладывания структур на дорожки диска (блоки флеша, ...) и будет некоторая неоптимальность. То есть, задача размещения тех же данных скорее всего решаема лучше, но ФС неоткуда про это узнать. Т.к. соответствующей информацией оперирует только контроллер (флеш)диска. >При разработке ZFS эти грабли учли, и всё-таки решили оптимизировать распределение >аллоцируемых блоков на уровне файловой системы. Видимо, на то были причины у >инженеров Sun. Конечно были. У них то не было LVM и они впихали соотв. слой в ФС. Кстати в бтр учли опыт инженеров Sun. И их промахи тоже учли. Сделав так что убирать данные с тома - просто и быстро. Поюзав экстенты, и так далее. Бтр позднее проектировался и потому опыт предшественников в нем учли. Да, прямо сейчас у zfs больше фич, но это вопрос времени. Тем более что оракл вызвал разброд и шатания команд разработчиков своими действиями.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	188. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Anon Y Mous on 02-Сен-10, 15:15
	> Кстати на уровне дизайна в бтрфс больше возможностей для управления томами. Например?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	181. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от Школьник (ok) on 01-Сен-10, 22:41
	>Офигеть! С фига ли файловая система по сути структура данных, должна что-то >распределять. Этим напрямую занимается планировщик VFS. "Планировщик VFS"?! Вот это да! Новое слово в искусстве программирования ядер ОС. >http://www.opennet.me/base/sys/linux_vfs.txt.html Кстати, по этой ссылке нет ни одного слова "планировщик". И гугл проклятый молчит. Может, подскажете, где бы про это почитать поподробнее? >Хотя наверное это трудно понять "трушным солярщикам" когда операционка поддерживает более чем >одну файловую систему. Предчувствую, года через два со стороны линуксоидов в дискуссиях будут такие кадры участвовать, что будем с тоской вспоминать о том, как хорошо было беседовать с User294.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	59. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от xxx (??) on 31-Авг-10, 17:34
	>В своё время в -CURRENT FreeBSD v5 была такая IFS -- iNode File System. Что-то не припоминаю такого. И гугл молчит, wtf?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	62. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 17:43
	Вы не припоминаете -- CVS припомнит. :))) Вот, полюбуйтесь: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/ufs/ifs/?hidea... А Google -- а что Google... В 2001'м-то году... ;)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	117. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от ы on 01-Сен-10, 09:02
	>> ну типа тестов больше чем пять > >В остальных тестах ZFS/Solaris не участвовала (или Phoronix не привёл данные). или просто таких тестов под солярку нет. >> и есть еще ext4 про которую вы умалчиваете. > >Сравнение ZFS (BtrFS) с Ext4 -- это сравнение самолёта с автомобилем. Ext4 >_ничего_ не умеет. Давай-давай мори дальше. >В своё время в -CURRENT FreeBSD v5 была такая IFS -- iNode >File System. Так она по производительности вообще всех рвала в тряпки. >;) Можете поковыряться и посмотреть, что это было. ;) Вот только ext4 в продакшене, даже гугл на неё перешел.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	124. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Andrew Kolchoogin on 01-Сен-10, 10:01
	>>> ну типа тестов больше чем пять >> В остальных тестах ZFS/Solaris не участвовала (или Phoronix не привёл данные). > или просто таких тестов под солярку нет. Угу. А под Линукс есть (ZFS/FUSE данные есть все). Конечно-конечно. И gcc в Солярке нет. И /bin/sh. Один CDE сплошной... >>> и есть еще ext4 про которую вы умалчиваете. >> Сравнение ZFS (BtrFS) с Ext4 -- это сравнение самолёта с автомобилем. Ext4 >> _ничего_ не умеет. > Давай-давай мори дальше. Давать тебе жена будет. Если будет, конечно. >> В своё время в -CURRENT FreeBSD v5 была такая IFS -- iNode >> File System. Так она по производительности вообще всех рвала в тряпки. >> ;) Можете поковыряться и посмотреть, что это было. ;) > Вот только ext4 в продакшене, даже гугл на неё перешел. "... даже гугл..." Вот, право, критерий. :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	133. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от ы on 01-Сен-10, 10:42
	>>>> ну типа тестов больше чем пять >>> В остальных тестах ZFS/Solaris не участвовала (или Phoronix не привёл данные). >> или просто таких тестов под солярку нет. > >Угу. А под Линукс есть (ZFS/FUSE данные есть все). > >Конечно-конечно. И gcc в Солярке нет. И /bin/sh. Один CDE сплошной... У фороникса спроси, чего не сделали. >> Давай-давай мори дальше. > >Давать тебе жена будет. Если будет, конечно. Да неволнуйся ты так право, женат двое детей. Ну а если по теме, что не умеет ext4 по сравнению с zfs? >>> В своё время в -CURRENT FreeBSD v5 была такая IFS -- iNode >>> File System. Так она по производительности вообще всех рвала в тряпки. >>> ;) Можете поковыряться и посмотреть, что это было. ;) >> Вот только ext4 в продакшене, даже гугл на неё перешел. > >"... даже гугл..." Вот, право, критерий. :) То есть по твоему over 10 000 000 серверов не критерий, по сравнению с чем-то затерянным в cvs образца 2001 года?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	143. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+1 +/–
	Сообщение от минона on 01-Сен-10, 12:47
	>> Вот только ext4 в продакшене, даже гугл на неё перешел. >"... даже гугл..." Вот, право, критерий. :) ну конечно, авторитет Кольчугина с дохлой ОС - это куда круче! :D ps: >Давать тебе жена будет. Если будет, конечно. вот и основной аргумент - хамство - единственный критерий выбора.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	56. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+1 +/–
	Сообщение от Аноним (??) on 31-Авг-10, 17:21
	>И вот откуда вы взяли своё утверждение? Ну вот откуда? Монитор барахлит? А можно я вместо того перца отвечу? Открываем http://www.phoronix.com/scan.php?page=article&item=zfs_fuse_... ну и далее. А там... 0) ZFS-FUSE слил обоим EXT4 и BTRFS в 2 раза на бенче статики опача. Результаты для соляры фороникс почему-то не показал на графике, к сожалению. 1) EXT4 всех порвал на постгресовском TPC-B, в какие-то жалкие 4 раза "всего" :). Btrfs там впрочем тоже не блеснул, но у линуксоидов то есть из чего выбрать. А у остальных систем с zfs выбор разве что из ископаемых UFSов. Наверное дело в том что постгр сам что-то типа версионника и ФС в духе версионника под ним - скорее медвежья услуга чем помощь. 2) В PostMark EXT4 уделал ZFS даже на соляре всего-то в почти 5 раз. Нормально так. Btrfs впрочем тоже сделал ZFSа. Правда "всего" почти в 4 раза. Ну да, он проиграл... ext4-ому. 2.1) В тесте SQLite EXT4 уделал FUSE вариант раза в два, хоть это и малоинформативно за отсутствием результатов для скажем соляры на графике. 3) В unpacking linux kernel все идут нос к носу кроме Fuse варианта ZFS который тормоз. ZFS чуть быстрее EXT4 и нос к носу с BTRFS. Epic win-а как-то не видно. Epic fail FUSE предсказуем. 4) В compile bench EXT4 натянул на 50% btrfs и zfs, которые показали близкие результаты. FUSE вообще где-то в ... ;) 5) В threaded io test ZFS оказался в нереальной опе. Что с fuse, что в родной солярке вообще. BTRFS сделал его в 25 раз :D. EXT4 поскромнее чуток, раз в 15 "всего" :). 6) Собссно небольшой win ZFS виден только в тестах iozone (да, с учетом fuse это достойный упоминания результат, к сожалению для соляры опять не привели цифры) Игого: EXT4 основательно уделывает ZFS под большей частью нагрузок. Btrfs тоже не дурак надрать задницу ZFSу при удобном случае несмотря на сырость. А вот ZFS задницу никому не надирает особо, особенно так чтобы с отрывом в разы. CPU? А что CPU? CPU usage всего что не fuse - не превысил 35% судя по графику. Выводы: для сегодня EXT4, для завтра btrfs. Fuse можно пользоваться только если позарез приперло прочитать чужой том на не-нативной для него операционке.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	67. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 17:54
	> Выводы: для сегодня EXT4, для завтра btrfs Для тех, для кого ничего, кроме Линукса, не существует. Совершенно верно. А кому надо, чтобы работало, используют человеческие решения.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	75. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от ы on 31-Авг-10, 18:41
	>Для тех, для кого ничего, кроме Линукса, не существует. Совершенно верно. нука, нука! и для кого? для бздишнеков? для солярщиков? для маководов? для кого?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	90. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от iZEN (ok) on 31-Авг-10, 20:38
	>но у линуксоидов то есть из чего выбрать. А у остальных систем с zfs >выбор разве что из ископаемых UFSов. Но у линуксоедов Ext4 и тем более Btrfs до сих пор нельзя использовать в продакшене. И выбор ограничен, по-сути, только лишь "ископаемой" Ext3 (которая стала стабильной в 2002-2003гг). Вывод: Ext4 ещё пилить и пилить; Btrfs ещё сыра как тряпка и не умеет RAID-5; ZFS упирается в многопоточные механизмы ядра и требовательная к памяти; остаётся UFS2 с GEOM (для FreeBSD), которая всех заруливает по адекватности большинства решаемых задач (снапшоты, ACL, RAID-0,-1,-3,-5 модулями GEOM, почти не фрагментируется, не нуждается в журналировании благодаря Soft Updates).
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	91. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 20:48
	:) UFS2/GEOM уже научилась делать shadowed hierarchy? А delegated administering? А cross-data checksumming? А on-the-fly compression? Ну хоть "RAID для бедных" -- аналог "copies=n" -- умеет? Что, так и нет?-) Жа-а-а-а-а-а-а-аль... ;) Так и придётся любителям UFS2/GEOM вечно писать /etc/fstab... ;)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	96. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от iZEN (ok) on 31-Авг-10, 21:42
	>:) > >UFS2/GEOM уже научилась делать shadowed hierarchy? Кэширование каталогов давно работает или WTF, если не так понял. >А delegated administering? WTF >А cross-data checksumming? WTF >А on-the-fly compression? WTF >Ну хоть "RAID для бедных" -- аналог "copies=n" -- умеет? WTF
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	104. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 23:21
	Ну, тогда начнём с изучения научной литературы: http://users.soe.ucsc.edu/~sbrandt/221/zfs_overview.pdf Там про контрольные суммы и про компрессию. И ещё много про что. Про DA: http://lmgtfy.com/?q=zfs+delegated+administration
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	107. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от iZEN (ok) on 01-Сен-10, 00:46
	>Ну, тогда начнём с изучения научной литературы: > >http://users.soe.ucsc.edu/~sbrandt/221/zfs_overview.pdf > >Там про контрольные суммы и про компрессию. И ещё много про что. Я в курсе про сквозную целостность (с заданной степенью расчёта хэша или без) и компрессию на лету (про уровни и алгоритмы тоже в курсе). >Про DA: > >http://lmgtfy.com/?q=zfs+delegated+administration На NT-системах это делается мышкой на странице Permissions свойств каталога или её продвинутую страничку со списками (выбрать пользователей, группы — лучше, расставить галочки, нажать кнопку Применить). На ZFS нужно вводить в командной строке определённую строчку. Для UFS2 можно задействовать расширенные атрибуты файлов/каталогов. Ну, и?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	109. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Anon Y Mous on 01-Сен-10, 03:35
	>>Про DA: >> >>http://lmgtfy.com/?q=zfs+delegated+administration > >На NT-системах это делается мышкой на странице Permissions свойств каталога или её >продвинутую страничку со списками (выбрать пользователей, группы — лучше, расставить галочки, >нажать кнопку Применить). На ZFS нужно вводить в командной строке определённую >строчку. Для UFS2 можно задействовать расширенные атрибуты файлов/каталогов. Ну, и? есть мнение, что ты думаешь о чем-то своем, но не о Delegated Administration
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	112. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от iZEN (ok) on 01-Сен-10, 08:10
	>есть мнение, что ты думаешь о чем-то своем, но не о Delegated Administration Есть ещё PAM. Не то?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	125. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от Andrew Kolchoogin on 01-Сен-10, 10:09
	>> есть мнение, что ты думаешь о чем-то своем, но не о Delegated Administration > Есть ещё PAM. Не то? Нет, не то. Очень вкратце, в применимости к FreeBSD: ну например, можно создать jail на некоторой подыерархии ZFS, сказать на эту подыерархию "zfs jail <subhierarchy>", после чего в jail'е можно будет создавать файловые системы-листья этой подыерархии. Суперюзеру, конечно. :) А тако ж ставить квоты, атрибуты "exec/noexec", "setuid/nosetuid", и так далее. Но в Jail'е. С Солярными зонами ситуация аналогичная, только там "zfs zone". Вот это и есть delegated administration.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	146. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от iZEN (ok) on 01-Сен-10, 13:51
	>Но в Jail'е. С Солярными зонами ситуация аналогичная, только там "zfs zone". > > >Вот это и есть delegated administration. До ZFS обходились ФС на виртуальном блочном устройстве (см mdconfig). Просто и дёшево. P.S. UFS я всё-таки сравниваю с традиционными ФС, что сейчас на продакшене в Linux. Вывод делаю неутишительный: в Linux до сих пор нет классических надёжных ФС с необходимыми фичами (снапшоты) и способных противостоять разрушению без обращения к отдельным костылям (LVM, журнал транзакций).
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	157. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от минона on 01-Сен-10, 15:09
	никому уже не интересен ВАШ вывод. вот в чём вопрос.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	121. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от ы on 01-Сен-10, 09:22
	>Но у линуксоедов Ext4 и тем более Btrfs до сих пор нельзя >использовать в продакшене. И выбор ограничен, по-сути, только лишь "ископаемой" Ext3 >(которая стала стабильной в 2002-2003гг). сказал бздишник.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	144. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от минона on 01-Сен-10, 12:55
	ему не отвечают только по одной причине - надоел. уже раз 20 тыкали носом в ограничения софтапдэйта (теже фичи с обнулением файлов, что и в rc ext4) - без толку. просто тролль, прикрывающийся бздишностью. и местами java'ой (бздишнег?!!! угу)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	147. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от iZEN (ok) on 01-Сен-10, 14:01
	>ему не отвечают только по одной причине - надоел. >уже раз 20 тыкали носом в ограничения софтапдэйта (теже фичи с обнулением >файлов, что и в rc ext4) - без толку. Механизм Soft Updates гарантирует правильную последовательность записи в файл, которуую делает программное обеспечение. Из-за сбоя в работе ФС открытые файлы физически не могут обнулится (как это нередко происходит на XFS и Ext4). В аварийных случаях содержимое открытых файлов останется в том виде, в каком оно было по времени максимум до 30 секунд до сбоя.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	152. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от минона on 01-Сен-10, 14:40
	http://web.opennet.ru/base/sys/softupdates_idea.txt.html вывод:   журналирования данных нет как класса. никаких writeback, ordered или journal (полное журналирование как метаданных ФС, так и пользовательских данных). и даже с восстановлением метаданных согласно ссылке бывают большие траблы. доп. вывод:   izen - банальный троль.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	153. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от минона on 01-Сен-10, 14:48
	дополнение (пусть попробует прокоментировать свои "30 секунд"): >Таким образом, softupdates зависит от двух условий. >Во-первых, блоки должны записываться на диск в той последовательности, как ОС передает их контроллеру.  Hо современные контроллеры и диски могут сами переупорядочивать запись блоков для оптимизации перемещения головок и т.п. (хотя tagged queuing позволяет ОС это отслеживать). >Во-вторых, предполагается, что сбой не может прервать посередине операцию записи блока на диск.  Умеют ли диски завершать текущую запись блока при сбое питания, я не знаю (хотя приятно было бы на это надеяться :-)Если эти условия выполняются, то softupdates помогает ровно в одном: не будет дефектов в файловой структуре -- ее можно монтировать даже без fsck. и вот это: >Hо само ее состояние может соответствовать любому моменту времени в прошлом. вот поэтому народ и думает - "а нужно ли спорить с этим латентным (а может и не латентным) проприетарщиком? ему ведь все средства, любая ложь - хороши."
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	163. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от iZEN (ok) on 01-Сен-10, 15:55
	>Если эти условия выполняются, то softupdates помогает ровно в одном: >не будет дефектов в файловой структуре -- ее можно монтировать даже >без fsck. Именно к этому я тебя подводил. ;) >и вот это: >>Hо само ее состояние может соответствовать любому моменту времени в прошлом. > >вот поэтому народ и думает - "а нужно ли спорить с этим >латентным (а может и не латентным) проприетарщиком? ему ведь все средства, >любая ложь - хороши." Не изворачивайся как угорь в банке.  :) Не констатируй того, чего я не говорил. Никакие ФС, кроме поддерживающие технику CoW и/или полное журналирование, не могут обеспечить сохранность данных. Классические ФС при нормальной работе заботятся лишь о целостности СВОЕЙ_СТРУКТУРЫ. Давай ты не будешь додумывать мои слова.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	168. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+2 +/–
	Сообщение от минона on 01-Сен-10, 16:52
	>Именно к этому я тебя подводил. ;) Э нет, батенька. :D Вывод в статье один - надо поставить блок бесперебойного питания. >Не изворачивайся как угорь в банке.  :) Не констатируй того, чего я не говорил. не изворачивайся как рак в кастрюле. твои выкрики про плачевное состояние фс в линухе сводятся к - экст3 позволяет полное журналирование, а софтапдэйт - нет. вообще. и где твои 30 секунд? там же, http://web.opennet.ru/base/sys/softupdates_idea.txt.html >Hо само ее состояние может соответствовать любому моменту времени в прошлом. опять врёшь? :D
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	176. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от iZEN (ok) on 01-Сен-10, 21:38
	>[оверквотинг удален] > >Э нет, батенька. :D >Вывод в статье один - надо поставить блок бесперебойного питания. >>Не изворачивайся как угорь в банке.  :) Не констатируй того, чего я не говорил. > >не изворачивайся как рак в кастрюле. >твои выкрики про плачевное состояние фс в линухе сводятся к - экст3 >позволяет полное журналирование, а софтапдэйт - нет. вообще. >и где твои 30 секунд? там же, http://web.opennet.ru/base/sys/softupdates_idea.txt.html >>Hо само ее состояние может соответствовать любому моменту времени в прошлом. "Kirk McKusick, разработчик Berkeley FFS, решил эту проблему с помощью Soft Updates: все незавершенные обновления метаданных находятся в памяти и записываются на диск в упорядоченном виде (''упорядоченное обновления метаданных''). При значительных обновлениях метаданных более поздние обновления ''присоединяются'' к предыдущим, если они все еще находятся в памяти и еще не записаны на диск. Поэтому все операции, скажем, над каталогом, обычно выполняются в памяти перед записью обновления на диск (блоки данных сортируются в соответствии с их положением, так что они не будут записаны на диск до метаданных. При крахе операционной системы выполняется ''откат'': считается, что все операции, не записанные на диск, никогда не происходили. Файловая система находится в том состоянии, в котором она была за 30-60 секунд до сбоя. Используемый алгоритм гарантирует, что все используемые ресурсы маркированы соответствующим образом в своих областях: блоки и индексные дескрипторы. После сбоя могут остаться только ошибки выделения ресурсов, они помечаются как ''используемые'', хотя на самом деле ''свободны''. fsck(8) разбирается в ситуации и освобождает более не используемые ресурсы. После сбоя система может быть безопасно смонтирована с опцией mount -f. Для освобождения ресурсов, которые могут не использоваться, в дальнейшем потребуется запустить fsck(8). Эта идея лежит в основе background (фоновая) fsck: во время запуска системы записывается только снимок файловой системы. Все системы могут быть смонтированы в ''грязном'' состоянии, и система загружается в многопользовательский режим. Затем, фоновые fsck ставятся в очередь для всех систем, где это требуется, чтобы освободить неиспользуемые ресурсы. (Файловые системы, где не используются Soft Updates, все еще требуют запуска fsck в обычном режиме)." >опять врёшь? :D Угу: http://www.freebsd.org/doc/ru/books/handbook/configtuning-di...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	179. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от аноним on 01-Сен-10, 22:30
	а! уже 30-60! :D но ладно, ведь именно это в ссылке и разбиралось. а от вас - 0 комментариев. вывод плачевен - софтапдэйт позволяет при определенной доли везения уменьшить скорость загрузки за счет fsck после сбоя. состояние данных и метаданных не гарантированно. и это единственное, что он может. других возможностей нет. печально.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	162. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+1 +/–
	Сообщение от iZEN (ok) on 01-Сен-10, 15:52
	>http://web.opennet.ru/base/sys/softupdates_idea.txt.html >вывод: >  журналирования данных нет как класса. Я о целостности данных не говорил. Я сказал, что файл после сбоя может быть в том виде, в котором его открыли за 30 секунд до сбоя. ВСЁ. Журналирование данных весьма затратная операция. Если его включить на Ext3, то можно сушить вёсла — больше 6...10МБ/с скорость записи не получишь.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	169. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+1 +/–
	Сообщение от минона on 01-Сен-10, 16:58
	а я - говорил. собственно само понятие продуктивной системы об этом говорит. т.к. плачевное состояние для продакшен системы - это не возможность гарантирования не только мета-данных (а согласно всё той же статье http://web.opennet.ru/base/sys/softupdates_idea.txt.html софтапдэт не гарантирует даже этого), но и (при желании) включения полного журналирования. нет этого в софтапдэйте. в первом случаи - ни каких гарантий (только если повезёт), во втором - просто нет. экст же предоставляет такой выбор. вот так то, латентный проприетарный пионер.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	177. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от iZEN (ok) on 01-Сен-10, 21:47
	>а я - говорил. собственно само понятие продуктивной системы об этом говорит. > >т.к. плачевное состояние для продакшен системы - это не возможность гарантирования не только мета-данных (а согласно всё той же статье http://web.opennet.ru/base/sys/softupdates_idea.txt.html софтапдэт не >гарантирует даже этого), но и (при желании) включения полного журналирования. > >нет этого в софтапдэйте. в первом случаи - ни каких гарантий (только >если повезёт), во втором - просто нет. Не надо читать околонаучных рассуждений на ОпенНете. S-U гарантирует целостность ФС, независимо от того, о чём думает автор плохого пересказа. Читать до просветления здесь: http://www.freebsd.org/doc/ru/books/handbook/configtuning-di... раз уж первоисточник на английском не понятен. Гарантия целостности метаданных — это и есть гарантия целостности самой структуры ФС. Данные пользователя, если уцелели, считай повезло, нет — никто их специально не обнуляет, как в XFS и Ext4 при внезапном пропадании электричества. Повреждённый/недописанный вледствие внезапного останова — это всё-таки файл, а не набор нулей в XFS и Ext4. >экст же предоставляет такой выбор. Да, предоставляет. Но какой ценой... >вот так то, латентный проприетарный пионер. Не надо хамить.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	180. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от аноним on 01-Сен-10, 22:41
	>Не надо читать околонаучных рассуждений на ОпенНете. S-U гарантирует целостность ФС, независимо от того, о чём думает автор плохого пересказа. уговорил. :D ты и до этого мало походил на ... очень упрямое и глупое животное. >Повреждённый/недописанный вледствие внезапного останова — это всё-таки файл, а не набор нулей в XFS и Ext4. баг был потому, что в определенный момент сама прога его обнуляла, а не фс. нда, слышишь звон, но... эх, izen, двоечник красноглазый. не нервничай так. раз ты сам сравниваешь софтапдейт с бетой ext4, то так тому и быть, пусть будут одного уровня. :D
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	172. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+1 +/–
	Сообщение от ы on 01-Сен-10, 19:51
	за 30 секунд для нагруженной бд придет абзац, что может даже repair не поможет, в чем тогда плюсы?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+7 +/–
Сообщение от delirium (ok) on 31-Авг-10, 11:40
> В большинстве тестов ZFS-FUSE сильно отстает от EXT4, Btrfs и оригинальной реализации ZFS, что вызвано замедлением из-за использования механизма FUSE. Тесты проводил кэп?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

3. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+6 +/–
Сообщение от luckym (ok) on 31-Авг-10, 11:49
Из тестов можно сделать один важный вывод - EXT4 рулит и педалит, и никакие Btrfs пока ему не замена.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	4. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 11:57
	Из этого можно сделать другой важный вывод: при наличии команды грамотных инженеров и возможности в течение десяти лет вести разработку файловой системы, не оглядываясь ни на кого, можно создать файловую систему, которая будет работать по скорости так же, как всеми давно используемые, но при этом иметь в сравнении с этими "давно используемыми" список фич, который не умещается на три экрана монитора. :) Мне безумно жаль Sun Microsystems: где ещё взять такую компанию, которая бы спонсировала проводимые внутри неё разработки, если они просто _представляют академический интерес_?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	16. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+1 +/–
	Сообщение от аноним on 31-Авг-10, 13:31
	>можно создать файловую систему, которая будет работать по скорости гораздо медленнее, чем всеми давно используемые //fix, очевидный после изучения результатов тестов по ссылке
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	26. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 14:40
	>> можно создать файловую систему, которая будет работать по скорости гораздо медленнее, >> чем всеми давно используемые > //fix, очевидный после изучения результатов тестов по ссылке О, да. Анонимус, как всегда, блещет способностью к изучению тестов. И даже не ленится дочитать отчёт до конца, в котором написаны предполагаемые причины.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	18. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от pavlinux (ok) on 31-Авг-10, 14:02
	>Мне безумно жаль Sun Microsystems: где ещё взять такую компанию, которая бы >спонсировала проводимые внутри неё разработки, если они просто _представляют академический интерес_? Berkley, MIT, NASA, CERT
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	28. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 14:49
	>> Мне безумно жаль Sun Microsystems: где ещё взять такую компанию, которая бы >> спонсировала проводимые внутри неё разработки, если они просто _представляют >> академический интерес_? > Berkley, MIT, NASA, CERT 1, 2 -- учебные заведения, 3 -- сами понимаете, там не всё можно открывать :), 4 -- научная организация. А коммерческие компании? А?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	30. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от pavlinux (ok) on 31-Авг-10, 15:04
	>>> Мне безумно жаль Sun Microsystems: где ещё взять такую компанию, которая бы >>> спонсировала проводимые внутри неё разработки, если они просто _представляют >>> академический интерес_? >> Berkley, MIT, NASA, CERT > >1, 2 -- учебные заведения, 3 -- сами понимаете, там не всё >можно открывать :), 4 -- научная организация. > >А коммерческие компании? А? Чисто академических по-моему и у Санок не было, все шло в продакшын. Ну а так, NVidia - Cuda + OpenCL - очень даже академический софт. У Интеля много фриварного софта, RedHat, VMware, IBM ..... в общем, без санок не умрём :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	32. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 15:08
	> Чисто академических по-моему и у Санок не было, все шло в продакшын. Project Looking Glass?-) > Ну а так, NVidia - Cuda + OpenCL - очень даже академический софт. Был бы ещё свободным -- цены бы ему не было. А так -- здесь согласен. BOINC вполне нормально CUDA'ой пользуется, сам проверял. > в общем, без санок не умрём :) Но затормозимся в прогрессе. ;)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	31. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Аноним (??) on 31-Авг-10, 15:05
	>>> Мне безумно жаль Sun Microsystems: где ещё взять такую компанию, которая бы >>> спонсировала проводимые внутри неё разработки, если они просто _представляют >>> академический интерес_? >> Berkley, MIT, NASA, CERT > >1, 2 -- учебные заведения, 3 -- сами понимаете, там не всё >можно открывать :), 4 -- научная организация. > >А коммерческие компании? А? intel, ibm
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	33. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Crazy Alex (??) on 31-Авг-10, 15:12
	Ну вообще логично, что исследованиями, представляющими чисто академический интеес, занимаются научные учреждения и университеты. И, опять же, со всем уважение к SUN - её политика в целом оказалась неудачной. О причинах, конечно, разговор отдельный.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	36. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 15:16
	> Ну вообще логично, что исследованиями, представляющими чисто академический интеес, > занимаются научные учреждения и университеты. И да, и нет. В СССР конструкторские бюро не только при проектных НИИ были, но и при производствах. Каждое из них занимало свою нишу. Что-то удобнее делать рядом с академиками, что-то -- рядом со станками. _Без_ гарантии, что оно в дальнейшем пойдёт в серию. > И, опять же, со всем уважение к SUN - её политика в целом оказалась неудачной. > О причинах, конечно, разговор отдельный. Экспериментальный факт показывает, что таки да. Однако, кто ещё из крупных вендоров открыл целиком проприетарную операционную систему в Open Source? Навскидку как-то никто не припоминается...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	44. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+2 +/–
	Сообщение от ы on 31-Авг-10, 15:52
	>Мне безумно жаль Sun Microsystems: где ещё взять такую компанию, которая бы >спонсировала проводимые внутри неё разработки, если они просто _представляют академический интерес_? Да собственно любая крупная компания. Даже майкрософт.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

6. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+8 +/–
Сообщение от аноним on 31-Авг-10, 12:26
Занятно. Если zfs на солярке работает примерно также быстро, как btrfs в linux, а zfs на freebsd - гораздо медленнее, получается, вся проблема либо в ядре фряхи, либо в кривом портировании. А насчет скорости нативной реализации для linux я бы не стал раньше времени радоваться. Может, как с freebsd выйдет.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	7. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 12:34
	> Занятно. Если zfs на солярке работает примерно также быстро, как btrfs в > linux, а zfs на freebsd - гораздо медленнее, получается, вся проблема > либо в ядре фряхи, либо в кривом портировании. ZFS на FreeBSD работает с той же скоростью, что и ZFS в Солярисе. Проблема вот в чём: ядро Соляриса -- полностью динамически масштабируемое. Ядро FreeBSD -- нет. Многие параметры ядра, связанные с распределением памяти -- не sysctls, а boot-time tunables. Их можно менять, только перезагрузив ядро. По умолчанию в ядре FreeBSD параметры для ZFS выставлены крайне неоптимально. Впрочем, в ядре Соляриса тоже. Но если со вторым ZFS в Солярисе справляется "щелчком пальцами", то с FreeBSD ситуация заметно сложнее. :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	11. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от iCat (ok) on 31-Авг-10, 13:00
	>По умолчанию в ядре FreeBSD параметры для ZFS выставлены крайне неоптимально Прошу комментариев с примерами или ссылки на материалы, где в доступной форме можно почерпнуть...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	12. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+2 +/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 13:02
	Э-э-э-э-э... http://wiki.freebsd.org/ZFSTuningGuide -- сюда ходили?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	13. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+4 +/–
	Сообщение от аноним on 31-Авг-10, 13:06
	>По умолчанию в ядре FreeBSD параметры для ZFS выставлены крайне неоптимально. Вынужден вас разочаровать: те тесты проводились на pc-bsd. Это ядро freebsd + настроенная zfs из коробки. Так что, боюсь, никакие изменения параметров уже не спасут.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	19. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+1 +/–
	Сообщение от тигар (ok) on 31-Авг-10, 14:07
	у pcbsd несколько отличающаяся от нормальной fbsd ниша. я считаю что глупо делать какие-то замеры на десктоп-ориентированном дистрибутиве. и это.. хочется узнать что означает "настроенная zfs из коробки"
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	25. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 14:38
	> Вынужден вас разочаровать: те тесты проводились на pc-bsd. Это ядро freebsd + > настроенная zfs из коробки. Это иллюзии. "Настроенная ZFS из коробки" будет работать на 512 мегабайтах без вопросов (сам настраивал). Кстати говоря, для OpenSolaris требования такие же. А PC-BSD отказывается её ставить меньше, чем на гектар ОЗУ. Если уж они такие "настройщики", то почему так происходит? От неумения настраивать?-)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	29. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Аноним (??) on 31-Авг-10, 15:03
	>Это иллюзии. "Настроенная ZFS из коробки" будет работать на 512 мегабайтах без >вопросов (сам настраивал). а зачем, кстати? такое ограничение по памяти я могу себе в продуктиве только на виртуалке представить, но в виртуалке zfs так ли нужна? а если для дома для семьи - ну только из-за спортивного интереса. btw сильно прикалывает тестовое железо фороникса - лаптоп с одним сата.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	34. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+1 +/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 15:12
	>> Это иллюзии. "Настроенная ZFS из коробки" будет работать на 512 мегабайтах без >> вопросов (сам настраивал). > а зачем, кстати? Ну как это "зачем"? Прежде всего, для того, чтобы закрепить понимание, как правильно настраивается ядро в memory-constrained cases. Суть не в том, чтобы запихнуть 8.1/ZFS в 64 мегабайта ОЗУ. Суть в том, чтобы понять, какую гайку дёргать, если в ядре закончилась какая-нибудь память (или виртуальное адресное пространство).
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	47. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+1 +/–
	Сообщение от Аноним (??) on 31-Авг-10, 16:37
	>те тесты проводились на pc-bsd. Это ядро freebsd + настроенная zfs из коробки. PCBSD "из коробки" настроена на десктоп. А не на "разогнать ZFS до потолка".
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	20. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Аноним (??) on 31-Авг-10, 14:09
	Откуда дровишки про умолчальные параметры и легкость устранения проблемы? :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	24. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 14:35
	> Откуда дровишки про умолчальные параметры и легкость устранения проблемы? В смысле "откуда"? Лёгкость устранения проблем с настройками параметров ядра в Солярисе очевидна -- ZFS их настраивает автоматически. :))) Правда, тоже не всегда: в частности, в случае Solaris Xen Domain0 всё-таки приходится пинать /etc/system, но это, если угодно, Corner Case. А что до FreeBSD -- так это вы почитайте архивы mailing list'ов времён FreeBSD v7.0-v7.2. Там много "войн" с ядром BSD на предметы, начиная от sub-optimal performance и заканчивая spontaneous crashes. Мне кто-то из Core так и ответил: "Для ZFS параметры настраиваются методом подбора до устранения спонтанных крэшей". Дёшево и сердито. :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	35. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от Crazy Alex (??) on 31-Авг-10, 15:14
	Мда, вот после этого лично я точно не стану ZFS  на BSD использовать...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	38. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+1 +/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 15:19
	> Мда, вот после этого лично я точно не стану ZFS на BSD использовать... Ну и напрасно. После где-то недельного траха параметры подбираются достаточно точно: у меня с мая прошлого года ни одного краха по причине ZFS у FreeBSD не было. Зато бонусов достаточно, чтобы эту неделю потратить. Например: как вы на UFS сделаете так, чтобы можно было откатить апгрейд системы?-) Restoring from backup tapes doesn't count: это долго. А так, чтобы за время одной перезагрузки?-)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	60. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от QuAzI (??) on 31-Авг-10, 17:35
	Чо? С 8-го релиза оно изредка паникует на i386 при сильной нехватке ОЗУ. А если её вполне себе хватает, свалить её очень и очень трудно. Я честно пытался и не получилось. NTFS-3G в разы проще грохнуть под нагрузкой.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	66. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 17:53
	> Чо? С 8-го релиза оно изредка паникует на i386 при сильной нехватке > ОЗУ. А если её вполне себе хватает, свалить её очень и > очень трудно. Я честно пытался и не получилось. NTFS-3G в разы > проще грохнуть под нагрузкой. Hint: задерите сетевые буфера. ZFS'у быстро памяти хватать перестанет. ;)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	108. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Аноним (??) on 01-Сен-10, 03:28
	8.0 amd64, до сих пор у меня падает машина если в VirtualBox начинаю очень интенсивно работать с динамическим диском (VDI) расположенном на ZFS пуле, добиться более-менее стабильной работы, что бы не падало каждые полчаса, удалось, но что бы не падало совсем - увы и ах.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	113. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от iZEN (ok) on 01-Сен-10, 08:15
	>8.0 amd64, до сих пор у меня падает машина если в VirtualBox >начинаю очень интенсивно работать с динамическим диском (VDI) расположенном на ZFS >пуле, добиться более-менее стабильной работы, что бы не падало каждые полчаса, >удалось, но что бы не падало совсем - увы и ах. Обновиться до 8.1 не пробовали? Говорят, помогает.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	140. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Аноним (??) on 01-Сен-10, 11:38
	>Обновиться до 8.1 не пробовали? Говорят, помогает. В планах, но руки пока не дошли.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

21. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
Сообщение от pavlinux (ok) on 31-Авг-10, 14:10
Единственный тест в который я поверю это IOzone: 8GB write test with a 64Kb block size Который показывает двукратное торможения при записи, которое только зависит от FUSE. Думается, что NTFS3G тоже самое показал бы.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

23. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
Сообщение от Аноним (??) on 31-Авг-10, 14:15
Посмотрел все диаграммы тестов и они меня очень удивли. Однако вспомнил, как у меня тормозит Линукс, поскольку драйвер для ati radeon 9550 сейчас тормознутый, а может он для kde4 ни как не подходит. Так вот, не может ли быть, что когда компутер выполняет тесты на ext4 и btrfs, то пользовательтским приложениям, всяким там kde4, дрова ati radeon 9550 просто не будут работать? Лично у меня дежавю, где то я уже это видел! А это эффект я видел на ms windows 3.1, 95, 98, me, xp... Я правильно понимаю, что высокие перфомансы для ext4, btrfs фактически создают мой компьютер однозадачным для этих замечательных файловых систем, а я пользователь, программист вроде как здесь и не при чём?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	37. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от pavlinux (ok) on 31-Авг-10, 15:18
	>программист вроде как здесь и не при чём? iowait bug
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	39. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 15:21
	>> программист вроде как здесь и не при чём? > iowait bug Explain?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	40. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от pavlinux (ok) on 31-Авг-10, 15:32
	>>> программист вроде как здесь и не при чём? >> iowait bug >Explain? .... планировщик задач и ввода/вывода как-то кооперировать надо. А то SATA контроллер захватил шину, проц и пипец....., жди другого запроса на I/O, тогда, .... в период переключения запроса к шине, может быть успеет вклиниться процесс. Говорил же, на многоПРОЦЕССОРНЫХ компах и со SCSI, на шине PCI-X, через MSI или даже без, таких глюков нет.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	52. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Andrew Kolchoogin on 31-Авг-10, 16:53
	> .... планировщик задач и ввода/вывода как-то кооперировать надо. Логично.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	148. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от iZEN (ok) on 01-Сен-10, 14:08
	>>> программист вроде как здесь и не при чём? >> iowait bug > >Explain? https://bugzilla.kernel.org/show_bug.cgi?id=12309
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

48. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
Сообщение от du ch on 31-Авг-10, 16:40
Парни, есть freebsd 8-stable с последним zfs на 4ТБ (почти заполнен кажись). Давай те пишите какие тесты делать, я буду делать и выкладывать результат, если надо. Но за последний год работы зарекомендовало себя отлично, никаких тормозов, просто лапочка.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	114. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–2 +/–
	Сообщение от iZEN (ok) on 01-Сен-10, 08:16
	>Парни, есть freebsd 8-stable с последним zfs на 4ТБ (почти заполнен кажись). >Давай те пишите какие тесты делать, я буду делать и выкладывать >результат, если надо. Но за последний год работы зарекомендовало себя отлично, >никаких тормозов, просто лапочка. Нужно проследить поведение системы под нагрузкой, когда пул заполнен на 99%. Ext4 и Btrfs в этом случае ведут себя неадекватно.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	126. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Andrew Kolchoogin on 01-Сен-10, 10:12
	> Нужно проследить поведение системы под нагрузкой, когда пул заполнен на 99%. Ext4 > и Btrfs в этом случае ведут себя неадекватно. ZFS тоже. И любая другая copy-on-write файловая система будет в таких условиях вести себя неадекватно by design. Я задавал этот вопрос (деградация быстродействия файловой системы при заполненном пуле) архитектору ZFS -- ответ приведён выше. ;)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	149. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от iZEN (ok) on 01-Сен-10, 14:13
	>> Нужно проследить поведение системы под нагрузкой, когда пул заполнен на 99%. Ext4 >> и Btrfs в этом случае ведут себя неадекватно. > >ZFS тоже. И любая другая copy-on-write файловая система будет в таких условиях >вести себя неадекватно by design. К сожалению, ответ "тоже будет вести себя" меня не устраивает. >Я задавал этот вопрос (деградация быстродействия файловой системы при заполненном пуле) архитектору >ZFS -- ответ приведён выше. ;) Где?! Конкретика?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

57. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
Сообщение от dimqua (ok) on 31-Авг-10, 17:28
Ну кому интересно как там работает FUSE, когда уже две нативные реализации есть? Только форониксу...
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

65. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrfs"	+/–
Сообщение от XoRe (ok) on 31-Авг-10, 17:51
> Представлены результаты сравнения производительности работающей в пространстве пользователя реализации файловой системы ZFS - ZFS-FUSE (0.6.9 и тестовый выпуск 0.7.0) с файловыми системами EXT4 и Btrfs. Сравнение проводилось в установленном по умолчанию дистрибутиве Ubuntu 10.04.1 (x86_64). И текст по ссылке: > For our testing of ZFS-FUSE, we used both the latest stable 0.6.9 release and a 0.7.0 Git snapshot as of their latest official code in their Git repository as of 2010-08-28. ... > For this ZFS-FUSE benchmarking we performed a clean installation of Ubuntu 10.04.1 LTS (x86_64) and installed the latest Linux kernel Git code for Linux 2.6.36 as of 2010-08-26. С одной стороны, Ubuntu 10.04.1 "из коробки". С другой стороны, и ядро Linux, и подсистема ZFS-FUSE скомпилированы (на этой машине, я так полагаю) из исходников с git репозитория. Т.е. взяли "официальный дистрибутив из коробки". И всего-лишь добавили ядро и фс из git. Насколько "изкоробочным" можно считать такое решение, если производительность здесь зависит только от ядра и файловой системы, а ОБА как раз взяты далеко не "из коробки"?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	106. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrfs"	+/–
	Сообщение от Andrew Kolchoogin on 01-Сен-10, 00:02
	> Насколько "изкоробочным" можно считать такое решение, если производительность здесь > зависит только от ядра и файловой системы, а ОБА как раз взяты далеко не "из коробки"? Эхъ. "... Один закоммитит работающую лампочку, пока все слишном заняты срачем, чтобы это заметить..." http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/funnies... Да, Фороникс такой Фороникс. ;)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

135. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+4 +/–
Сообщение от sluge (ok) on 01-Сен-10, 11:08
непонимаю этот фанатизм по поводу zfs. все равно по скорости она не догонит ext4, так с чего же  сыр бор затевать?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	150. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	–1 +/–
	Сообщение от iZEN (ok) on 01-Сен-10, 14:18
	>непонимаю этот фанатизм по поводу zfs. все равно по скорости она не >догонит ext4, так с чего же  сыр бор затевать? Вот когда форониксы сделают "zfs set checksum=off poolname/testfilesystem", тогда можно будет сравнить. ;)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	156. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от минона on 01-Сен-10, 15:07
	izen открыл для себя тюнинг фс. если чё, то в бтр тоже checksum работает https://btrfs.wiki.kernel.org/index.php/FAQ#What_checksum_fu... >Currently Btrfs uses crc32c for data and metadata. The disk format has room for 256bits of checksum for metadata and up to a full leaf block (roughly 4k or more) for data blocks. Over time we'll add support for more checksum alternatives. так что ещё один факт лжи izen'а зафикшен.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	158. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от iZEN (ok) on 01-Сен-10, 15:32
	>izen открыл для себя тюнинг фс. >если чё, то в бтр тоже checksum работает Я в курсе, к.О. >так что ещё один факт лжи izen'а зафикшен. Тобой? Ну-ну. По-моему, я нигде ещё не сравнивал ZFS с Btrfs кроме как в контексте чисто маркетинговых перспектив.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	160. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от минона on 01-Сен-10, 15:40
	ну конечно! :D ты сравнивал с ext4 (и однозначно "в контексте чисто маркетинговых перспектив"). и не важно что ext4 чуть быстрее бтр, которая в свою очередь быстрее zfs. никакой связи и закономерностей. главное что есть повод наехать на фроникс - т.пые же.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	164. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от iZEN (ok) on 01-Сен-10, 16:02
	>ну конечно! :D >ты сравнивал с ext4 (и однозначно "в контексте чисто маркетинговых перспектив"). >и не важно что ext4 чуть быстрее бтр, которая в свою очередь >быстрее zfs. >никакой связи и закономерностей. главное что есть повод наехать на фроникс - >т.пые же. У тебя что-то с логикой. Я отвечал конкретно на эту сентенцию: Вопрос: "непонимаю этот фанатизм по поводу zfs. все равно по скорости она не догонит ext4, так с чего же  сыр бор затевать?" Мой ответ: "Вот когда форониксы сделают "zfs set checksum=off poolname/testfilesystem", тогда можно будет сравнить. ;)" Чего тут нелогичного? ZFS и Ext4 можно будет сравнивать, когда ZFS приведут к тому состоянию, в котором находится Ext4, чтобы было что с чем сравнивать.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	166. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от минона on 01-Сен-10, 16:10
	да нет, батенька, с логикой траблы у тебя. большие траблы.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	170. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от аноним on 01-Сен-10, 17:06
	в ext4 тоже отруби тогда, умник https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Journal_ch... плохому танцору всегда что-то мешает. izen, ты танцевать умеешь?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	174. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Anon Y Mous on 01-Сен-10, 20:47
	>>непонимаю этот фанатизм по поводу zfs. все равно по скорости она не >>догонит ext4, так с чего же  сыр бор затевать? > >Вот когда форониксы сделают "zfs set checksum=off poolname/testfilesystem", тогда можно будет сравнить. >;) Да ладно. Оверхед от контрольных сумм там скорее всего сущие копейки. Там в другом дело. tiobench по умолчанию пишет блоками по 4К, что совпадает с размером страницы памяти, которыми оперируют btrfs и ext4, но не совпадает с размером блока по умолчанию в 128К, которым оперирует ZFS. Интереснее было бы посмотреть результаты того же теста, но с блоком 128К. Ну и плюс какие-нибудь косяки с флэшем могут вносить свою лепту
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	183. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от аноним on 02-Сен-10, 09:05
	каким образом? http://lwn.net/Articles/342892/ >ZFS would use one block pointer per block, but each object would use a different block size - e.g., 512 bytes, or 128KB - depending on the size of the object. а вот и основная разница >In summary, btrfs organizes everything on disk into a btree of extents containing items and data. ZFS organizes everything on disk into a tree of block pointers, with different block sizes depending on the object size. вот такие они, соляро-бсд-java-zfs'ники.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	190. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Anon Y Mous on 02-Сен-10, 19:14
	> каким образом? >http://lwn.net/Articles/342892/ >>ZFS would use one block pointer per block, but each object would use a different block size - e.g., 512 bytes, or 128KB - depending on the size of the object. А вот таким - до тех пор, пока объект меньше чем recordsize, установленный для файловой системы, он занимает места ровно столько, сколько нужно секторов для его хранения. Как только он перешагивает через recordsize, то каждый блок в этом объекте становится размером recordsize. Поскольку фороникс все тестирует с установками по умолчанию, вот и получаются файлы размером 32M состоящие и блоков 128КБ, соответственно, при перезаписи случайным образом блокаи размером по 4КБ получается много лишней работы. То есть надо или конфигурить recordsize 4КБ, или заставлять tiobench писать блоками по 128КБ, чтобы получилось сравнение яблок с яблоками, а не с вишнями. > вот такие они, соляро-бсд-java-zfs'ники. Сказать-то что хотел?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	191. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от аноним on 03-Сен-10, 02:32
	не верно. по скольку уже выяснили, что zfs совсем не обязатльно иметь блок размером именно в 128к. также логично предположить, что время выделения блока любого размера из перечисленных - это О(1). более того, для бтр в 32М блоков по 4к большее количество получается, чем для zfs по 128к. опять же, любое прикладное по не выделяет блоки, оно просто передает порцию данных для io (объектом же является весь файл, а не его куски), соответственно сколько блоков выделять, в каком количестве и как это согласуется с конкретным физ.девайсом, секторами, головками и пр. поэтому ваше предположение, что zfs не умеет этого делать - хм, смешно как минимум. т.е. абсолютно не факт, что если вы пишете в файл порциями по N, то и блок будет по N. еще раз прочтите (про ахилесову пяту zfs - SLAB): >The central on-disk data structure was the slab - a chunk of disk divided up into the same size blocks, like that in the SLAB kernel memory allocator, which he also created. Instead of extents, ZFS would use one block pointer per block, but each object would use a different block size - e.g., 512 bytes, or 128KB - depending on the size of the object. вот все его плюсы и минусы в популярном изложении http://en.wikipedia.org/wiki/Slab_allocation >Slab – объем памяти, за счет которого кэш может увеличиваться или уменьшаться. Он представляет собой распределение памяти в кэш, а его размер обычно кратен размеру страницы памяти. Slab должен содержать список свободных буферов, а также список буферов, которые были выделены (в случае большого размера slab’а). так что панацея отменяется.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	192. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Anon Y Mous on 03-Сен-10, 13:54
	Все, что ты написал - неверно. Не хочешь верить мне - продолжай дальше верить статье дамы, которая в последний раз в код ZFS заглядывала в 2004 году. Ну или обратить к первоисточнику - самому коду, - если хватит терпения и времени разобраться.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	193. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Аноним (??) on 04-Сен-10, 00:36
	хочешь сказать что zfs пошла по пути регрессий? :D ну а если нет, то и сам поймешь почему порции данных, отличные от 4к ничего не изменят. зы: думаю ты уже и сам понял что фигню сморозил. про ахилесову пяту, slab, я не настаиваю. может он и стал лучше (что заметно снизит потребность в озу). но лучше бтри не получится. но речь шла не об этом, а о размерах блоков. а они никах от порций на io не зависят. сам посуди, иначе все файлы, имеющие структуру (exe, elf, avi, jpg,..) и имеющий маленький заголовок (первая порция на запись), а это почти все файлы - имели бы и блоки 512, ну максимум 4к. ззы: можно сколько угодно раздувать щеки, отсылать к исходникам - это не прибавит знаний, здравого смысла и конструктива к разговору.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	194. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Anon Y Mous on 04-Сен-10, 13:35
	>хочешь сказать что zfs пошла по пути регрессий? :D Каких регрессий? Ты о чем? >ну а если нет, то и сам поймешь почему порции данных, отличные >от 4к ничего не изменят. Ты вместо того, чтобы тут демагогию разводить, взял бы да попробовал - сам бы все и увидел. >зы: >думаю ты уже и сам понял что фигню сморозил. Фигню тут ты несешь. Ты даже не попытался понять, то что я написал > про ахилесову пяту, slab, я не настаиваю. может он и стал лучше (что заметно снизит потребность в озу) Вот видишь, даже сам отползать начинаешь. > но лучше бтри не получится. Конечно, лучше бтр сделать нельзя. >но речь шла не об этом, а о размерах блоков. а они никах от порций на io не зависят. Ты сам то понимаешь, что ты пишешь? Еще раз перечитай, то, что я написал. И попробуй понять, прежде чем хвататься за клавиатуру >сам посуди, иначе все файлы, имеющие структуру (exe, elf, avi, jpg,..) и >имеющий маленький заголовок (первая порция на запись), а это почти все >файлы - имели бы и блоки 512, ну максимум 4к. Объясняю еще раз специально для тебя - размер блока, который ZFS будет использовать для хранения файла, зависит не от структуры этого файла, а от значения свойства recordsize для файловой системы и размера самого файла. Пока размер файла меньше, чем значение recordsize, файл может поместиться в одном блоке и размер этого блока составляет минимальное количество секторов, необходимое для сохранения файла, и может меняться - если файл вырастет (но не дорастет до recordsize), размер блока тоже вырастет, если уменьшится - размер блока тоже уменьшится. Как только файл перерастает recordsize, ZFS фиксирует для него размер блока. То есть при recordsize по умолчанию, файл размером 129К будет занимать  два блока по 128К, а модификация блока размером 4К внутри любого из этих двух блоков, потребует чтения блока 128К с диска (если его не найдется в кэше), модификации 4К в нем, выделения нового блока 128К и записи его. Если у тебя файл структурирован и имеет записи фиксированного размера, как в тесте Threaded IO Tester фороникса, где размер блока по умолчанию составляет 4К, то recordsize нужно сделать равным размеру записи, чтобы получилось сравнение яблок с яблоками. Ну или увеличивать размер блока в Threaded IO Tester до 128К. >ззы: >можно сколько угодно раздувать щеки, отсылать к исходникам - это не прибавит >знаний, здравого смысла и конструктива к разговору. Вот и не раздувай. Ибо пока ни знаний, ни здравого смысла, ни конструктива ты ни на йоту не добавил.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	195. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Аноним (??) on 04-Сен-10, 14:11
	>Каких регрессий? Ты о чем? о том, что вы предположили, что zfs не в состоянии для файла в 32М создавать блоки по 128к, если порции по 4к. >Вот видишь, даже сам отползать начинаешь. с культурой общения у вас БА_А_Альшие траблы. речь была не об убогости слаб. вот и все. >Объясняю еще раз специально для тебя - размер блока, который ZFS будет использовать для хранения файла, зависит не от структуры этого файла, а от значения свойства recordsize для файловой системы и размера самого файла. и какое же значение recordsize у zfs?:D >как в тесте Threaded IO Tester фороникса, где размер блока по умолчанию составляет 4К в тесте нет блоков, есть буферы для вводв-вывода. блоки - это исключительно понятия фс. и на пользовательском уровне не применяются. зы: на "вы" вас мама не учила общаться?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	196. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Anon Y Mous on 04-Сен-10, 15:34
	>>Каких регрессий? Ты о чем? > >о том, что вы предположили, что zfs не в состоянии для файла >в 32М создавать блоки по 128к, если порции по 4к. Я ничего не предполагал. Я Вам описал, как там все работает на самом деле. Вы не поняли. До сих пор >>Вот видишь, даже сам отползать начинаешь. > >с культурой общения у вас БА_А_Альшие траблы. Не большие чем, у Вас, анонимный собеседник. >>Объясняю еще раз специально для тебя - размер блока, который ZFS будет использовать для хранения файла, зависит не от структуры этого файла, а от значения свойства recordsize для файловой системы и размера самого файла. > >и какое же значение recordsize у zfs?:D Читайте внимательнее. Значение recordsize по умолчанию было названо. Фороникс все тестирует по умолчанию, так что.. >>как в тесте Threaded IO Tester фороникса, где размер блока по умолчанию составляет 4К > >в тесте нет блоков, есть буферы для вводв-вывода. Вы в этот тест даже не заглядывали, а рассуждаете, что там есть и чего нету. Загляните и убедитесь. >блоки - это исключительно понятия фс. и на пользовательском уровне не применяются. Да-да, конечно. Вам самому не смешно?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	197. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Аноним (??) on 04-Сен-10, 17:31
	http://en.wikipedia.org/wiki/ZFS#Variable_block_sizes >ZFS uses variable-sized blocks of up to 128 kilobytes. The currently available code allows the administrator to tune the maximum block size used as certain workloads do not perform well with large blocks. Automatic tuning to match workload characteristics is contemplated. где в новости (и в тесте) упоминание того, что в opensolaris максимальный размер блока в zfs установлен в 4к? >If data compression (LZJB) is enabled, variable block sizes are used. If a block can be compressed to fit into a smaller block size, the smaller size is used on the disk to use less storage and improve IO throughput (though at the cost of increased CPU use for the compression and decompression operations). ps: >>блоки - это исключительно понятия фс. и на пользовательском уровне не применяются >Да-да, конечно. Вам самому не смешно? нет. не смешно. не смешно, что солярку и zfs теперь "защищают" такие малокомпетентные "специалисты". изменить на пользовательском уровне размер блока, это всё равно, что утверждать, что нотепад при сохранение может менять размер сектора на диске - бред одного порядка достоверности.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	198. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Anon Y Mous on 04-Сен-10, 20:29
	>http://en.wikipedia.org/wiki/ZFS#Variable_block_sizes >>ZFS uses variable-sized blocks of up to 128 kilobytes. The currently available code allows the administrator to tune the maximum block size used as certain workloads do not perform well with large blocks. Automatic tuning to match workload characteristics is contemplated. > >где в новости (и в тесте) упоминание того, что в opensolaris максимальный >размер блока в zfs установлен в 4к? Вот я и говорю, что он не установлен, если это непонятно. Поэтому в этом тесте сравниваются яблоки с апельсинами. Вам объяснить, что значит вот эта фраза из вашей цитаты: The currently available code allows the administrator to tune the maximum block size used as certain workloads do not perform well with large blocks ??? >ps: >>>блоки - это исключительно понятия фс. и на пользовательском уровне не применяются >>Да-да, конечно. Вам самому не смешно? > >нет. не смешно. не смешно, что солярку и zfs теперь "защищают" такие >малокомпетентные "специалисты". Вам кажется. Можете продолжать видеть только то, что лежит на поверхности. Мне от этого будет только лучше. >изменить на пользовательском уровне размер блока, это всё равно, что утверждать, что >нотепад при сохранение может менять размер сектора на диске - бред >одного порядка достоверности. Рекомендую вам, прежде чем упрекать меня в малокомпетентности, задуматься о том, насколько компетентны вы сами. А также прочитать еще раз мои слова, и найти в них, где было хоть что-то про изменение размера сектора на диске.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	199. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от аноним on 05-Сен-10, 04:18
	>Вот я и говорю, что он не установлен, если это непонятно. Поэтому в этом тесте сравниваются яблоки с апельсинами. а он установлен. вот сюрприз, правда? :D называется установки по-умолчанию. и если вы хоть раз ставили осла и юзали zfs (в чем я сильно сомниваюсь) то должны знать даже его конкретное значение. >А также прочитать еще раз мои слова, и найти в них, где было хоть что-то про изменение размера сектора на диске. про сектор вы не говорили, но не меньшую глупость сказали: >Там в другом дело. tiobench по умолчанию пишет блоками по 4К, что совпадает с размером страницы памяти, которыми оперируют btrfs и ext4, но не совпадает с размером блока по умолчанию в 128К, которым оперирует ZFS. знатокам zfs сповящается - Variable block sizes........ Automatic tuning to match workload characteristics is contemplated. ... - что означает, что если zfs и принимает решение использовать блок в 128к, то только пользы для. а tiobench вообще блоками не пишет. буферами он пишет. в юзерспейсе. а блоки (и/или inode'ы) - в кернел спейсе. оченно разные вещи знаете ли.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	200. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Anon Y Mous on 05-Сен-10, 07:58
	>>Вот я и говорю, что он не установлен, если это непонятно. Поэтому в этом тесте сравниваются яблоки с апельсинами. > >а он установлен. вот сюрприз, правда? :D >называется установки по-умолчанию. и если вы хоть раз ставили осла и юзали >zfs (в чем я сильно сомниваюсь) то должны знать даже его >конкретное значение. Я уже устал повторять - по умолчанию свойство recordsize имеет значение 128К, что не есть лучший выбор, когда прикладная нагрузка пишет и читает блоками по 4К случайным образом. Чтобы сравнивать яблоки с яблоками в этом тесте, нужно для ZFS установить свойство recordsize в 4К. Поскольку фороникс тестирует все с установками по умолчанию, этого не было сделано, то есть использовалось для recordsize использовалось значение по умолчанию 128К. Я вроде на русском языке пишу. Что непонятно? >>А также прочитать еще раз мои слова, и найти в них, где было хоть что-то про изменение размера сектора на диске. > >про сектор вы не говорили, но не меньшую глупость сказали: >>Там в другом дело. tiobench по умолчанию пишет блоками по 4К, что совпадает с размером страницы памяти, которыми оперируют btrfs и ext4, но не совпадает с размером блока по умолчанию в 128К, которым оперирует ZFS. Предлагаю вам скачать уже исходные тексты программы tiotest, используемой в этом тесте, и убедиться самостоятельно (если, конечно, текст программы на C понимать умеете), кто здесь сказал глупость и какую именно. >знатокам zfs сповящается - Variable block sizes........ Automatic tuning to match workload >characteristics is contemplated. ... - что означает, что если zfs и >принимает решение использовать блок в 128к, то только пользы для. Предлагаю вам посмотреть значение слова contemplated в словарике, и еще раз попробовать понять это предложение. Если не справитесь - скажите, попробую помочь. >а tiobench вообще блоками не пишет. буферами он пишет. в юзерспейсе. а >блоки (и/или inode'ы) - в кернел спейсе. оченно разные вещи знаете ли. Если вам больше нравиться называть куски фиксированного размера со смещениями, кратными этому размеру, буферами - называйте, я не против. Просто обычно их называют блоками.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	201. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от аноним on 05-Сен-10, 09:10
	>ZFS uses variable-sized blocks of up to 128 kilobytes. The currently available code allows the administrator to tune the maximum block size used as certain workloads do not perform well with large blocks. Automatic tuning to match workload characteristics is contemplated. переводится >ZFS использует блоки переменного размера до 128 килобайтов. В настоящее время доступный кодекс позволяет администратору настраивать максимальный размер блока, используемый, поскольку определенные рабочие нагрузки не выступают хорошо с большими блоками. Автоматическая настройка, чтобы соответствовать особенностям рабочей нагрузки рассмотрена. рпеевод глагола contemplate http://lingvo.yandex.ru/contemplate/%D1%81%20.../ >обдумывать, продумывать, размышлять 128k - максимальный блок, 8к - блок по умолчанию с осле. >Предлагаю вам посмотреть значение слова contemplated в словарике, и еще раз попробовать понять это предложение. Если не справитесь - скажите, попробую помочь. предлагаю вам ознакомиться с адресным пространством ядра и адресным пространством пользователя, способами передачи данных из оного в другой, основами С и уже потом давать советы. >Если вам больше нравиться называть куски фиксированного размера со смещениями, кратными этому размеру, буферами - называйте, я не против. Просто обычно их называют блоками. нравиться или нет - это не важно. блоком в zfs называется участок на диске перменной длины. в традиционных фс его аналог inode. получить доступ к нему можно только из пространства ядра (или из fuse, дабы тот установлен) и через системные вызовы ядра. буфер - это область памяти. для пользовательского процесса (коим и является указанный тест, ибо он даже нифига не модуль ядра) в пользовательском адресном пространстве процесса. т.е. НИКАКОЙ связи. удобно это вам или нет. вы ПРОФАН Anon. это не оскорбление, это просто факт.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	202. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Anon Y Mous on 05-Сен-10, 13:54
	>вы ПРОФАН Anon. это не оскорбление, это просто факт. Ну что ж, вы можете продолжать заблуждаться сколько угодно. Мне от этого только лучше.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	203. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от аноним on 05-Сен-10, 20:11
	врядли ВАМ будет лучше. вы ведь даже объяснить не в состоянии, как блоки-буферы вв из теста коррелируют с блоками файловой системы zfs. и это еще не говоря про планировщик вв, кэшь, слаб и т.д. и это печально.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	204. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от AnonYMous (ok) on 05-Сен-10, 23:42
	>врядли ВАМ будет лучше. Ну это мне виднее, не так ли? >вы ведь даже объяснить не в состоянии, как блоки-буферы вв из теста >коррелируют с блоками файловой системы zfs. >и это еще не говоря про планировщик вв, кэшь, слаб и т.д. > >и это печально. Я объяснил. Несколько раз. Просто некоторые люди в силу определенных особенностей не умеют воспринимать то, что до них пытаются донести, и возомнив себя экспертом и вооружившись автоматическим переводчиком и пачкой цитат из википедии пытаются сделать вид, что что-то понимают в устройстве и механизмах работы ZFS, не отдавая себе отчета в том, насколько этожалко и смешно выглядит. И вот это действительно печально.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	205. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от минона on 07-Сен-10, 13:59
	>Ну это мне виднее, не так ли? не так >Я объяснил. Несколько раз. Просто некоторые люди в силу определенных особенностей не умеют воспринимать то, что до них пытаются донести, и возомнив себя экспертом каким образом данные из буфера прикладной программы попадают в адресное пространство ядра и, затем, в блоки zfs? ответьте только на этот вопрос. и сможете дальше пальцы кидать.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	206. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от Anon Y Mous on 09-Сен-10, 20:24
	>>Ну это мне виднее, не так ли? > >не так Правда чтоли? >>Я объяснил. Несколько раз. Просто некоторые люди в силу определенных особенностей не умеют воспринимать то, что до них пытаются донести, и возомнив себя экспертом > >каким образом данные из буфера прикладной программы попадают в адресное пространство ядра >и, затем, в блоки zfs? Через промежуточный буфер в ARC. Правда чем тебе это поможет, я не знаю. >ответьте только на этот вопрос. и сможете дальше пальцы кидать. Теперь понятно, чем вы тут занимаетесь, минона.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	207. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от crypt (??) on 15-Сен-10, 23:02
	Вот так и закончился разговор анонима-студента с Anon Y Mous :)) Правду говорят: и смех, и грех.)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

141. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
Сообщение от nb (??) on 01-Сен-10, 12:23
http://ru.wikipedia.org/wiki/Btrfs http://ru.wikipedia.org/wiki/ZFS Смотрим графу (уже) "разработчик", думаем. К.О. все прения, кто круче - БТР или Зю - скоро будут не актуальны.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	145. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от минона on 01-Сен-10, 13:14
	>Смотрим графу (уже) "разработчик", думаем. и чего? это ничего не объясняет - бтр в апстриме ядра линуха разрабатывается, а zfs - внутри оракла. >К.О. все прения, кто круче - БТР или Зю - скоро будут не актуальны. дык, уже.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	151. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от iZEN (ok) on 01-Сен-10, 14:28
	>http://ru.wikipedia.org/wiki/Btrfs >http://ru.wikipedia.org/wiki/ZFS > >Смотрим графу (уже) "разработчик", думаем. >К.О. все прения, кто круче - БТР или Зю - скоро будут не актуальны. Я думаю, что Btrfs на Linux будет оставаться экспериментальной очень долго. Впрочем, так же, как и ZFS на Linux. Oracle не нужна ZFS на Linux. Альтернатива ZFS в Linux для Oracle, похоже, после приобретения активов Sun, тоже не очень интересна. Таким образом получается сегментирование продуктов: нишевые решения остаются в своих нишах и не мешают друг другу, не конкурируя за кошелёк клиентов. Oracle, скорее, вложится в поддержку SOLARIS, чтобы удешевить стоимость сопровождения при существующей продажной цене, чем будет дописывать жизненно необходимый инструментальный набор для Btrfs. Приобретение готового продукта сильно уменьшило шансы доморощенной ФС попасть в продакшен.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	154. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от ы on 01-Сен-10, 15:02
	>Я думаю, что Btrfs на Linux будет оставаться экспериментальной очень долго В убунте 11.04 запланирована как дефолтная fs
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	155. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от минона on 01-Сен-10, 15:03
	доморощенной? :D это zfs теперь будет доморощенной. онли. а бтр таки в апстриме. факты и фантазии izen'а всё-таки разные вещи - разработка бтр увеличилась на порядок. таже убунту, миго и ещё ряд уже докладывают, что бтр будет фс по-умолчанию в конкретных версиях. zfs же будет (а будет ли?) развиваться в закрытом режиме внутри оракла и только после выхода следующего блоба солярки будет доступна (а будет ли?) широким массам. с другой стороны zfs для флагманких продуктов оракла (субд, эрп,..) не особо нужна. собственно вообще не нужна. у них свой ASM есть. и с zfs он не пересекается никак.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	161. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+1 +/–
	Сообщение от iZEN (ok) on 01-Сен-10, 15:43
	>разработка бтр увеличилась на порядок. Что-то не видно прогресса. fsck для Btrfs всё ещё не готов и, похоже, заброшен. >таже убунту, миго и ещё ряд уже докладывают, что бтр будет фс по-умолчанию в конкретных версиях. Наличие подгружаемого модуля ядра ещё ничего не говорит о готовности всей необходимой инфраструктуры. >zfs же будет (а будет ли?) развиваться в закрытом режиме внутри оракла >и только после выхода следующего блоба солярки будет доступна (а будет >ли?) широким массам. Существующих возможностей ZFS выше крыши — задел есть лет на десять, чтобы это использовать в продакшене и тюнить узкие места. >с другой стороны zfs для флагманких продуктов оракла (субд, эрп,..) не особо нужна. собственно вообще не нужна. Им нужна унификация. Когда файловая система одна, а СУБД использует ZVOL, то не нужны дополнительные накладные расходы на сопровождение ещё чего-то. Я думаю, Oracle хорошо просекла эту фишку и будет отказываться от несвязанных и слабосвязанных между собой инструментов в пользу уже отлаженного апстрима — универсальной ZFS, наращивая её возможности не изнутри (её структура полностью завершена), а существующими средствами НАД ФС и блочными устройствами. >у них свой ASM есть. и с zfs он не пересекается никак. "ASM предполагает, что из неформатированных разделов диска формируются дисковые группы, внутри которых формируется своего рода облегченный специализированый вариант файловой системы для нужд БД." — ну, да, точно — ZVOL'ы подходят как нельзя кстати для "дисковых" групп под "облегчённые ФС для нужд БД". "Управление «файлами» внутри дисковых групп берет на себя облегченный специализированый вариант экземпляра СУБД (экземпляр ASM)." — гибко дополняет отсутствующие возможности ZFS пула по эффективному управлению ZVOL'ами.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	165. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от минона on 01-Сен-10, 16:04
	ещё раз  -  разработка бтр увеличилась на порядок. таже убунту, миго и ещё ряд уже докладывают, что бтр будет фс по-умолчанию в конкретных версиях. всё остальное одним словом - слив. ps: >не, да, точно — ZVOL'ы подходят как нельзя кстати для "дисковых" групп под "облегчённые ФС для нужд БД". возможно (даже не говорю о том, что скорость оракловой субд под zfs (тюненная, без чексум) конкретно проседает по сравнению с ufs, vxfs, и пр http://ru.wikipedia.org/wiki/Veritas_File_System ) >VxFS является основной файловой системой в HP-UX. Также VxFS работает в Solaris, OpenSolaris, AIX, Linux, SINIX и UnixWare. проблема только в том, что этого нет. и что характерно, точно не появятся для платформ, отличных от солярки. а таких не мало. а оракл любит унифицировать свои решения, что логично. так что возможно что бтр и в солярке появится.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	167. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от iZEN (ok) on 01-Сен-10, 16:30
	>[оверквотинг удален] >миго и ещё ряд уже докладывают, что бтр будет фс по-умолчанию >в конкретных версиях. >всё остальное одним словом - слив. >ps: >>не, да, точно — ZVOL'ы подходят как нельзя кстати для "дисковых" групп под "облегчённые ФС для нужд БД". > >возможно (даже не говорю о том, что скорость оракловой субд под zfs >(тюненная, без чексум) конкретно проседает по сравнению с ufs, vxfs, и >пр http://ru.wikipedia.org/wiki/Veritas_File_System ) >>VxFS является основной файловой системой в HP-UX. Также VxFS работает в Solaris, OpenSolaris, AIX, Linux, SINIX и UnixWare. Ну, вот, ты уже мешаешь в одну кучу виртуальные блочные устройства (ZVOL) и ФС с тюнингом по чексуммам. :)) Остановись. Отдышись. >проблема только в том, что этого нет. и что характерно, точно не >появятся для платформ, отличных от солярки. Oracle ASM не зависит от конкретной ФС, ему нужны просто блочные устройства. >оракл любит унифицировать свои решения, что логично. >так что возможно что бтр и в солярке появится. Зачем Btrfs в SOLARIS, если ZFS/ZVOL удовлетворяют потребностям использования ASM на 100%?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	171. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от аноним on 01-Сен-10, 17:17
	>Ну, вот, ты уже мешаешь в одну кучу виртуальные блочные устройства (ZVOL) и ФС с тюнингом по чексуммам. :)) Остановись. Отдышись. да нет. я последователен как никогда. это ведь ты пытаешься вставить zvol в asm, который работает на (НА!) любой платформе, где нет никаких zvol. проблемы с образованием? >Зачем Btrfs в SOLARIS, если ZFS/ZVOL удовлетворяют потребностям использования ASM на 100%? где удовлетворяет? с каких пор в asm уже встроили ZFS/ZVOL? :D ты уж совсем забрехался.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	175. "Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..."	+/–
	Сообщение от злодейко on 01-Сен-10, 20:48
	>http://ru.wikipedia.org/wiki/Btrfs >http://ru.wikipedia.org/wiki/ZFS > >Смотрим графу (уже) "разработчик", думаем. >К.О. все прения, кто круче - БТР или Зю - скоро будут >не актуальны. там в основе своей разные идеи - посмотрим чья победит 8-))) http://lwn.net/Articles/342892/ особенно нравятся аналогии с мышами (планцетными и сумчатыми 8-))
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема