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

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

"Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
Сообщение от opennews (ok) on 11-Янв-11, 12:37
В DragonFly BSD осуществлен (http://leaf.dragonflybsd.org/mailarchive/commits/2011-01/msg...) переход с четвертой на пятую версию файловой системы Hammer, которая отличается поддержкой (http://www.opennet.me/opennews/art.shtml?num=28608) объединения дубликатов данных. Одновременно началась (http://leaf.dragonflybsd.org/mailarchive/commits/2011-01/msg...) работа над шестой версией Hammer, в которой планируется реализовать новый метод хэширования директорий. Ресурс Phoronix представил (http://www.phoronix.com/scan.php?page=article&item=dragonfly...) результаты тестирования производительности файловых систем Hammer v4, ZFS, UFS, EXT3, EXT4 и Btrfs. -  В тесте на чтение данных BlogBench ФС Hammer заметно отстала от других ФС; -  В тесте BlogBench на запись -  ФС Hammer заметно обогнала UFS и ZFS, немного уступив Btrfs и значительно отстав от Ext3 и Ext4; -  В тесте на скорость упаковки Gzip-архивов,  ФС Hammer обогнала ZFS, но немного отстала от остальн... URL: http://www.phoronix.com/scan.php?page=article&item=dragonfly... Новость: http://www.opennet.me/opennews/art.shtml?num=29238
Ответить | Правка | Cообщить модератору

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

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

2. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+2 +/–
Сообщение от Ivan1986 on 11-Янв-11, 12:38
>была на уровне ZFS, немного отстала от ZFS так где из них опечатка на btrfs ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	22. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+4 +/–
	Сообщение от terr0rist (ok) on 11-Янв-11, 14:55
	А это: > В тесте на скорость распаковки исходных текстов Linux-ядра ФС Hammer была на уровне ZFS, немного отстала от ZFS, UFS, EXT3 и EXT4, но существенно обогнала UFS. отстала от UFS, но существенно обогнала UFS.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+6 +/–
Сообщение от Аноним (??) on 11-Янв-11, 12:46
>Релиз ФС Hammer 5. >результаты тестирования производительности файловых систем Hammer v4, ... умом фороникс не понять
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
	Сообщение от JL2001 (ok) on 11-Янв-11, 12:52
	>>Релиз ФС Hammer 5. >>результаты тестирования производительности файловых систем Hammer v4, ... > умом фороникс не понять DragonFlyBSD 2.8.2 (the latest release) was benchmarked in both HAMMER and UFS configurations in a stock configuration. мб потому, что тестировали release а переход был в git ?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	16. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+1 +/–
	Сообщение от Аноним (??) on 11-Янв-11, 14:16
	а смысл называть новость о тестировании hammer4 'Релиз ФС Hammer 5'? приписали бы внизу что-то типа: кстати, на днях вышел хаммер5. скоро потестим - следите за нашим сайтом
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	26. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+2 +/–
	Сообщение от User294 (ok) on 11-Янв-11, 15:53
	> а смысл называть новость о тестировании hammer4 'Релиз ФС Hammer 5'? Умом товарисчей аппрувящих/корректящих новости на опеннете не понять. Они иногда группируют новости так, что просто диву даешься. Я б еще понял, если б на опеннете было по 100 новостей в день. Но при потоке в 2-3 новости в сутки пихать ежей и ужей в одну кучу - весьма оригинально. > приписали бы внизу что-то типа: кстати, на днях вышел хаммер5. скоро потестим > - следите за нашим сайтом Подозреваю что это местные редакторы наредактили и впхнули зачем-то 2 в общем то разные новости в одну. В данном случае еще не совсем клиника - хотя-бы топик общий более-менее, все-таки. Бывает куда более шизанутое объединение новостей. Кто б мне еще объяснил великий смысл в странной/кривой группировке новостей, когда их 2 щтуки в день? Впрочем случаются и другие отжиги. Например, статьи "не попавшие в выпуски новостей" почему-то иногда (?) метятся как "важное". Это вообще деление на ноль какое-то (имхо, или уж важное и пусть сразу попадает в новости, или уж не столь важное и нефиг это тогда метить как важное?!).
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

4. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+2 +/–
Сообщение от JL2001 (ok) on 11-Янв-11, 12:46
> прокомментировал результаты тестов вот можно дельно комментировать тесты фороникса, а местные знатоки тока щёки дуют и цедят "форониксжефиглетёплоемягкое"
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+1 +/–
	Сообщение от JL2001 (ok) on 11-Янв-11, 12:53
	>> прокомментировал результаты тестов > вот можно дельно комментировать тесты фороникса, а местные знатоки тока щёки дуют > и цедят "форониксжефиглетёплоемягкое" кстати ни кто на русском не может ли кратко описать достоинства Hammer ? или ссылку подкинуть..
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

5. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	–9 +/–
Сообщение от ua9oas интересуется Миша Рыцаревъ on 11-Янв-11, 12:50
Интересная загадка- а почему их так много? Как то мне на этот вопрос тут уже отвечали (пока не могу найти, где. И список, который тогда там привели был намного больше здешнего!) И куда их столько? В винде вот уже давно как все одна да одна только (а все ли дистрибутивы линукс ее понимают? Например если стоит две ОС или ОС запущена через livecd и с тем есть проблемы, то как это решать? А производительностью ntfs от линуксовых как отличается?   А что там нового по reiser fs ? А то раньше про нее много писали, в т.ч. и то, что она другие в этих же тестах сможет выигрывать, но что-то новаго по ней уже давно не вижу.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "Миша рыцарев тупит"	+8 +/–
	Сообщение от Миша рыцарев тупит on 11-Янв-11, 13:09
	> Интересная загадка- а почему их так много? Потому что это вам не виндовс, где майкрософт за вас решил что вы будете жрать что дали. Технологии используемые в hammer, btrfs, zfs и подобных отличаются от файловых систем майкрософта настолько же насколько боинг отличается от дирижабля. Вы в вашем плане летать дирижаблями, если оно вам по вкусу. Но это слегка архаично, да. А то что MS ничего другого не продает - чьи проблемы то?! > А производительностью ntfs от линуксовых как отличается? Скорость дирижабля отличается от скорости боинга, наверное по причине прогресса технологий. А то что мимо майкрософта просвистели достижения технологий типа экстентов, b-деревьев, copy-on-write и прочих прелестей СОВРЕМЕННЫХ технологий файловых систем - вам никто не виноват. Можете до усрача верить что античные блочные аллокаторы с немеряными битмапами - венец прогресса технологий, хренли. Тем не менее, пока Майкрософт продает вам дирижабли, даже тормозные бздельники уже заканчивают собирать свои "боинги".
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	15. "Миша рыцарев тупит"	–2 +/–
	Сообщение от letsmac (ok) on 11-Янв-11, 14:11
	>>А то что мимо майкрософта просвистели достижения технологий типа экстентов, b-деревьев, copy-on-write и прочих прелестей СОВРЕМЕННЫХ технологий файловых систем - вам никто не виноват. Деревья Байера, там с первой версии. Года так с 1998, если не раньше.И экстенты там есть и непрерывные файлы и пулы и потоки и даже поддержка распределенных FAT. Кто пролетает - так это ещё вопрос :-) Там это уже 12 лет работает - а тут всё еще в бета версии.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	33. "Миша рыцарев тупит"	–1 +/–
	Сообщение от User294 (ok) on 11-Янв-11, 19:04
	> Деревья Байера, там с первой версии. Года так с 1998, если не раньше. Деревьями можно индексировать разные сущности. Я припоминаю только про индексирование директорий. Ну это и в *никсах сто лет есть. В всяких там XFS, JFS, EXT3 - шустро работающее индексирование директорий тоже явно не вчера сделали. > И экстенты там есть А файл $Bitmap - это чего? Уж не для того ли он создан, чтобы в этой битовой карте занятость блоков ФС отслеживать? Экстенты реализованные нормально - позволяют избавиться от такого безобразия, насколько я помню. Проблема такого способа отслеживания занятости места на томе - в том что на большом томе битовая карта получается здоровой и работа с большой битовой картой начинает тормозить. Ну так NTFS резвостью и не страдает. > и непрерывные файлы Это sparse чтоли? А давно sparse файлы считаются крутой фичой? > и пулы и потоки и даже поддержка распределенных FAT. В NTFS нет FAT. Там MFT, для начала. А что понимается под "распределенных FAT"? > Кто пролетает - так это ещё вопрос :-) О, а давайте сравним логику CoW "журналирования" и классического журнала. И надежность, ага. В одном случае без особых проблем журналятся и данные и метаданные без просадки скорости. Во втором случае - или журналят только метаданные, или скорость записи убивается в разы.  Насколько я знаю, нтфс с дефолтными настройками журналит только метаданные. А в каком там состоянии данные останутся... ну оно в этом не лучше EXT* и прочих классических ФС. У CoW-образных ФС в этом плане есть изрядный плюс. Они по скорости в лучшем случае почти как нежурналируемые, а по надежности - почти как журналируемые которые журналят полностью все данные+метаданные. Как по мне так на пролет похожи "классические" ФС, к которым и NTFS относится. > Там это уже 12 лет работает - а тут всё еще в бета версии. Что там в бета-версии? EXT3? А то у него тоже было тупорылое выделение блоков. И хешированные директории были. Это как, по вашей логике суперсовременная ФС получается? Офигенно! :)
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	36. "Миша рыцарев тупит"	+/–
	Сообщение от letsmac (ok) on 11-Янв-11, 19:26
	>>В NTFS нет FAT. Там MFT, для начала. А что понимается под "распределенных FAT"? DFS понимается. FAT хоть как понимай хоть, как MFT хоть как BSDM  - дело разработчика как он эту область назовет. >>А в каком там состоянии данные останутся... ну оно в этом не лучше EXT* и прочих классических ФС. 12 лет - ни единого разрыва :-D. >>У CoW-образных ФС в этом плане есть изрядный плюс. Теоретический. Практический - снос крыши кэшу. NTFS журналит кластеры для отмены - в лучшем случае это быстрее CoW, в худшем медленнее. Собсна все ответы есть у Руссиновича- что и как у NTFS. Журнал у неё много старше всех ext-подобных. >>Ну так NTFS резвостью и не страдает. Она ей наслаждается. Сравнивать Fuse реализацию за три корки хлеба и реализацию кода FS в ядре ? Это нереально. >>Это как, по вашей логике суперсовременная ФС получается? Офигенно! :) FS 12-летней давности не может быть суперсовременной. Но остальные по прежнему чет лепят и считают, что зоопарк FS у Linux уберсовременный. Да ни фига - отсталый он, все эти фишки тырятся у более современных реализаций. Слив № 10000 поздравляю с юбилеем.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	41. "Миша рыцарев тупит"	+/–
	Сообщение от User294 (ok) on 11-Янв-11, 20:59
	>>>В NTFS нет FAT. Там MFT, для начала. А что понимается под "распределенных FAT"? > DFS понимается. ?! Это ж сетевая ФС, которая всего лишь позволяет шаре по одному и тому же пути указывать на несколько физически разных машин. Кэп намекает: сетевые ФС есть и под *никсы, если что. Только вот при чем тут FAT/MFT, особенно распределенные? oO > FAT хоть как понимай хоть, как MFT хоть как BSDM Мне было бы интереснее понять как FAT относится к сетевой файловой системе DFS. И это, а комент про $Bitmap вы проигнорировали. Это по вашему так и надо современные ФС делать? Или чего? >  - дело разработчика как он эту область назовет. Ну, кроме названия у них еще и несколько разная логическая организация. В нтфс был некий бзик что все - файлы. Сам $Mft - тоже файл. Самое оригинальное то что он содержит запись указывающуб на сам себя :) > 12 лет - ни единого разрыва :-D. А еще можно 12 лет на запорожце поездить для полноты ощущений. Если уж никуда не торопиться и не гнаться за комфортом и параметрами - вполне вариант :) >>>У CoW-образных ФС в этом плане есть изрядный плюс. > Теоретический. И практический. Физику не обманешь. Когда на диск пишется файл, традиционная журналирующая ФС для честного журналирования должна записать его *дважды*: один раз - в журнал, второй - коммит задуманного в основную часть ФС. Ну или как компромисс позволяющий избежать просадки скорости, при журналинге только метаданных - не получится обеспечить честную транзакционность по принципу "все или ничего", и будет возможна ситуация когда облом случился в тот момент когда файл был наполовину старый и наполовину новый. И это не получится ни откатить назад, ни завершить операцию до конца. Из-за отсутствия потребных для этого данных. Такой подход (ordered журналирование и т.п. в терминах EXT3, etc) обеспечивает только корректное состояние метаданных при крахе, но данные файла (в лучшем случае) корректны только при дозаписи файла. А вот при перезаписи - файл может оказаться наполовину старой и наполовину новой версией, что вообще-то чревато неюзабельностью такого файла. Честное журналирование такой проблемы не имеет но писать 2 раза данные файла на диск для этого - не прикольно. Copy-on-write файловая система - по сути один большой журнал. Запись на физический девайс делается 1 раз, а откат к прошлому состоянию в случае проблем делается простым забиванием на то что не успели дописать. При том это применимо как к метаданным, так и к данным, что возможно благодаря логик работы CoW (копирование данных при записи). Фокус в том что CoW файловая система всегда производит запись в *новое* место, не разрушая старые данные. Даже при перезаписи файлов. Поэтому в случае краха всегда доступно старое состояние файла (и файловой системы заодно). Этот подход имеет свои грабли (фрагментация из-за копирования в сторонку того что изменено/дописано), но его плюсы перевешивают а грабли можно до некоторой степени пролечить. В итоге получается скорость файловой системы с журналированием только метаданных + надежность/транзакционность файловой системы с полным журналированием. И куча плюшек нахаляву типа возможности делать множественные снапшоты просто, быстро и не через зад. Ведь если старое состояние файла не дестроили - можно без проблем показать файл и в том виде каким он был до модификации. Просто проигнорив дозаписанное после интересующего момента. Оно же в сторонке лежит и забить на него проще простого :) Итого? CoW выглядит красиво и эффективно. Шаг вперед в технологиях, имхо. > Практический - снос крыши кэшу. Мсье дурак? Кэш не сохраняется при крахах, поэтому все что я говорил - это уже то что происходит при фактической записи на физический девайс, опосля всяких там кешей и прочая (логика журналинга насильно сбрасывает даже аппаратные кеши накопителей, если это не получается - беда, хана журналингу: толку от него не будет, т.к. журналинг полагается на фактическую запись в девайс нужных данных). Кэширование журнала или чего там еще - может только поднасрать. Извините, но если случится крах, данные для отката операции или ее доведения до конца брать надо с энергонезависимого накопителя, а?! Потому что кеш при потере питания или ребуте будет безжалостно просран (в крутых контроллерах поэтому бывают кеши с батарейками, но это отдельный вопрос). Итого? Чтобы журналирование сработало, данные должны быть физически записаны на накопитль, откуда их потом можно будет взять, правда? Ну и какой тогда кеш?! В случае честного журналинга и классической ФС - писать надо два раза. На физический носитель. Убедившись что он ни в коем случае не врет что записал данные. Сначала - в область журнала, потом в область основной файловой системы :). Как максимум читерят и не пишут 2 раза данные. Но при этом возникает возможность ситуации с полуперезаписанными файлами, особенно в случаях когда файл перезаписывается поверх самого себя своей же измененной версией. > NTFS журналит кластеры для отмены - Да щаззз. Насколько я знаю, нтфс в дефолтном виде журналит только метаданные. Поэтому ничто не мешает возникнуть ситуации когда облом случился при перезаписи файла, на середине операции. Файл при этом будет испорчен (и это проблема ВСЕХ файловых систем не делающих полное журналирование, а полное журналирование в классических ФС убивает скорость минимум в 2 раза, т.к. данные файла надо писать дважды). > в лучшем случае это быстрее CoW, в худшем медленнее. CoW обеспечивает скорость близкую к скорости без журналирования (как и "читерские" неполные журналирования только метаданных). Но зато "журналирует" еще и данные (независимо от того в какой момент случился крах, всегда есть старое состояние файла т.к. у CoW запись не деструктивна, в отличие от). Если на классической ФС журналить все (для аналогичного уровня неубиваемости данных при крахе) - скорость убьется минимум в 2 раза, т.к. в классическом дизайне журнала их надо писать 2 раза. Сперва в журнал, потом на диск. > Собсна все ответы есть у Руссиновича- что и как у NTFS. Есть. И в NTFS ничего такого супердупер интересного. Обычная такая ФС, по технологиям - уровня EXT3/XFS примерно. Только они тоже уже давно не новье и не круть. > Журнал у неё много старше всех ext-подобных. Но не менее бестолков - в общем то обычный классический журнал, более-менее :) > Она ей наслаждается. ...да, неспеша... :) > Сравнивать Fuse реализацию за три корки хлеба и реализацию > кода FS в ядре ? Это нереально. Так я про ядерную реализацию, если что. Она тоже скоростью не страдает. И фрагментируется весься даже. > FS 12-летней давности не может быть суперсовременной. Но остальные по прежнему чет > лепят и считают, что зоопарк FS у Linux уберсовременный. Из уберсовременных там Btrfs. Остальные - просто фс. Какойнить XFS или EXT4 - ничего шедеврального, но работают и довольно резво. А хоть и обладая озвученными минусами традиционых ФС, как то или журналинг только метаданных с риском получить полупереписанный файл, или миниум двукратная прсадка скорости записи на полное честное журналироание. > Да ни фига - отсталый он, все эти фишки тырятся у более современных > реализаций. Btrfs хорошо так потырило - все лучшие достижения из разных мест понадергали :). Да, они все по отдельности были и до. Но объединить все в 1 ФС почему-то никто до них не додумался. И, главное, майкрософту в ближайшие годы будет нечем ответить толком на подобные ФС. Их фс 15-летней древности - это не ответ.   > Слив № 10000 поздравляю с юбилеем. Поздравляю с сливом. Даже двукратным. Первый - про DFS, второй - про кэш vs журналирование.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	44. "Миша рыцарев тупит"	+/–
	Сообщение от achekalin (ok) on 12-Янв-11, 00:44
	Самое смешное, что в реальной жизни производительность FS особо не влияет: если уж ускорять, то не на десятки, а на тысячи процентов, а для этого конкретное приложение (а не ОС) применяет свое кеширование. А еще, добавлю, в реальной жизни FS выбирается один раз, в самом начале жизни проекта, и потом ни-ни тронуть ее до большого редизайна. Так что, извините, нормальный админ, при всей своей любви к плюшкам, вряд ли в серьезное применение выберет свежую сборку рейзера, например - от греха.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	48. "Миша рыцарев тупит"	+/–
	Сообщение от ананим on 12-Янв-11, 10:52
	рейзера - нет конечно. а вот с экст3 на экст4 переползти - легко. тоже можно с бтр, когда дорастет. они просто безболезненно конвертируются. а самое смешное не это, а то, что в реальной жизни админы бывают разные. и выбор фс гораздо менее критичен, чем выбор админа. это да.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	60. "Миша рыцарев тупит"	+/–
	Сообщение от User294 (ok) on 17-Янв-11, 10:12
	> для этого конкретное приложение (а не ОС) применяет свое кеширование. Есть одна "маленькая" проблема: несколько терабайтных накопителей ну никак не хотят втискиваться в оперативную память. И вообще, не все хотят ограничивать наборы данных размером оперативы. Поэтому всегда найдутся случаи когда скорость работы ФС - важна. Ну вот например, у мну на диске лежит ...цать исох с линуксом. Мне как, купить под их кеширование много-много-много оперативы? Или меня не должна волновать скорость их чтения/записи в случае когда они потребуются? oO Более того, Кэп намекает что есть очень массовый случай когда этот сценарий волнует всех: файлсервера, например. Что же там должно кешировать конкретное приложение? Все файлы с которыми юзеры работать могут? А вы сможете закешировать несколько терабайтных винчей, например, в оперативку то? На более-менее вменяемом железе по более-менее разумным ценам? :) Вообще, в идеале, все однажды должно прийти к скоростной и емкой энергонезависимой памяти, что-то типа RAM но не теряющей данные при отключении. Которая заменит диски и заметно упростит многие моменты, сделав ненужными многие традиционные сущности или сильно их упростив. Этот процесс идет, SSD+RAM по сути промежуточный этап на пути к нему. Для более нормального варианта этого самого пока-что не готовы технологии энергонезависимой памяти (они или в состоянии экспериментальных образцов, или относительно малоемких чипов, типа какогонить FRAM от Ramtron). Но это будет через хренадцать лет, а хранить данные нам нужно уже сегодня. Вон флеш-память например сделали еще в 80-х, но "диски" из нее всерьез стали собирать только через 20 с гаком лет.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	69. "Миша рыцарев тупит"	+/–
	Сообщение от iZEN (ok) on 17-Янв-11, 19:05
	>> для этого конкретное приложение (а не ОС) применяет свое кеширование. > Есть одна "маленькая" проблема: несколько терабайтных накопителей ну никак не хотят втискиваться > в оперативную память. И вообще, не все хотят ограничивать наборы данных > размером оперативы. Поэтому всегда найдутся случаи когда скорость работы ФС - > важна. Ну вот например, у мну на диске лежит ...цать исох > с линуксом. Мне как, купить под их кеширование много-много-много оперативы? Или > меня не должна волновать скорость их чтения/записи в случае когда они > потребуются? User294, не тупи, пожалуйста. Мне делается странно, когда ты говоришь подобные вещи. Кэшируются не файлы в памяти, а часто читаемые блоки данных из них. Во всех оперционках для продакшена есть алгоритмы оптимизации кэширования файлов. И даже Pentium 200 MMX с 64МБ ОЗУ в конце 1990-х мог спокойно "кэшировать" сетевой MS Office 97, когда 20 клиентов по 10Mbps коаксиалу ВНЕЗАПНО_ВСЕ_ВМЕСТЕ начинали с ним работать в режиме файл-сервера и, представь себе, ничего не тормозило.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	70. "Миша рыцарев тупит"	+/–
	Сообщение от User294 (ok) on 18-Янв-11, 15:51
	> User294, не тупи, пожалуйста. Мне делается странно, когда ты говоришь подобные вещи. > Кэшируются не файлы в памяти, а часто читаемые блоки данных из них. Вопрос только в том кто же у нас тупит. Во первых, на файлопомойке кеш может быть менее эффективен чем могло бы хотеться. Конечно, процент попаданий в кеш зависит от природы файлопомойки и активности юзеров но в общем случае можно заранее сказать что наборы данных в память заведомо не влезут целиком. Во вторых, если бы *ты* не *тупил*, то заметил бы что в исходном сообщении автор настаивал на том что приложение должно *своими* *силами* кешировать наборы данных. Нет, иногда приложение и правда знает лучше чем ОС что ему стоит кешировать, а что нет. Однако в случае файлсервера вообще сложно закешировать весь набор данных и еще сложнее угадать что потребуется пользователю через хренадцать минут. Ну я и привел автору пример когда его подход не сработает. Потому что автор вылез чуть ли не с панацеей. Ну вот пусть он и расскажет как в упомянутом случае производительность ФС пофигу. А если бы ты не был тормозом и имел хоть небольшой опыт и/или желание поэкспериментировать с системой и понять что она вообще может, то ты бы тогда попробовал отгружать юзвергам с файлопомойки мало-мальски жирные файлы и тогда с полоборота понял бы о какой ситуации я говорю. Под большой нагрузкой сие выглядит не очень прикольно: винчи разрываются пытаясь обслужить всех, гоняя головы туда-сюда, скорость чтения не ахти, а процент попаданий в кеш на чтение оставляет желать лучшего, т.к. юзеры вообще не обязаны хотеть одни и те же файлы и как оно там получится - полная лотерея зависящая от хотения юзеров. Понимаешь теперь, почему делают высокооборотистые диски для серверов, хоть они и менее емкие + иногда даже юзают SSD, хоть это и зверски дорого и не очень емко? ;) При том данную картинку совершенно не сложно пронаблюдать на практике и файловая система вполне может внести свой вклад в результат в таком случае. > Во всех оперционках для продакшена есть алгоритмы оптимизации кэширования файлов. И > даже Pentium 200 MMX с 64МБ ОЗУ Вот засунь туда ZFS и забенчмаркай. Можно сравнить с другими ФС. Ыхыхыхыхы, я хочу на это посмотреть. Да, уделай форониксов, покажи нам столь кульный бенч? Он конечно напрочь бесполезный, но забавный :) > представь себе, ничего не тормозило. А представь себе что 20 юзеров качают 20 iso-sized файлов, например. И каково будет серверу при этом. И, кстати, они совсем не обязаны быть одинаковыми. Случаи бывают разные, не так ли? :). А жирные файлы, включая и массовый параллельный доступ бывают нужны много где. Бэкапы. Виртуальные машины. Просто файлопомойки, видеосервера/рекордеры/чтотамеще. Как ты думаешь, ФС там не внесет свой вклад? А какого ж буя бенчи показывают разные результаты тогда? :)
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	74. "Миша рыцарев тупит"	+/–
	Сообщение от iZEN (ok) on 18-Янв-11, 17:39
	>> User294, не тупи, пожалуйста. Мне делается странно, когда ты говоришь подобные вещи. >> Кэшируются не файлы в памяти, а часто читаемые блоки данных из них. > Вопрос только в том кто же у нас тупит. Ты, конечно. Иди почитай Таненбаума, что ли, "Современные операционные системы". Узнай, как происходит кэширование файлов в памяти. > А представь себе что 20 юзеров качают 20 iso-sized файлов, например. И > каково будет серверу при этом. И, кстати, они совсем не обязаны > быть одинаковыми. Случаи бывают разные, не так ли? :). Да, случаи бывают разные. А то, что ты привёл, не попадает даже в 1% вариантов использования файлопомойки (NAS), а сразу подпадает под применение в таком случае SAN. > А жирные > файлы, включая и массовый параллельный доступ бывают нужны много где. Бэкапы. > Виртуальные машины. Просто файлопомойки, видеосервера/рекордеры/чтотамеще. Ты сейчас приводишь варианты использования для разного оборудования и организации кэширования. Очнись. Они для разных вещей предназначены. Нельзя одним NAS покрыть все возможные области хранения данных, хоть какая там ФС не стояла и хоть сколько ОЗУ там ни было! > Как ты думаешь, ФС там не внесет свой вклад? А какого ж буя бенчи показывают разные результаты тогда? :) Самое "узкое" место в компьютерной системе, отдающей данные, — это механика. Скорость механики определяет быстродействие системы хранения. Сколько ни повышай быстродействие контроллёра и интерфейсов жёстких диском, они от этого быстрее работать не станут. Так что единственное ускорение доступа это — кэширование часто востребуемых блоков данных с этих железок. ВСЁ!
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	75. "Миша рыцарев тупит"	+/–
	Сообщение от User294 (ok) on 18-Янв-11, 21:33
	> Ты, конечно. Иди почитай Таненбаума, что ли, "Современные операционные системы". Узнай, > как происходит кэширование файлов в памяти. А твоя мысль тут где? Или у тебя ЧСВ такое что ты возомнл что я не понимаю как работают кеш? Или посылка в ман - потому что своей мысли родить не удалось? :) > Да, случаи бывают разные. А то, что ты привёл, не попадает даже > в 1% вариантов использования файлопомойки (NAS), Откуда взята цифра в 1%? Ну, мне вот просто интерсно - с потолка, как обычно, или есть более серьезные источники? :) > а сразу подпадает под применение в таком случае SAN. А можно еще вместо мухобойки купить базуку. Ведь муху наверное тоже взрывом убьет до кучи, а там разберемся, да? :) > Очнись. Они для разных вещей предназначены. Нельзя одним NAS покрыть все > возможные области хранения данных, хоть какая там ФС не стояла и > хоть сколько ОЗУ там ни было! А я разве утверждал что 1 сервак должен покрывать все нужды? Кого-то нещадно глючит. Ну или процитируй где я утверждал что 1 сервера хватит всем. Тем не менее, если файловая система А в 2 раза быстрее файловой системы B при типовой для сервера нагрузке, есть надежды что удастся скостить затраты на одну и ту же задачу примерно в пару раз, если повезет. Что-нибудь не так? :) >> Как ты думаешь, ФС там не внесет свой вклад? А какого ж буя бенчи показывают разные результаты тогда? :) > Самое "узкое" место в компьютерной системе, отдающей данные, — это механика. Кэп, а вас не смущает тот факт что файловая система вполне может тут как подыграть, так и подгадить? Удобным или неудобным размещением структур данных, например. Алсо, как ни странно бывают случаи когда все может упереться и в саму логику ФС только так. Как ты думаешь, например, что быстрее: найти файл в линейном списке из 50 000 файлов, или по b-дереву шустренько лукапнуть? А то доступиться к всем 50 000 записей то - ой как не быстро будет :).А что если это надо часто и много? Дык файловая система никак не влияет? А чего ж тогда FAT аццки клинит при больших директориях? Может, из-за того что директории там представлены как линейные списки? :) > Скорость механики определяет быстродействие системы хранения. Ну да, расскажи это например FAT-у, легко тормозящему при работе с разлапистыми дирами даже на флеше. > станут. Так что единственное ускорение доступа это — кэширование часто востребуемых > блоков данных с этих железок. ВСЁ! Почему же? Как известно, жесткий диск читает/пишет данные довольно быстро. Если доступ последовательный. А вот пока диск позиционирует головы - он ессно не может читать/писать. Благородному дону не кажется что у файловой системы тут есть большое поле для деятельности? Как то постараться разложить данные и метаданные так, чтобы головы пришлось бы гонять поменьше, а непрерывно читать - побольше ;). Сие как бы одна из задач над которой упираются авторы файловых систем.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	17. "Миша рыцарев тупит"	+4 +/–
	Сообщение от zazik (ok) on 11-Янв-11, 14:16
	> и подобных отличаются от файловых систем майкрософта настолько же насколько боинг > отличается от дирижабля. Вы в вашем плане летать дирижаблями, если оно Я бы не стал так огульно охаивать дирижабли. Они ничуть не архаичны и очень удобны.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	49. "Миша рыцарев тупит"	+/–
	Сообщение от ананим on 12-Янв-11, 10:57
	угу. пассажирам цепелина посвящается.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	57. "Миша рыцарев тупит"	+/–
	Сообщение от zazik (ok) on 13-Янв-11, 09:55
	> угу. пассажирам цепелина посвящается. А теперь сравним количество авиа- и дирижаблекатастроф.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	66. "Миша рыцарев тупит"	+/–
	Сообщение от User294 (ok) on 17-Янв-11, 11:14
	> А теперь сравним количество авиа- и дирижаблекатастроф. Кэп намекает что когда самолетов было полторы штуки на всю планету, авиакатастрофы были редкими единичными случаями почему-то. Хотя конструкции самолетов тех времен особой надежностью не отличались. ЗЫЖ для пущей эпичности можно сравнить число ДТП с участием карет и автомобилей в 2000-2010 годах, например. Я даже результат скажу: по этому сравнению кареты получатся куда безопаснее чем даже самолеты, не говоря уж о автомобилях. К чему это я?  Может, к тому что оценка надежности имеет смысл в виде "число катастров деленное на число аппаратов в эксплуатации"? :) То-есть, если у аппарата вероятность поломки 0.01 за срок службы, если у вас всего 1 аппарат, он у вас скорее всего вообще не сломается и будет образцом надежности. А что если у вас 1000 аппаратов? Тогда вы можете ожидать что за срок службы сломается добрый десяток из них. Что, разумеется, вызовет вопросы о надежности. Следует ли отсюда что аппарат стал хуже только от того что его наштамповали 1000 раз? :)
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	61. "Миша рыцарев тупит"	+/–
	Сообщение от User294 (ok) on 17-Янв-11, 10:15
	> Они ничуть не архаичны и очень удобны. ...но практически все авиаперевозки совершают почему-то самолеты и вертолеты. Странно.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	62. "Миша рыцарев тупит"	+/–
	Сообщение от zazik (ok) on 17-Янв-11, 10:45
	>> Они ничуть не архаичны и очень удобны. > ...но практически все авиаперевозки совершают почему-то самолеты и вертолеты. Странно. ...но практически все десктопы под вендой почему-то. Странно.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	64. "Миша рыцарев тупит"	+/–
	Сообщение от User294 (ok) on 17-Янв-11, 11:00
	> ...но практически все десктопы под вендой почему-то. Странно. Линуксы я почему-то вижу явно чаще чем дирижабли. Странно :)
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	65. "Миша рыцарев тупит"	+/–
	Сообщение от zazik (ok) on 17-Янв-11, 11:08
	>> ...но практически все десктопы под вендой почему-то. Странно. > Линуксы я почему-то вижу явно чаще чем дирижабли. Странно :) Когда-то Линуксов было заметно меньше, чем сейчас :) Да и самолётостроительное лобби, видимо, оказалось сильнее дирижаблестроительного.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	67. "Миша рыцарев тупит"	+/–
	Сообщение от User294 (ok) on 17-Янв-11, 11:19
	> видимо, оказалось сильнее дирижаблестроительного. Мне кажется что лучше оказались для начала скорость, управляемость, особенно при наличии сильного ветра и бОльшая технологичность (например процедуры взлета/посадки, поддержания желаемого курса, его преодоление за предсказуемое время, etc). Недостатки есть у всех, но видимо данное сочетание параметров оказалось более оптимальным.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	68. "Миша рыцарев тупит"	+/–
	Сообщение от zazik (ok) on 17-Янв-11, 11:34
	>> видимо, оказалось сильнее дирижаблестроительного. > Мне кажется что лучше оказались для начала скорость, управляемость, особенно при наличии > сильного ветра и бОльшая технологичность (например процедуры взлета/посадки, поддержания > желаемого курса, его преодоление за предсказуемое время, etc). Недостатки есть у > всех, но видимо данное сочетание параметров оказалось более оптимальным. А особенно показатель выживаемости в авиа- и дирижаблекатастрофах, ага. Но ведь новых нарожают, значит и беспокоиться не о чем!
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	71. "Миша рыцарев тупит"	+/–
	Сообщение от User294 (ok) on 18-Янв-11, 16:11
	> А особенно показатель выживаемости в авиа- и дирижаблекатастрофах, ага. Ну, учитывая что дирижаблей в природе за всю историю человечества было не так уж много, а период активной эксплуатации был невелик, можно сказать что даже единичная катастрофа - уже приличный показатель опасности. Пруфлинк на тяжелую катастрофу с полным уничтожением аппарата, спецэффектами и кучей трупов? Пожалуйста: http://en.wikipedia.org/wiki/Hindenburg_disaster P.S. кстати кто там удивлялся нафига видео в вебе? Ну вот в этой статье например - документальные кадры. По-моему, выглядит вполне убедительно чтобы потерять веру в абсолютную безопасность этого вида транспорта (впрочем это же можно и для любого иного вида транспорта найти). > Но ведь новых нарожают, значит и беспокоиться не о чем! Но бездушная статистика тем не менее говорит что летать самолетом намного безопаснее чем например ездить на авто (куда более распостраненных чем дирижабли и перевозящих намного больше народа). Все-таки в силу суровости результатов авиакатастроф, там и меры по их предотвращению соответствующие. И именно эта причина может не позволить сказать что дирижабли - безопаснее: тут надо смотреть соотношение числа серьезных катастроф с числом судов в эксплуатации и время их эксплуатаии, ну и сравнивать вероятность отказа с катастрофическими последствиями в пересчете на единицу техники за, допустим, год эксплуатации. Или вероятность для 1 пассажира убиться в пересчете на километр или час перелета, например. Грубо говоря, это будут ваши шансы испытать острые ощущения после погрузки вашей тушки на борт посудины энного типа для достижения некоей цели, что и должно бы вас по идее интересовать. P.S. и вообще, наверное нам пора бы заканчивать с этим оффтопом :)
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	73. "Миша рыцарев тупит"	+/–
	Сообщение от zazik (ok) on 18-Янв-11, 17:13
	> Ну, учитывая что дирижаблей в природе за всю историю человечества было не > так уж много, а период активной эксплуатации был невелик, можно сказать > что даже единичная катастрофа - уже приличный показатель опасности. Пруфлинк на > тяжелую катастрофу с полным уничтожением аппарата, спецэффектами и кучей трупов? Пожалуйста: > http://en.wikipedia.org/wiki/Hindenburg_disaster Так там вся проблема в неготовности технологии на тот момент. Фанерные планеры тоже на раз разбивались/разваливались. А вот наполненные, например, гелием дирижабли при повреждении оболочки(если это не дыра в пол корпуса) просто бы медленно опустились на землю в отличие от срывающихся в штопор и разваливающихся при падении самолётов. Дирижаблям немного не повезло, вот и всё.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	76. "Миша рыцарев тупит"	+/–
	Сообщение от User294 (ok) on 18-Янв-11, 22:08
	> Дирижаблям немного не повезло, вот и всё. С устройством мира. Сущая фигня, право. Кто ж виноват что гелий, зараза, в пределах планеты Земля оказался редким и как следствие - дорогим?!
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	77. "Миша рыцарев тупит"	+/–
	Сообщение от zazik (ok) on 19-Янв-11, 09:15
	>> Дирижаблям немного не повезло, вот и всё. > С устройством мира. Сущая фигня, право. Кто ж виноват что гелий, зараза, > в пределах планеты Земля оказался редким и как следствие - дорогим?! Не такой уж дорогой. Просто на тот момент единственным крупным производителем гелия были США, а они не стремились поставлять свой гелий в ту же Германию. Сейчас бы с этим таких проблем не было, но ниша уже занята.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	13. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+1 +/–
	Сообщение от Зилибоба (ok) on 11-Янв-11, 14:01
	Милый, добрый человек... Я с вами согласен, не нужен этот зоопарк фс. Зоопарки вообще не нужны. Оставить одного правителя, одну страну и одну расу людей... По остальным пунктам все ровно, фс, прогрессируют, дистрибутивы все видят, Рейзер фс жива и прободлжает прогресировать, но пока в разрези чисто научного интререса... Да, производительностью отличается нтфс сильно, и по моим ощущениям не в лучшую сторону...
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	34. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	–1 +/–
	Сообщение от User294 (ok) on 11-Янв-11, 19:11
	> Да, производительностью отличается нтфс сильно, и по моим ощущениям не в лучшую > сторону... По моим наблюдениям он отличается склонностью к тормознутости и фрагментации.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	27. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	–1 +/–
	Сообщение от skybon (ok) on 11-Янв-11, 16:14
	Reiser4 медленно развивается из-за того, что её создатель Ханс Райзер отбывает 15-летний срок в американской тюрьме за убийство жены. А так пользуйтесь ext4. Эта новость для сисадминов, гиков (читай: красноглазиков) и всё.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

10. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
Сообщение от Nirnroot on 11-Янв-11, 13:40
Хм, интересно, во фрю перенесут? А то давно назрела необходимость заменить UFS2 чем-нибудь.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	12. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
	Сообщение от vasia911 on 11-Янв-11, 13:54
	А чем ZFS не замена ?
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	50. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
	Сообщение от ананим on 12-Янв-11, 11:19
	ну как чем? вон ниже пишут что если и замена, то сразу нужно менять на соляру. :D
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

11. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
Сообщение от Motif (ok) on 11-Янв-11, 13:41
А они стрекозу хотя бы на реальном железе запускали, или как обычно, в виртуалке?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	14. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	–1 +/–
	Сообщение от ufs on 11-Янв-11, 14:09
	Естественно, DfBSD не стоит на месте, как 2-3 года назад... Вот увидите, HAMMER FS будет "первой" FS ;-)
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	28. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
	Сообщение от Motif (ok) on 11-Янв-11, 16:56
	> Естественно, DfBSD не стоит на месте, как 2-3 года назад... Вот увидите, > HAMMER FS будет "первой" FS ;-) Причем здесь DfBSD? Имеется ввиду Похороникс. Это одна машина с Убунтой, всё остальное - виртуалки.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	23. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
	Сообщение от non anon on 11-Янв-11, 15:23
	> А они стрекозу хотя бы на реальном железе запускали, или как обычно, в виртуалке? Похороникс-то? Нет, конечно, он боится на свой комп что-нибудь кроме убунты ставить. Видимо, как обычно, в виртуалбоксе.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	29. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
	Сообщение от Motif (ok) on 11-Янв-11, 16:56
	>> А они стрекозу хотя бы на реальном железе запускали, или как обычно, в виртуалке? > Похороникс-то? Нет, конечно, он боится на свой комп что-нибудь кроме убунты ставить. > Видимо, как обычно, в виртуалбоксе. Похоже на то.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	38. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+1 +/–
	Сообщение от Stax (ok) on 11-Янв-11, 20:06
	Вроде в этот раз нативно, без виртуалок (кстати у них вроде обычно kvm, а не бокс). Но (!) они полностью вырубили поддержку SMP на линуксе и PC-BSD, мотивируя тем, что DragonFly не поддерживает, поэтому так будет честнее. Это даже комментировать не хочется.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

18. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+1 +/–
Сообщение от Resonance (ok) on 11-Янв-11, 14:25
по тестам ext4 самая лучшая FS :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	19. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
	Сообщение от Аноним (??) on 11-Янв-11, 14:30
	и самая стабильная, ага. мы в курсе.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	20. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
	Сообщение от Resonance (ok) on 11-Янв-11, 14:39
	> и самая стабильная, ага. мы в курсе. ну я не жалуюсь :)
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	35. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	–1 +/–
	Сообщение от User294 (ok) on 11-Янв-11, 19:18
	> и самая стабильная, ага. мы в курсе. Вполне нормальная ФС. У мну уже есть кучка томов в EXT4. Ессно юзаются с ядрами .32 и выше, до .32 ядра с EXT4 я предпочитал не связывтаться глядя на баги и т.п.. А вот с тех пор никаких особых грабель не узрел и не имел никаких крупных проблем. Надежность - на уровне любой иной классической журналируемой ФС, имхо.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

21. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
Сообщение от Аноним (??) on 11-Янв-11, 14:48
> дедублицирование И как только над этим словом не издевались. :((((
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

25. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
Сообщение от iZEN (ok) on 11-Янв-11, 15:45
Ни за что не поверю, что на тесте "Threaded I/O Tester Random Write" ZFS в 25 раз быстрее UFS(2? SoftUpdates?) на PC-BSD. Что-то тут нечисто.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	30. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
	Сообщение от Анон on 11-Янв-11, 17:08
	> Ни за что не поверю, что на тесте "Threaded I/O Tester Random > Write" ZFS в 25 раз быстрее UFS(2? SoftUpdates?) на PC-BSD. Что-то > тут нечисто. Как всегда, сравнение теплого с мягким, к тому же взятым из коробки. То, что разноспецифичные ФС можно всегда экстремально заточить под специфический тест/задачу как всегда выплескивается с водой, а дилетанты как бы верят на слово.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	31. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
	Сообщение от Анон on 11-Янв-11, 17:09
	>> Ни за что не поверю, что на тесте "Threaded I/O Tester Random >> Write" ZFS в 25 раз быстрее UFS(2? SoftUpdates?) на PC-BSD. Что-то >> тут нечисто. > Как всегда, сравнение теплого с мягким, к тому же взятым из коробки. > То, что разноспецифичные ФС можно всегда экстремально заточить под специфический тест/задачу > как всегда выплескивается с водой, а дилетанты как бы верят на > слово. И это не вопрос веры. Бери и сам тестируй, делов-то.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	32. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
	Сообщение от letsmac (ok) on 11-Янв-11, 17:17
	Нечисто тут ИМХО с реализацией кэширования записи. Если тест постоянно валит что-то вроде FlushBuffer - тут уже дело в подстройке под такое поведение.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

37. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
Сообщение от Stax (ok) on 11-Янв-11, 20:04
Нет, ну разве не маразм - они для теста zfs берут bsd.. В то время как в бенчмарках этот специфический порт zfs проигрывает по скорости оригинальному zfs весьма и весьма. И ладно бы можно было сказать "тестируем все на одной системе", так нет же - они берут два разных bsd и еще и линукс впридачу, а потом все в куче сравнивают. А вот нормальный zfs на оупенсолярке или нексенте взять не судьба была? Ну и "As a result, we used the stock DragonFlyBSD UP kernel and when benchmarking PC-BSD and Ubuntu we disabled the SMP support there." это тоже ничего себе шаг. Типа, так как dragonfly не поддерживает SMP, давайте и на линуксе его зарежем, чтобы "честнее" сравнивать? В общем фороникс такой фороникс, от этой синтетики до реальных ситуаций пропасть.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	42. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	–1 +/–
	Сообщение от User294 (ok) on 11-Янв-11, 21:12
	> Нет, ну разве не маразм - они для теста zfs берут bsd.. > В то время как в бенчмарках этот специфический порт zfs проигрывает > по скорости оригинальному zfs весьма и весьма. Тем не менее, общие свойства ФС из их бенчей - понятны. В смысле, у них есть и бенчи где был опенсолярис. Думаете, там ZFS выступал принципиально иначе? А фиг, сильные и слабые стороны были в том же духе. PostMark он там точно так же с треском слил, например. И?
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	52. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	–2 +/–
	Сообщение от Анон on 12-Янв-11, 15:03
	>> Нет, ну разве не маразм - они для теста zfs берут bsd.. >> В то время как в бенчмарках этот специфический порт zfs проигрывает >> по скорости оригинальному zfs весьма и весьма. > Тем не менее, общие свойства ФС из их бенчей - понятны. В > смысле, у них есть и бенчи где был опенсолярис. Думаете, там > ZFS выступал принципиально иначе? А фиг, сильные и слабые стороны были > в том же духе. PostMark он там точно так же с > треском слил, например. И? А ты сам-то, дорогой, устриц кушал? В смысле - боевые системы на ZFS гонял, не? Тогда послушай тех, кто их ел. Бенчи - они вообще нихрена не показатель. Есть реальный перфоманс на реальных системах и задачах. И вот лично мне - он актуальней любых тестов в чьем бы то ни было исполнении. У меня после перевода на ZFS боевого сервера в два раза уменьшился отклик. А у вас?
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	53. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
	Сообщение от ананим on 12-Янв-11, 15:08
	ты своими устрицами уже весь форум загадил. зыж в общем - где? когда? какая нагрузка? что за организация? что ты подразумевашь под откликом? методика тестирования? и пр. - иначе в сад.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	54. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+1 +/–
	Сообщение от Stax (ok) on 12-Янв-11, 19:49
	Представь себе, да. Работал с разными солярками и поднимал решения на zfs. Везде были одни преимущества и увеличения скорости. Хотя особенностей своих куча, и далеко не выходит любую железку, которая работала в других условиях перевести на солярку с zfs, даже если с точки зрения приложений это возможно - чтобы zfs работала как надо, к ней нужно подходить правильно. zfs имеет массу преимуществ по возможностям и производительности в частности, при переводе задач на виртуализированные серверы с zfs-решением в качестве SAN, или при переходе от групп виртуалок, использующих локальные диски к централизованному хранению. Так же zfs прекрасно работает в NAS-сервере организаций, как для решений "офисная файлопомойка" так и для решений бэкапа. Только в зависимости от нагрузки нужно правильно выбирать и настраивать железо, а не думать, что если взять сервкак с пачкой sata и взгромоздить нексенту и расшарить zfs, то настанет рулез. Если нужно гонять на zfs БД, то все еще сложнее. А говорить "в два раза отклик" вообще ни о чем. По сравнению с чем? В какой задаче? zfs на какой ОС? SAN, NAS или локальная?
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	55. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	–1 +/–
	Сообщение от Анон on 13-Янв-11, 07:48
	>[оверквотинг удален] > переходе от групп виртуалок, использующих локальные диски к централизованному хранению. > Так же zfs прекрасно работает в NAS-сервере организаций, как для решений > "офисная файлопомойка" так и для решений бэкапа. Только в зависимости от > нагрузки нужно правильно выбирать и настраивать железо, а не думать, что > если взять сервкак с пачкой sata и взгромоздить нексенту и расшарить > zfs, то настанет рулез. Если нужно гонять на zfs БД, то > все еще сложнее. > А говорить "в два раза отклик" вообще ни о чем. По сравнению > с чем? В какой задаче? zfs на какой ОС? SAN, NAS > или локальная? По сравнению с UFS под Oracle 10 g R2, локальная, система с вебфронтом на основе БД, Солярис 10 10/09.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	58. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
	Сообщение от iZEN (ok) on 13-Янв-11, 10:25
	>> А говорить "в два раза отклик" вообще ни о чем. По сравнению >> с чем? В какой задаче? zfs на какой ОС? SAN, NAS >> или локальная? > По сравнению с UFS под Oracle 10 g R2, локальная, система с > вебфронтом на основе БД, Солярис 10 10/09. А, ну да, вы не пробовали UFS2. по сравнению с ней UFS1 действительно тормоз. Кстати, на десктопе UFS2 опережает по скорости записи и отклику ZFS примерно на 10-15%.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	56. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	–1 +/–
	Сообщение от Анон on 13-Янв-11, 07:56
	>[оверквотинг удален] > подходить правильно. > zfs имеет массу преимуществ по возможностям и производительности в частности, при переводе > задач на виртуализированные серверы с zfs-решением в качестве SAN, или при > переходе от групп виртуалок, использующих локальные диски к централизованному хранению. > Так же zfs прекрасно работает в NAS-сервере организаций, как для решений > "офисная файлопомойка" так и для решений бэкапа. Только в зависимости от > нагрузки нужно правильно выбирать и настраивать железо, а не думать, что > если взять сервкак с пачкой sata и взгромоздить нексенту и расшарить > zfs, то настанет рулез. Если нужно гонять на zfs БД, то > все еще сложнее. Сложнее для кого? Достаточно рекомендации выполнить вот эти: http://www.solarisinternals.com/wiki/index.php/ZFS_for_Datab... Что до Оракла, то там есть свой мануал с рекомендациями. Которым достаточно скрупулезно последовать. Нашли блин проблему для грамотного DBA...
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	59. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
	Сообщение от Sergey (??) on 13-Янв-11, 14:30
	> А ты сам-то, дорогой, устриц кушал? В смысле - боевые системы на > ZFS гонял, не? Тогда послушай тех, кто их ел. Покажите, пожалуйста, хоть одну крупную инсталляцию ZFS. Не в специализированных железках типа OpenStorage и не местечковых конторках а-ля Horh&Hoof Ink. с 3 серверами и десятком пользователей.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	63. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
	Сообщение от User294 (ok) on 17-Янв-11, 10:49
	> А ты сам-то, дорогой, устриц кушал? В смысле - боевые системы на > ZFS гонял, не? Тогда послушай тех, кто их ел. Сильно не гонял, только слегка видел. Как-то не хоется возиться с ос где оно есть в продакшновом состоянии, уж извините. И чего вас слушать то? Вы готовы сказать что-то дельное и интересное? Гнутье пальцев и бряцание причандалами - неинтересно. Бенчмарки дают хотя-бы пищу для размышлений. Они не истина в последней инстанции и вообще показывают лишь соотношение сил на конкретном хардваре, в конкретных нагрузках. При этом совсем не исключено что изменение хардвара или нагрузок может поставить все с ног на голову. И тем не менее, даже это позволяет понять у кого какие особенности, сильные и слабые места у кого есть. Не всегда точно и объективно. Но это все-таки лучше чем совсем никак. > Бенчи - они вообще нихрена не показатель. Бенчи всего лишь могут показать сильные и слабые стороны той или иной ФС, с чем она справляется лучше а с чем хуже при энных условиях. В лучшем случае может получиться понять сильные и слабые стороны тех или иных инженерных решений при испытании конструкции уже на практике. > Есть реальный перфоманс на реальных системах и задачах. Спасибо, Кэп! Что бы я без вас делал? Кстати, бенчмарки меряют некий перфоманс на неких задачах. Возможно даже для кого-то эти задачи будут реальными. Вы об этом не думали? Да, бенчмарки не гарантируют вам что вы увидите точно такие же соотношения на ВАШЕМ железе и задачах, если вы об этом. И чего? :) > И вот лично мне - он актуальней любых тестов в чьем бы то ни было исполнении. А ответите на один интересный вопрос, сэр? Если совсем проигнорировать все бенчмарки, то откуда брать информацию о сильных и слабых сторонах дизайнов разныз файловых систем? Ну не из маркетоидного же бреда, правда? :) > У меня после перевода на ZFS боевого сервера (отбирая у прошлого оратора фуражку).Поработаю ка и я Кэпом, чтоли? :) 1. Кэп намекает, что сервера бывают РАЗНЫЕ. С чертовски разными задачами. Разными конфигурациями, разным соотношением мощности различных компонентов и прочая. И то что хорошо для сервера грузящего "исошники" бочками - не обязательно хорошо для серверов БД или почтовиков, например. 2. Кэп намекает что вы забыли уточнить что на что вы заменили, для начала. 3. Кэп намекает что вы не предоставили никаких бенчмарков и сравнить столько же ФС сколько сравнил фороникс. Кэп считает что ваших данных недостаточно для того чтобы сделать далеко идущие выводы или сравнить разные файловые системы, не говоря уж о понимании свойств. > в два раза уменьшился отклик. Невольно вспомнился анекдот, позволю себе префразировать: - ZFS лучше чем остальные! - Чем?! - Чем остальные! > А у вас? Да, да, знаем. "На 30% больше свежести" (c) реклама :))). Только вот ТЕХНИЧЕСКИХ аргументов, достаточных для понимания того что и как - я у вас не вижу. У вас с телерекламерами есть кое что общее. Вы, как и они, не указали как вы получили ваши "в 2 раза" с достаточной детализацией, чтобы можно было хотя-бы грубо понять что произошло и почему оно - вот так. Совсем как рекламеры с их "на 30% больше свежести" не указывают как именно они там замеряли свои проценты свежести :). Не хочу ничего сказать, но при таком подходе - даже чудикам из фороникса доверия в разы больше. Они по крайней мере описывают что и как мерялось. Хоть я и не понимаю некоторые их бенчмарки или нахожу некоторые их бенчмарки странными (например, похоже что их бенчмарки подыгрывают ФС со включенным сжатием, при том реальные данные скорее всего будут подыгрывать несколько меньше бенчмарковых).
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	72. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
	Сообщение от Аноним (??) on 18-Янв-11, 16:54
	>[оверквотинг удален] > Сильно не гонял, только слегка видел. Как-то не хоется возиться с ос > где оно есть в продакшновом состоянии, уж извините. И чего вас > слушать то? Вы готовы сказать что-то дельное и интересное? Гнутье пальцев > и бряцание причандалами - неинтересно. Бенчмарки дают хотя-бы пищу для размышлений. > Они не истина в последней инстанции и вообще показывают лишь соотношение > сил на конкретном хардваре, в конкретных нагрузках. При этом совсем не > исключено что изменение хардвара или нагрузок может поставить все с ног > на голову. И тем не менее, даже это позволяет понять у > кого какие особенности, сильные и слабые места у кого есть. Не > всегда точно и объективно. Но это все-таки лучше чем совсем никак. Я объясню, почему я на абстрактные бенчи класть хотел. Однажды в моей практике стоял ребром выбор платформы. Либо АМД с Оптероном, либо UltraSPARC. Была реальная задача, взятая клоном с боевого сервера. Была поставлена на Ниагару, были сделаны все тюнинги - рекомендованные двумя основными вендорами + собственный немаленький опыт профессионального тюнинга. И Ниагара, хваленая и прославленная, слила по тяжелой, всухую, в идентичных условиях, АМД. Всухую - это значит, что разбег по скорости отклика на основном функционале был более, чем в четыре раза. Опаньки? >[оверквотинг удален] > ФС, с чем она справляется лучше а с чем хуже при > энных условиях. В лучшем случае может получиться понять сильные и слабые > стороны тех или иных инженерных решений при испытании конструкции уже на > практике. >> Есть реальный перфоманс на реальных системах и задачах. > Спасибо, Кэп! Что бы я без вас делал? Кстати, бенчмарки меряют некий > перфоманс на неких задачах. Возможно даже для кого-то эти задачи будут > реальными. Вы об этом не думали? Да, бенчмарки не гарантируют вам > что вы увидите точно такие же соотношения на ВАШЕМ железе и > задачах, если вы об этом. И чего? :) И ничего. Сам на все ответил. И зачем они тогда? >> И вот лично мне - он актуальней любых тестов в чьем бы то ни было исполнении. > А ответите на один интересный вопрос, сэр? Если совсем проигнорировать все бенчмарки, > то откуда брать информацию о сильных и слабых сторонах дизайнов разныз > файловых систем? Ну не из маркетоидного же бреда, правда? :) Лично я - когда вопрос стоит таким образом - беру и разворачиваю демо-сцену. Загоняю туда реальную систему и гоняю ее до умопомрачения. Личные тесты. Ничего большего. И все вижу сразу, что где и почем. >> У меня после перевода на ZFS боевого сервера > (отбирая у прошлого оратора фуражку).Поработаю ка и я Кэпом, чтоли? :) > 1. Кэп намекает, что сервера бывают РАЗНЫЕ. С чертовски разными задачами. Разными > конфигурациями, разным соотношением мощности различных компонентов и прочая. И то что > хорошо для сервера грузящего "исошники" бочками - не обязательно хорошо для > серверов БД или почтовиков, например. > 2. Кэп намекает что вы забыли уточнить что на что вы заменили, > для начала. > 3. Кэп намекает что вы не предоставили никаких бенчмарков и сравнить столько > же ФС сколько сравнил фороникс. Я не занимаюсь бенчмарками. Для меня - и моего прямого руководства - результаты, полученные лично мной на моих серверах и моих задачах - единственный критерий принятия решения. Сравнивать десятки ФС - не моя работа. Моя работа - выжимать из моей платформы максимум. Моя платформа - исторически и по объективным показателям - Солярис на ZFS. В течение последних 14 лет. Еще вопросы? > Кэп считает что ваших данных недостаточно для того чтобы сделать далеко идущие > выводы или сравнить разные файловые системы, не говоря уж о понимании > свойств. О том, как лично я и мои ЛПР делаем выводы - читай выше. О понимании помолчим. Я знаю ZFS изнутри. На уровне сорцов. А вы? >> в два раза уменьшился отклик. > Невольно вспомнился анекдот, позволю себе префразировать: > - ZFS лучше чем остальные! > - Чем?! > - Чем остальные! Истинно так. При хорошей прокладке между консолью и креслом. >[оверквотинг удален] > "в 2 раза" с достаточной детализацией, чтобы можно было хотя-бы грубо > понять что произошло и почему оно - вот так. Совсем как > рекламеры с их "на 30% больше свежести" не указывают как именно > они там замеряли свои проценты свежести :). Не хочу ничего сказать, > но при таком подходе - даже чудикам из фороникса доверия в > разы больше. Они по крайней мере описывают что и как мерялось. > Хоть я и не понимаю некоторые их бенчмарки или нахожу некоторые > их бенчмарки странными (например, похоже что их бенчмарки подыгрывают ФС со > включенным сжатием, при том реальные данные скорее всего будут подыгрывать несколько > меньше бенчмарковых). Учебный класс по администрированию ZFS находится не здесь. Научить, как готовить кошек - могу только за деньги. :)
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	78. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
	Сообщение от User294 (ok) on 20-Янв-11, 18:01
	> Я объясню, почему я на абстрактные бенчи класть хотел. Кладите наздоровье. А я все-таки предпочитаю смотреть что на них есть для понимания свойств и проблем различных дизайнов ФС и прочая. > значит, что разбег по скорости отклика на основном функционале был более, > чем в четыре раза. Я рад за вас. > Опаньки? Что - опаньки? Нормальный специалист, зная задачу, ее типовые операции и сильные и слабые стороны железа и технологий, по хорошему имхо должен бы быть в состоянии прикинуть что приблизительно будет БЕЗ вбубухивания денег в реальное железо для постановки натурных экспериментов и слегка до этого.   >> что вы увидите точно такие же соотношения на ВАШЕМ железе и >> задачах, если вы об этом. И чего? :) > И ничего. Сам на все ответил. И зачем они тогда? Ну, для лично меня они полезны тем что позволяют составить впечатление о свойствах тех или иных ФС и их соотношениях в неких условиях. Потенциально понимая сильные и слабые стороны той или иной ФС. При этом можно как минимум грубо прикинуть что будет себя вести лучше а что хуже на той или иной задаче. > Лично я - когда вопрос стоит таким образом - беру и разворачиваю демо-сцену. Это, разумеется, наиболее реалистично, но как бы денег стоит и времени требует. Кроме того - хорошо бы понимать чего разворачивать, и что будет оптимально для той или иной задачи. Бенчи в этом плане позовляют заиметь некое представление о том какие вообще слабые и сильные стороны есть у разных ФС. Например, XFS хорошо работает с большими файлами но не особо хорошо с мелкими. Это не слишком меняется по конфигурациям (хотя и меняется по версиям ядра - в новых версиях ядра сие подтянули, но все-таки). > Загоняю туда реальную систему и гоняю ее до умопомрачения. Личные > тесты. Ничего большего. И все вижу сразу, что где и почем. До умопомрачения? Спасибо. А я предпочитаю сперва прикинуть хотя-бы в какую сторону стоит идти. Мне нравится понимать что, как и почему происходит, и почему это происходит именно так. Я не собираюсь быть тупой исполнительной обезьяной. > Я не занимаюсь бенчмарками. Для меня - и моего прямого руководства - > результаты, полученные лично мной на моих серверах и моих задачах - > единственный критерий принятия решения. Ага, все у вас просто что писец. Взять тот же ваш пример с амд и ниагарой. Представим себе что повезло чуть меньше. И у нас ЕЩЕ НЕТ ни сервака на ниагаре, ни сервака на амд. А решение принять надо, и надо что-то купить, чтобы было. Хорошо бы не промазать с выбором, разумеется. Вы бы как поступили в такой ситуации? oO > Сравнивать десятки ФС - не моя работа. Тогда как вы узнаете что ваше решение - хорошее? Узнать об этом можно только сравнив с другими. > Моя работа - выжимать из моей платформы максимум. Моя платформа - > исторически и по объективным показателям - Солярис на ZFS. В течение > последних 14 лет. Еще вопросы? Нет, вопросов больше не имею. Спасибо что подтвердили подозрения. Видимо вы уперты рогом в солярис и ZFS, а потому в принципе не способны представить себе такую вещь как сравнение разных ФС. Поэтому даже если другая файловая система сможет вдвое лучше, вы на это плюнете и будете юзать солярис и ZFS, даже если вашему шефу и придется распереться на вдвое большее количество серверов, вбухав на вас в 2 раза больше денег. Поэтому все что вы можете - это вопить о том как солярис и ZFS круты. Другого то вы все-равно видимо не умеете, бенчмарков не проводили, ну и все такое. Я допускаю что вы научились тюнить вашу систему (чтобы за 14 лет этому не научиться - надо быть совсем уж деревянным). Однако у любого инструмента есть сильные и слабые стороны. И если инструмент в чем-то не силен, совсем не факт что тюнингом это исправится. Я теперь понимаю ваш бухтеж про бенчи. Ведь они наглядно демонстрируют что для некоторых ворклоадов ZFS совсем не подарок. Скорее всего вы попросту избегаете такие задачи, или решаете их неоптимально. Бывает :) > О том, как лично я и мои ЛПР делаем выводы - читай выше. > О понимании помолчим. Я знаю ZFS изнутри. На уровне сорцов. А вы? Вы скорее всего знаете его лучше меня. С чем я вас и поздравляю. Я всего лишь вкуривал (ну, пытался) в базовые структуры оного и т.п. чисто из интереса. Чтобы понять что оно из себя представляет в общих чертах. Немного посмотреть на сорсы пришлось, но не более того. Вы в вашем праве считать данный дизайн панацеей и пхать в каждую дырку. Все равно вам больше пихать толком нечего. Ну не UFS же ископаемый, так? Это не по сравнению с ним ли у вас там латентность в разы упала? Похвастайтесь уж? А для меня это всего лишь еще один дизайнов ФС, я не собираюсь его рассматривать как The One and The only, единственно правильный и панацею на все про все. Потому что я отлично усвоил что панацеи не бывает, а у любого дизайна ФС можно найти слабое место на котором какая-то иная ФС его прилично обойдет. В силу того что ее особенности устройства дисковых структур и прочая - лучше легли на конкретную задачу, например.   >> - ZFS лучше чем остальные! >> - Чем?! >> - Чем остальные! > Истинно так. При хорошей прокладке между консолью и креслом. Угу, конечно. Вас послушать так это прямо грааль какой-то. Заруливает всех в хлам на любых ворклоадах и на любом железе, невзирая на то что батлнеки разные, структуры разные и прочая. Правда вот я вижу одно упущеньице: а СРАВНИВАЛОСЬ то с чем? Ведь все познается в сравнении. Судя по всему - ни с чем особо. В лучшем случае поди с каким-то ископаемым хламом типа UFS. Подтверждаете мои подозрения на этот счет? А то я грешным делом подозреваю что вы рассказали о улучшении латентности vs что-то такое, т.е. ископаемое и не развиваемое напрочь. Форониксы же сравнивают всей кучей. Не делая из ZFS фетиш. Да, не идеально. Да, не тюня все и вся. И все-таки даже их бенчмарки позволяют заиметь некое представление о свойствах ФС и их соотношениях. То что вам это знание бесполезно т.к. вы уперты рогом в соляру и выбирать вам тупо не из чего - так это не мои проблемы. А я вот с интересом посмотрю кто как в дефолтовой конфиге соотнсится. Если ФС типа А лучше ФС типа Б в 10 раз под некоей нагрузкой, логично пытаться выжать что-то из ФС типа А, потому что этот путь выглядит явно перспективнее и скорее всего позволит или поиметь меньше геморроя или получить заведомо более хороший результат. >> включенным сжатием, при том реальные данные скорее всего будут подыгрывать несколько >> меньше бенчмарковых). > Учебный класс по администрированию ZFS находится не здесь. Так мне и не нужны ваши классы. А нафига? Копаться в древнем *никсе с кучей фирменных проблем и жлобским вендором - ваше право как старого зубра со стажем, который нашел свю гавань и уже не может или не хочет ничего нового знать, но еще не просрал старые умения. А мне такое "счастье" никуда не уперлось. Потому что у меня какие-то более другие понятия о этом самом счастье. И мне не светит перспектива заложиться на одну жлобскую контору. Уже назакладывался раньше, так что второй раз на те же грабли - ни за что на свете. > Научить, как готовить кошек - могу только за деньги. :) Боюсь, не будет мне интересно ваше обучение. Я поучусь готовке кошек сам, или у других, и это будут кошки более других пород. Так что не получится у вас подзаработать. Максимум что вам светит - немного мне вправить мозг, если мое понимание устройства ZFS слишком кривое. К сожалению оплату за это обещать не могу, только fun от макания меня в мои оплошности как масксимум. Но идеальное знание ZFS мне в принципе и не требуется. Скорее, я хочу просто понимать какие в природе бывают дизайны ФС и какие кто инженерные решения применяет в ФС, чем они хороши и плохи. Этакий научный интерес, чисто для души. Упражнение для мозгов чтобы они не ржавели, чтоли.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

40. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
Сообщение от VKraft on 11-Янв-11, 20:47
ещё в школе учитель математики говорила: "песок с дровами не сравнивать и не складывать"
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

47. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
Сообщение от Аноним (??) on 12-Янв-11, 10:50
Интересно, зачем нужна zfs, btrfs, ext4 и hammer? Это для обычного компа или сервера? Для каких задач актуальны эти замечательные ФС?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

79. "Релиз ФС Hammer 5. Сравнение производительности Hammer, ZFS,..."	+/–
Сообщение от Papa Carlo on 24-Янв-11, 17:46
Битва началась? Семь тестов шести файловых систем под тремя операционками: чтение, запись, архивация 2GB, PostMark v1.51, распаковка ядра Linux-2.6.32.tar.bz2, Threaded I/O Tester v0.3.3 последовательная запись - 64MB на каждую из 4-х нитей и Threaded I/O Tester v0.3.3 случайная запись - 64MB на каждую из 4-х нитей. В результате:          +     +     -     +     -     +     + Hammer DragonFly 34140      483     29.83      389     18.69     47.80     10.96 UFS DragonFly     163640      65      ?..      76     50.09     56.87      3.34 UFS PC-BSD     272913      206     27.12      45     27.49     30.28      1.99 ZFS PC-BSD     178291      61     36.43      510     15.58     40.34     49.62 EXT3 Ubuntu     252700     1118     17.85      666     14.52     42.58      2.77 EXT4 Ubuntu     283114      862     17.83     2137     15.57     53.98      3.04 Btrfs Ubuntu     280463      559     17.83     1800     17.16     53.96     33.16 "+" - чем больше, тем лучше. "-" - чем меньше, тем лучше. В процентах к лучшему результату: Hammer DragonFly 12%      43%      60%      16%      78%      84%      22% UFS DragonFly      58%      6%     ?..      4%      29%     100%      7% UFS PC-BSD      96%      18%      66%      2%      53%      53%      4% ZFS PC-BSD      63%      5%      49%      24%      93%      71%     100% EXT3 Ubuntu      89%     100%     100%      31%     100%      75%      6% EXT4 Ubuntu     100%      77%     100%     100%      93%      95%      6% Btrfs Ubuntu      99%      50%     100%      84%      85%      95%      67% В третьем тесте (Gzip сжатие 2GB) DragonFly существенно улучшает свои результаты, но Michael Larabel это так не интересно, что он даже не пишет результат UFS DragonFly. Остаётся только гадать, какой процент от лучшего результата набрала UFS DragonFly? Допустим, 95%. Почему нет? В шестом тесте UFS DragonFly была лучшей. Тогда итог будет таким: Hammer DragonFly 54% UFS DragonFly      52% UFS PC-BSD      50% ZFS PC-BSD      70% EXT3 Ubuntu      86% EXT4 Ubuntu      98% Btrfs Ubuntu      100% С практической точки зрения, вывод ясен: Ubuntu - рулез, DragonFly - отстой. Но, с точки зрения тестирования, совершенно неясно кто выиграл: Ubuntu или Btrfs? И мне сильно не нравится отсутствие результата UFS DragonFly в третьем тесте. Если Michael Larabel так относится к результатам, как же он тестировал? Из обсуждения на http://phoronix.com/forums/showthread.php?28216-Can-DragonFl... (оно короткое, 3 страницы): "Что-то серьезно не в порядке с Threaded I/O Tester. Просто никак не возможно, что ZFS стал писать быстрее при переходе от линейной к случайной записи, особенно если учесть, что все, и HAMMER и Btrfs, снизилось на порядок. Вы уверены, что результат не должен быть 4,96? К счастью, я знаком с внутренностями UFS, ZFS и HAMMER. HAMMER "log structured" таким же образом, как ZFS. Существование "log structured" ни как не объясняет повышение в производительности что видно между последние две графы." "...была ли система установлена в режиме AHCI или нет (AHCI драйвер стрекозы гораздо лучше, чем его водитель ATA)" "В реальной системе, где производительность вопросы вы будете иметь вторичные системы хранения, такие как небольшой SSD, и в DragonFly установка SSD с его swapcache для кэширования файловой системы мета-данных, чтобы согласиться стороны медленнее "нормальных" 1-3 Тб HD (S) любопытно, что Hammer настроен для. Файловая система тестирования на ноутбуке немного оксюморон с 99,999%, что вы будете делать нормально будет сохраняться в памяти все равно и файловая система будет иметь никакого значения." "То же самое много людей наблюдали в прошлом: ZFS мошенничества. Это кэш много, даже тогда, когда сказали не делать этого, и flushes позже, но сразу же возвращается. Если вы бежите из кэша, ZFS будет трэш-диск на века, но до этого момента ZFS бенчмаркинг сообщит удивительные номера." Если выкинуть третий и седьмой тесты как некорректные, то получим: Hammer DragonFly 50% UFS DragonFly      42% UFS PC-BSD      48% ZFS PC-BSD      55% EXT3 Ubuntu      85% EXT4 Ubuntu     100% Btrfs Ubuntu      89% Вопрос остаётся: Кто выиграл: Ubuntu или EXT4? И почему?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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