Исходное сообщение
"Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..." Отправлено Andrew Kolchoogin, 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 сто раз говорилось.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>>Да в том то и дело, что 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 сто > раз говорилось.
	Введите код, изображенный на картинке: