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

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

"Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
Сообщение от opennews (??) on 19-Сен-12, 13:02
Представлен (https://groups.google.com/a/zfsonlinux.org/forum/?fromgroups...) новый экспериментальный выпуск  модуля для ядра Linux с поддержкой ZFS - zfsonlinux 0.6.0-rc11 (http://zfsonlinux.org/). Несмотря на официальный статус экспериментальной разработки, пакет ZFSonLinux достаточно стабилен для использования энтузиастами. Кроме того, модуль ZFSonLinux уже входит в состав дистрибутивов Gentoo и Sabayon Linux. Представленная в ZFSonLinux версия пула и файловой системы совместима с ZFS из состава FreeBSD 9.0 и 8.3. В новой версии продолжено портирование компонентов ZFS из проекта Illumos, в рамках которого создано полностью свободное и развиваемое независимым сообществом ответвление от кодовой базы OpenSolaris. Среди наиболее значительных улучшений отмечено: -  Поддержка устройств подкачки на основе ZVOL; -  Поддержка ядер Linux с патчами PREEMPT_RT (ветка "-rt"); -  Заметно увеличена производительность msync(); -  Улучшено поведение в условиях нехватки памяти; -  Расширены возможности поиска при выполнении 'zpool import'; -  Добавлена поддержка команды  'zstreamdump'; -  Добавлена поддержка команды 'zfs get -t datatype". URL: https://groups.google.com/a/zfsonlinux.org/forum/?fromgroups... Новость: http://www.opennet.me/opennews/art.shtml?num=34885
Ответить | Правка | Cообщить модератору

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

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

1. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
Сообщение от Kroz (??) on 19-Сен-12, 13:02
Как оно на практике?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от redixin (ok) on 19-Сен-12, 14:00
	Юзаю несколько месяцев на сервере который хранит бекапы (бекапы бекапов. фс все таки экспериментальная), а так же несколько слейвов mongodb которые снапшотятся. Фс юзается весьма активно, и даже пару раз было внезапное отключение питания и проблем не возникало.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	13. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+4 +/–
	Сообщение от iCat (ok) on 19-Сен-12, 15:08
	Больше года: - на томе, лежащем на zfs, подключенном по iSCSI к Windows 2003 крутится пяток SQL-баз 1С. - на томе, расположенном на двух HDD по схеме ZRAID, с включённой дедупликацией (коэффициент дедупликации приблизился к 3x), лежат файлы пользователей. Снапшоты делаются ежедневные (с глубиной ротации 31 день) и еженедельные (с глубиной ротации 365 дней). Пользовательские файлы раздаются SAMBA. Что интересно: пользователи при right-click на папке или файле выбирают свойства, а там - "Предыдущие версии", выбирают архивную копию за требуемую дату и копируют к себе, куда им надо... Впрочем, это уже, наверное, к zfs отношения не имеет...
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	16. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Хрен с горы on 19-Сен-12, 15:15
	>Что интересно: пользователи при right-click на папке или файле выбирают свойства, а там - "Предыдущие версии", выбирают архивную копию за требуемую дату и копируют к себе, куда им надо... Впрочем, это уже, наверное, к zfs отношения не имеет... Круто! А как такое делается?
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	23. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от Elhana (ok) on 19-Сен-12, 15:34
	>>Что интересно: пользователи при right-click на папке или файле выбирают свойства, а там - "Предыдущие версии", выбирают архивную копию за требуемую дату и копируют к себе, куда им надо... Впрочем, это уже, наверное, к zfs отношения не имеет... > Круто! А как такое делается? Точно также как тут: http://help.ubuntu.ru/wiki/samba_shadow_copy только снапшоты zfs, а не LVM - на одном диске и без оверхеда по лишней записи.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	25. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Хрен с горы on 19-Сен-12, 15:36
	Спасибо!
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	46. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от redixin (ok) on 19-Сен-12, 17:53
	> подключенном по iSCSI кстати, оно не тормозит? > на двух HDD по схеме ZRAID raidz из двух дисков?
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	59. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iCat (ok) on 20-Сен-12, 01:48
	>> подключенном по iSCSI >кстати, оно не тормозит? "тормозит" - понятие относительное. С теми базами, которые лежат на iSCSI работают программисты. Они не жалуются... >> на двух HDD по схеме ZRAID >raidz из двух дисков? А чем это смущает?
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	79. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от ананим on 20-Сен-12, 13:55
	>С теми базами, которые лежат на iSCSI работают программисты. Они не жалуются... ну ещё бы! :D пусть только попробуют!
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	133. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iCat (ok) on 22-Сен-12, 14:56
	>>С теми базами, которые лежат на iSCSI работают программисты. Они не жалуются... > ну ещё бы! :D > пусть только попробуют! У меня с ними хорошие взаимоотношения.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	69. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Andrew Kolchoogin on 20-Сен-12, 10:51
	Достаточно стабильно для меня, чтобы не бояться держать на нём домашнюю директорию: при кросс-платформенной разработке под несколько Юниксов возникает проблема обмена данными между различными установленными на одной и той же машине операционками. Как ни смешно, но кроме ZFS _одновременно хорошо_ FreeBSD, Linux и Solaris поддерживают разве что FAT. :) А ZFS очень и очень выручает. Ну и, конечно, приятно наличие "RAID'а для notebook'ов" -- при установке "zfs set copies=3" авторы ZFS _гарантируют_ сохранность данных при разрушении ~8% поверхности HDD, что для вечно таскаемого ноута не такая уж невозможная ситуация -- совет поставить второй HDD на USB как-то не радует. :)
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	72. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от nagual (ok) on 20-Сен-12, 11:14
	> Достаточно стабильно для меня, чтобы не бояться держать на нём домашнюю директорию: > при кросс-платформенной разработке под несколько Юниксов возникает проблема обмена данными > между различными установленными на одной и той же машине операционками. > Как ни смешно, но кроме ZFS _одновременно хорошо_ FreeBSD, Linux и Solaris > поддерживают разве что FAT. :) А ZFS очень и очень выручает. > Ну и, конечно, приятно наличие "RAID'а для notebook'ов" -- при установке "zfs > set copies=3" авторы ZFS _гарантируют_ сохранность данных при разрушении ~8% поверхности > HDD, что для вечно таскаемого ноута не такая уж невозможная ситуация > -- совет поставить второй HDD на USB как-то не радует. :) С ноутами засада. Если стукнуть диск заклинит и тогда и ZFS не поможет а если поставить SSD и там контролер вылетит тот вероятность восстановления вообще 0% ...
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	73. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Andrew Kolchoogin on 20-Сен-12, 12:50
	> С ноутами засада. Если стукнуть диск заклинит и тогда и ZFS не поможет Если именно _заклинит_ -- то есть, из-за гироскопического эффекта искривится ось шпинделя -- тогда можно снять тарелку, переставить в рабочую технологическую "банку" и попытаться "поймать калибровку". Дорого, требует аргонового бокса и терпения, но для данных совершенно безопасно. Если же калибровка "не ловится", тогда нужно примерно 5-6 млн. руб. и установка для рамановской спектроскопии (спектроскопии комбинационного рассеяния) -- ну и, конечно, мощная числодробилка для спектрального анализа. Не надо думать, что варианты теоретические -- из-за потерь описания и алгоритмов шифрования магнитных лент NASA до сих пор не может прочитать данные из космоса, полученные между 1959 и 1965 годами, они стоят гораздо дороже пяти миллионов рублей, так же и данные, хранившиеся на "склинившем" винчестере ноутбука могут стоить пару вагонов с такими ноутбуками. :) А вот если головкой прочертит по поверхности, тогда шансы на восстановление без избыточности довольно призрачны. Про SSD согласен, во всяком случае, пока -- на текущий момент технологии восстановления данных с разрушившегося SSD мне неизвестны.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	101. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Сен-12, 02:51
	> -- тогда можно снять тарелку, переставить в рабочую технологическую "банку" и > попытаться "поймать калибровку". Дорого, требует аргонового бокса и терпения, Аргон то нафига? Хитачики вон еще только собираются делать диски с гелием. А в современных пока-что обычный воздух. Все-равно банка не идеально герметична. Так что и простой воздух катит, только обеспыленный, так что то о чем вы вещаете - "чистая комната". Ну или чистый бокс для тех кто не настолько крутой. А вот насчет всего остального есть крупные сомнения что такая операция закончится успехом. Во первых если по диску долбанули так что шпиндель согнулся, есть шанс что головы заодно порядочно запилили поверхность. Во вторых, хотя на блинах и есть сервометки по которым и позиционируются головы, у каждого винта есть еще и индивидуальные калибровки. Сомнительно что они подойдут при такой пересадке, а пересчитать их врядли выйдет кроме как на фабрике. Даже если допустить что такой хардкор мог бы привести к успеху, такая долботня специалиста потребной квалификации стоит как целая стопка жестких дисков. По поводу чего, простите, намного проще и дешевле просто делать бэкапы важных данных. > но для данных совершенно безопасно. Если же калибровка "не ловится", тогда нужно примерно > 5-6 млн. руб. и установка для рамановской спектроскопии (спектроскопии комбинационного > рассеяния) -- ну и, конечно, мощная числодробилка для спектрального анализа. И как, много винтов таким методом прочитали? Там же еще кодирование, специфичное для производителя и прочая - придется полностью реверсить все и вся. Я допускаю что особо крутые лабы могут даже в принципе осилить сие для сильно некоторых производителей за сильно отдельные бабки или получить инфо от производителя даже. И то не факт. > дороже пяти миллионов рублей, так же и данные, хранившиеся на "склинившем" > винчестере ноутбука могут стоить пару вагонов с такими ноутбуками. :) Капитан намекает что если у кого есть такие ценные данные то обычно и бэкапы есть. > Про SSD согласен, во всяком случае, пока -- на текущий момент технологии > восстановления данных с разрушившегося SSD мне неизвестны. Отпаять микросхемы флеша да прочитать на программаторе. Вот и вся методика. Ни вам чистых боксов, ни нежной механики, ни супердупер калибровок. Далее потребуется разгрести логику wear leveling + сжатие (если есть, оным особенно славится SandForce, юзающий его для ускорения записи) чтобы отстроить нормальный образ девайса эквивалентный тому что контроллер SSD вывесил бы операционке. У современных контроллеров может быть достаточно навороченно, но все это как раз вполне реально, т.к. требует только мозговых усилий и они зачастую были проделаны. Шифрование (если было) - скорее всего не разгребут. А так - продвинутые сервисмэны все это умеют. И поскольку реверсить wear leveling надо лишь 1 раз в отличие от возни с механикой каждый раз, а далее все написанный софт будет на автомате разруливать - есть даже надежда на не очень конский ценник. Но это очень зависит от.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	112. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от nagual (ok) on 21-Сен-12, 08:04
	> Отпаять микросхемы флеша да прочитать на программаторе. Вот и вся методика. Ни > вам чистых боксов, ни нежной механики, ни супердупер калибровок. Сразу видно месье не в теме ... > Далее потребуется > разгрести логику wear leveling + сжатие Прецендентов пока небыло.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	178. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 12:30
	> Сразу видно месье не в теме ... Мсье как раз мониторит состояние отрасли. >> разгрести логику wear leveling + сжатие > Прецендентов пока небыло. А как же тогда конторы по дата рекавери предлагают достать информацию с SSD и флешек? Или предлагается поверить в то что nagual эксперт а все кто предлагает такие услуги - гонщики?
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	197. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от nagual (ok) on 23-Сен-12, 17:08
	> Мсье как раз мониторит состояние отрасли. Месье мэнаджэр ? :-)) > А как же тогда конторы по дата рекавери предлагают достать информацию с > SSD и флешек? Или предлагается поверить в то что nagual эксперт > а все кто предлагает такие услуги - гонщики? Почуствуйте разницу между "предлагают" и "достать". Хотябы приведите сравнительно цены этого "достать" между SSD и HDD.
	Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

	224. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 20:22
	> Месье мэнаджэр ? :-)) Нет. Мсье просто интересуется подобными вопросами. >> а все кто предлагает такие услуги - гонщики? > Почуствуйте разницу между "предлагают" и "достать". Хотябы приведите сравнительно цены > этого "достать" между SSD и HDD. Простите, с HDD в сложных случаях цена может быть даже более конская или же данные вообще не смогут достать.
	Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

	126. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Клыкастый2 on 21-Сен-12, 16:36
	> Как ни смешно, но кроме ZFS _одновременно хорошо_ FreeBSD, Linux и Solaris Вы так говорите, как будто постоянно в 3 операционки винты перетыкаете.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	71. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Andrew Kolchoogin on 20-Сен-12, 11:09
	Впрочем, "на практике для больших" оно тоже лучше, чем BtrFS. Oracle, к сожалению, "распылило усилия", и не в лучшую сторону -- в частности, поддержка использования ZFS DMU в Lustre была практически готова ещё в 2010 году, но Oracle практически забросила Solaris и ZFS, так что допиливать поддержку пришлось сторонним организациям. ldiskfs в Lustre обладает довольно серьёзным ограничением на том -- всего 8 ТБ. Конечно, "в те годы, когда Коран писали...", оно было и ничего, но не во второй декаде XXI века. Но LLNL не дремлет: http://zfsonlinux.org/llnl-zfs-lustre.html Вполне может быть, что Sequoia (№1 в Top 500 суперкомпьютеров) использует именно Люстру поверх ZFS под Линуксом. Или будет. В BtrFS ничего подобного нет, и, насколько я понимаю, в обозримом будущем не предвидится.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	75. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 20-Сен-12, 13:39
	однобокое суждение. 1. вначале люстру санки насильно прогнули под zfs и не доделали. теперь в этих недоделках оракл конечно виноват. ага. а то что там вполне возможно просто архитектурные ограничения (нафиг там zfs, если она до этого и без него отлично работала? решили тормозить непадецки? ну-ну). разрабы помалкивают, но есть определённая уверенность, что люстра БЕЗ zfs лучше люстры С zfs. санкам это было нужно - они с линухом конкурировали. ораклу же всё-равно что продавать. 2. на базе бтр и рассчитывая на её архитектурные особенности, развивается ceph. конечно можно это не замечать ("люстра то в топ500, а где ceph?" - эдакий мс-подход). как и то, что статус её разработки примерно такой же, как и в люстре+zfs. в любом случае на данный момент факт такой: 3. в топ500 нет люстры+zfs. и есть подозрения (переходящие в уверенность) что и не будет - собственно а нахрена уже работающей люстре из оперного театра ещё и вот та гармонь с балалайкой.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	78. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от ананим on 20-Сен-12, 13:54
	зыж А вообще прикольный пассаж! :D >Вполне может быть, что Sequoia (№1 в Top 500 суперкомпьютеров) использует именно Люстру поверх ZFS под Линуксом. Или будет. >В BtrFS ничего подобного нет, и, насколько я понимаю, в обозримом будущем не предвидится. сводится к такому: "в топ500 есть люстра, поэтому zfs круче btrfs". прикольно. вы в сфере маркетинга работаете? :D
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	83. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Andrew Kolchoogin on 20-Сен-12, 15:58
	> А вообще прикольный пассаж! :D >>Вполне может быть, что Sequoia (№1 в Top 500 суперкомпьютеров) использует именно Люстру поверх ZFS под Линуксом. Или будет. >>В BtrFS ничего подобного нет, и, насколько я понимаю, в обозримом будущем не предвидится. > сводится к такому: > "в топ500 есть люстра, поэтому zfs круче btrfs". А как вы собираетесь сравнивать качество программного обеспечения, если не по месту его использования? По сексуальной ориентации авторов, что ли?-) Ню-ню. > прикольно. вы в сфере маркетинга работаете? :D А вы с какой целью интересуетесь?
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	84. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 20-Сен-12, 16:02
	>А как вы собираетесь сравнивать качество программного обеспечения, если не по месту его использования? а я и сравниваю... на своём ноуте! :D а в топ500 их сравнение пока не предвидится. >> прикольно. вы в сфере маркетинга работаете? :D >А вы с какой целью интересуетесь? с целью школы и времени обучения. интересно в общем.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	95. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Andrew Kolchoogin on 21-Сен-12, 01:16
	>> А как вы собираетесь сравнивать качество программного обеспечения, если не по месту >> его использования? > а я и сравниваю... на своём ноуте! :D Ага. Люстровы >>> прикольно. вы в сфере маркетинга работаете? :D >>А вы с какой целью интересуетесь? > с целью школы и времени обучения. > интересно в общем.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	96. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Andrew Kolchoogin on 21-Сен-12, 01:19
	>> А как вы собираетесь сравнивать качество программного обеспечения, если не по месту >> его использования? > а я и сравниваю... на своём ноуте! :D Ага. Люстровый кластер на виртуалках развёрнут, да? Ну, админы localhost'а -- большие специалисты по качеству программного обеспечения... > а в топ500 их сравнение пока не предвидится. ... и по прогнозам, это всем известно. >>> прикольно. вы в сфере маркетинга работаете? :D >> А вы с какой целью интересуетесь? > с целью школы и времени обучения. Я готов вас обучить. Готовы ли вы платить за обучение?
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	98. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 21-Сен-12, 01:43
	Не, млин, зетэфесный!!! Зыж > Я готов вас обучить. Готовы ли вы платить за обучение? БЕЗУСЛОВНО. Как только вы докажите свою квалификацию. Пока - ниже двоечки.
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	102. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Сен-12, 03:13
	> прикольно. вы в сфере маркетинга работаете? :D А это у всех солярщиков и маркетоидов так. Зато наш маркетолог не умеет чинить SSD. А те кто занимается data recovery вполне осиливают SSD, потому как там все относительно просто как раз. И данные в цифровом виде вынуть прямо из чипов можно. Другое дело что чем навороченнее ФС, чем больше там слоев RAID, сжатия, дедупликации и прочих снапшотов - тем меньше шансов что спецы по дата рекавери смогут этого шалтая-болтая собрать в нечто работающее и тем больше они будут возиться и дороже сдерут, т.к. все менее автоматически и все более геморройно по мере возрастания навороченности ФС. А встроенные средства починки из откровенно убитого состояния у ZFS хиленькие, так что на автоматику спецам надеяться не придется особо, как и на то что частично разрушенная ФС сможет сама себя как-то прочитать. В этом плане чем проще ФС, тем лучше.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	113. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от nagual (ok) on 21-Сен-12, 08:06
	>[оверквотинг удален] > в цифровом виде вынуть прямо из чипов можно. > Другое дело что чем навороченнее ФС, чем больше там слоев RAID, сжатия, > дедупликации и прочих снапшотов - тем меньше шансов что спецы по > дата рекавери смогут этого шалтая-болтая собрать в нечто работающее и тем > больше они будут возиться и дороже сдерут, т.к. все менее автоматически > и все более геморройно по мере возрастания навороченности ФС. А встроенные > средства починки из откровенно убитого состояния у ZFS хиленькие, так что > на автоматику спецам надеяться не придется особо, как и на то > что частично разрушенная ФС сможет сама себя как-то прочитать. В этом > плане чем проще ФС, тем лучше. Месье тонко манипулирует понятиями, сначала говорит про SSD потом оказывается что это уже ZFS не думаю что он это делает со злым умыслом, куда ему болезному :)) просто провалы в памяти на фоне осеннего обострения ...
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	180. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 12:35
	> Месье тонко манипулирует понятиями, Не понятно в каком месте манипуляция. Обычный капитанинг. Если вы припретесь в дата рекавери лабу что с SSD что с HDD которые были пулом ZFS - тут вас обдерут, да. Если ZFS вот так сходу не соберется - это будет попадос, потому что собирать такое монстрило по кусочкам - удовольствие очень так себе. То же самое касается и RAID, особенно экзотичных. Дешево, просто и быстро - только типовые и массовые грабли. А всякий кастом будет стоить вам совершенно отдельных денег. > сначала говорит про SSD потом оказывается что это > уже ZFS не думаю что он это делает со злым умыслом, Вы еще и думать умеете? > куда ему болезному :)) просто провалы в памяти на фоне осеннего обострения ... Реквестирую скан диплома, подтверждающий вашу квалификацию, позволяющую ставить подобные диагнозы. Иначе будете объявлены шарлатаном.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	82. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Andrew Kolchoogin on 20-Сен-12, 15:52
	> 1. вначале люстру санки насильно прогнули под zfs и не доделали. > теперь в этих недоделках оракл конечно виноват. Не "не доделали", а "не успели доделать до поглощения Ораклом". > ага. а то что там вполне возможно просто архитектурные ограничения (нафиг там zfs, > если она до этого и без него отлично работала? решили тормозить непадецки? ну-ну). "Там" -- это где? В Lustre? Или в ldiskfs? Если в Lustre, то там никаких архитектурных ограничений нет (так же, как в TCP нет ограничения на размер передаваемых во время одного connect()'а данных). А если в ldiskfs -- то да, есть, о чём я и написал. А в связке ZFS DMU/Lustre их нет, и этот код есть, и работает. Я что-то не пойму, вы с каким утверждением пытаетесь полемизировать? > на базе бтр и рассчитывая на её архитектурные особенности, развивается ceph. Я их весь сайт облазил. Дайте, пожалуйста, ссылку внутри ceph.com, где написано, что "на базе BtrFS, и рассчитывая на её архитектурные особенности". > в топ500 нет люстры+zfs. и есть подозрения (переходящие в уверенность) что и не будет Это у вас откуда такая уверенность, что нет? Лично я высказывал _подозрения_, что есть -- соотнося разработчика Lustre/ZFS и владельца Sequoia. Вы лично в LLNL звонили, что ли?
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	85. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 20-Сен-12, 16:06
	>[оверквотинг удален] > я и написал. А в связке ZFS DMU/Lustre их нет, и > этот код есть, и работает. > Я что-то не пойму, вы с каким утверждением пытаетесь полемизировать? >> на базе бтр и рассчитывая на её архитектурные особенности, развивается ceph. > Я их весь сайт облазил. Дайте, пожалуйста, ссылку внутри ceph.com, где написано, > что "на базе BtrFS, и рассчитывая на её архитектурные особенности". >> в топ500 нет люстры+zfs. и есть подозрения (переходящие в уверенность) что и не будет > Это у вас откуда такая уверенность, что нет? > Лично я высказывал _подозрения_, что есть -- соотнося разработчика Lustre/ZFS и владельца > Sequoia. Вы лично в LLNL звонили, что ли? Кстати ОРАкля zfs v30 v31 под свободной лицензией не пускает ... неудивительно что это в linux не принимается ... Вобщем можно подвести итог: ОРАкле удалось задавить ZFS бтрфс мускуль опеофис и даже жабу :-))) ... вобщем все до чего ручки дотянулись.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	87. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 20-Сен-12, 16:18
	btrfs очень сильно развивается. число коммитов (и участников) увеличилось если не в десятки, то в разы. недавно вот тестировал сэнд/ресив. вроде работает. вот пруфы - список рассылки http://vger.kernel.org/vger-lists.html#linux-btrfs график коммитов - http://dir.gmane.org/gmane.comp.file-systems.btrfs сами патчи - http://www.spinics.net/lists/linux-btrfs/ ("сабжектс" начинаются с [PATCH] Btrfs:) сейчас разработка идёт очень активно. что характерно, специалистами оракл - процентов 5, не более на мой взгляд.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	182. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 12:36
	> btrfs очень сильно развивается. Ну так бсдшные оналитеги не пописаны на рассылки и список коммитов не смотрят. Зато аналитику толкнуть горазды.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	187. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от iZEN (ok) on 23-Сен-12, 12:49
	>> btrfs очень сильно развивается. > Ну так бсдшные оналитеги не пописаны на рассылки и список коммитов не > смотрят. Зато аналитику толкнуть горазды. А чего там смотреть? Всё и так ясно — Btrfs не сертифицирована для продакшена баз данных. http://www.spinics.net/lists/linux-btrfs/msg19006.html //--- Subject: Re: Experiences: Why BTRFS had to yield for ZFS From: Avi Miller <avi.miller@xxxxxxxxxx> Date: Wed, 19 Sep 2012 07:46:26 +1000 Cc: Casper Bnag <casper.bang@xxxxxxxxx>, linux-btrfs@xxxxxxxxxxxxxxx In-reply-to: <5058A5C8.8080107@affinityvision.com.au> Hi, On 19/09/2012, at 2:48 AM, Andrew McGlashan <andrew.mcglashan@xxxxxxxxxxxxxxxxxxxxx> wrote: > On 17/09/2012 8:05 PM, Avi Miller wrote: >> Oracle Database is not certified to run on either btrfs or ZFS on Linux, so if certification is an issue, you can't use either filesystem. Out of interest, have you done a performance benchmark with ASM using ASMlib on the same platform? > > I thought that Oracle considered BTRFS to be production ready.  It > surprises me that running an Oracle database on BTRFS is not a supported > configuration. The Oracle Linux team considers btrfs production-ready and we support it for production purposes for customers. However, we have nothing to do with Database and their certification process, and the Database (and other) product teams have not certified it for use with their products yet. This is also why product certification lags: we have nothing to do with individual product certification processes on various operating systems/platforms. So, while I'm aware that the database team is planning to certify btrfs "at some point", I suspect with Oracle OpenWorld coming up in a few weeks time, they have other things on their plate right now. :) -- Oracle <http://www.oracle.com> Avi Miller | Principal Program Manager | +61 (412) 229 687 Oracle Linux and Virtualization 417 St Kilda Road, Melbourne, Victoria 3004 Australia ---//
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

	227. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 20:25
	> А чего там смотреть? Всё и так ясно — Btrfs не сертифицирована > для продакшена баз данных. Бсда вообще никак не сертифицирована для оракла. Ни с ZFS, ни без. Так что причина понтов не понятна.
	Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

	235. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 20:34
	>> А чего там смотреть? Всё и так ясно — Btrfs не сертифицирована >> для продакшена баз данных. > Бсда вообще никак не сертифицирована для оракла. Ни с ZFS, ни без. > Так что причина понтов не понятна. Причина понтов с Btrfs тоже непонятна. Ну объявили её якобы готовой к продакшену, а вендоры готовых решений что-то не торопятся на неё переходить. Почему? Беспонтово потому что — терять данные на ровном месте никто не хочет, кто бы что бы там не объявлял. А вот пионеры в лице User294 всё ещё надеются, что в Btrfs произойдут качественные изменения, появится поддержка RAID-5 на уровне ФС, может быть напишут нормальный дефрагментатор и допишут btrfsck, которые сделают работу этой замечательной во всех отношениях CoW ФС более-менее человечной, а не сикась-накось. Про сертификацию Oracle СУБД для работы на этой замечательной ФС я уже не говорю — что-то движется ЗА горизонтом, но очертания не ясны.
	Ответить | Правка | ^ к родителю #227 | Наверх | Cообщить модератору

	239. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 20:38
	> А вот пионеры в лице User294 всё ещё надеются, что в Btrfs > произойдут качественные изменения, появится поддержка RAID-5 на уровне ФС, может быть Не надо поддержки RAID-5 на уровне ФС. Только не это. > напишут нормальный дефрагментатор А в ZFS его не напишут никогда. Хотя CoW FS без нормального дефрагментатора/GC в долгосрочной перспективе юзабельна только под файлопомойку с соотношением read/add/delete/overwrite примерно в 100/1/1/0.
	Ответить | Правка | ^ к родителю #235 | Наверх | Cообщить модератору

	247. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 20:59
	> Не надо поддержки RAID-5 на уровне ФС. Только не это. Почему? Что плохого в RAID-5 на уровне ФС? >> напишут нормальный дефрагментатор > А в ZFS его не напишут никогда. Хотя CoW FS без нормального > дефрагментатора/GC в долгосрочной перспективе юзабельна только под файлопомойку с соотношением read/add/delete/overwrite примерно в 100/1/1/0. Я вроде как опроверг твоё мнение на счёт скорости софтверного RAID-5 (RAID-Z). Да, действительно, при заполнении на 97-99% операции чтения-записи на такой пул тормозят. Но если свободно хотя бы 15 — лучше 30 ГБ, то скорости чтения/записи будут в порядке. Для SSD это нивелируется ещё больше, так как на SSD не действует естественная фрагментация CoW ФС.
	Ответить | Правка | ^ к родителю #239 | Наверх | Cообщить модератору

	265. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 22:55
	> Я вроде как опроверг твоё мнение на счёт скорости софтверного RAID-5 (RAID-Z). Это читом с закешированным файлом? Нет уж, давай либо на холодное кеширование, либо файлом более чем размер кеша. Вот тот самый 14-гиговый файл, думаю, будет неплохим примером, если в системе не более 8 Гб памяти.
	Ответить | Правка | ^ к родителю #247 | Наверх | Cообщить модератору

	513. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 02-Окт-12, 21:06
	>> А вот пионеры в лице User294 всё ещё надеются, что в Btrfs >> произойдут качественные изменения, появится поддержка RAID-5 на уровне ФС, может быть > Не надо поддержки RAID-5 на уровне ФС. Только не это. >> напишут нормальный дефрагментатор > А в ZFS его не напишут никогда. Хотя CoW FS без нормального > дефрагментатора/GC в долгосрочной перспективе юзабельна только под файлопомойку с соотношением > read/add/delete/overwrite примерно в 100/1/1/0. Скажите а Reiser4 это продолжение развития reiserfs ? http://habrahabr.ru/post/108629/ А то пишут что там с дефрагментацией все плохо:"...Например, при использовании reiser4 на разделе с торрентами, получалось больше 11000 фрагментов на 700-мегабайтный файл, и никаким копированием не получалось сбить этот показатель хотя бы до нескольких сотен. При этом были ощутимы негативные последствия для производительности..." И еще журнал там тоже только на метаданные ?
	Ответить | Правка | ^ к родителю #239 | Наверх | Cообщить модератору

	532. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 06-Окт-12, 15:42
	> Скажите а Reiser4 это продолжение развития reiserfs ? Скорее тотальный rewrite "по мотивам". > А то пишут что там с дефрагментацией все плохо:"...Например, при использовании reiser4 > на разделе с торрентами, получалось больше 11000 фрагментов на 700-мегабайтный файл, Да и фиг с ним - это совсем сырая ФС для камикадзе.
	Ответить | Правка | ^ к родителю #513 | Наверх | Cообщить модератору

	327. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 20:38
	> Причина понтов с Btrfs тоже непонятна. Ну объявили её якобы готовой к продакшену, Поддержку с ней объявили 2 конторы, ну и не более того. На свой страх и риск, в своих дистрах, юзающих порядком допатченные ядра. > а вендоры готовых решений что-то не торопятся на неё переходить. На *BSD вообще мало кто нынче переходит. Если уж сравнивать - так *BSD нынче вообще в *опе. > Почему? Беспонтово потому что — терять данные на ровном месте никто > не хочет, кто бы что бы там не объявлял. Так правильно, такую штуку надо тестировать как следует. > А вот пионеры в лице User294 всё ещё надеются, что в Btrfs > произойдут качественные изменения, Вот чего-чего а фич там уже более чем. Теперь все это застабилизировать окончательно надо. Хотя, конечно, НеПианерам (tm) со скоростью 6Мб на шпиндель виднее как оно там лучше в дисковых технологиях. Но я бы при такой скорости взвыл и соптимизил бы ее в разы, так или иначе :P. > появится поддержка RAID-5 на уровне ФС, может быть напишут нормальный дефрагментатор Там уже есть дефрагер. А в zfs мало того что его нет и не планируется, так что оно не подарок для механики, так еще и TRIM нету, так что оно не подарок для SSD. Замечательно. А в btrfs и trim уже есть. Ха. > и допишут btrfsck, (аналогов которого в ZFS нет и не предвидится вообще) > которые сделают работу этой замечательной во всех отношениях CoW > ФС более-менее человечной, а не сикась-накось. Ну то-есть, по словам изена, ZFS - кривая ФС. Дефрага - нету, fsck - тоже, trim не поддерживается. В общем красота. > Про сертификацию Oracle СУБД для работы на этой замечательной ФС я уже > не говорю — что-то движется ЗА горизонтом, но очертания не ясны. А *bsd оракл в принципе сертифицировать не собирается. В результате, если не просто наезжать на сферические недостатки в вакууме а сравнить с ближайшими конкурентами, получаем классическую картину "бревно и соринка".
	Ответить | Правка | ^ к родителю #235 | Наверх | Cообщить модератору

	328. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 24-Сен-12, 20:49
	> На *BSD вообще мало кто нынче переходит. Если уж сравнивать - так > *BSD нынче вообще в *опе. У соседа корова сдохла, совсем чужой человек, мелочь, а как приятно ... :-))) > Там уже есть дефрагер. А в zfs мало того что его нет > и не планируется, так что оно не подарок для механики, так > еще и TRIM нету, так что оно не подарок для SSD. > Замечательно. А в btrfs и trim уже есть. Ха. Неужели после детального разжовывания на хабре вы все еще бредите необходмостью трима ? Месье не закусывал когда пил тормозную жидкость? > В результате, если не просто наезжать на сферические недостатки в вакууме а > сравнить с ближайшими конкурентами, получаем классическую картину "бревно и соринка". Раз уж зашло о бревнах http://phpsuxx.blogspot.com/2010/08/raid-z.html изучите, чтоб потом не говорили что не заметили.
	Ответить | Правка | ^ к родителю #327 | Наверх | Cообщить модератору

	388. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 25-Сен-12, 18:58
	>> *BSD нынче вообще в *опе. > У соседа корова сдохла, совсем чужой человек, мелочь, а как приятно ... :-))) Это вы о себе? Потому что наперли на факт что ФС официально не поддерживается, а про то что у вас вся система официально не поддерживается, а не то что отдельная ФС - тактично промолчали. Очень напоминает озвученный подход. При том что у вас вообще весь хлев выкосило, вы радуетесь что у соседа хоть 1 корова - захворала. Пффф. >> Замечательно. А в btrfs и trim уже есть. Ха. > Неужели после детального разжовывания на хабре вы все еще бредите необходмостью трима Я не только брежу, я им еще пользуюсь. Потому что сам себе не враг. Кстати я и без всяких хабрашвабров представляю себе как все это работает, поэтому сам в состоянии делать выводы. > Месье не закусывал когда пил тормозную жидкость? Я не пью тормозную жидкость. > Раз уж зашло о бревнах http://phpsuxx.blogspot.com/2010/08/raid-z.html изучите, чтоб > потом не говорили что не заметили. Ну и что это за капитанинг? Ну есть, ну raid. Да, с чексуммами райд лучше чем без, как раз потому что можно понять какая из версий данных верна в случае когда диск не сдох совсем но стал завирать. Я это и так знаю. И чего?
	Ответить | Правка | ^ к родителю #328 | Наверх | Cообщить модератору

	329. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 24-Сен-12, 20:53
	>> Причина понтов с Btrfs тоже непонятна. Ну объявили её якобы готовой к продакшену, > Поддержку с ней объявили 2 конторы, ну и не более того. На > свой страх и риск, в своих дистрах, юзающих порядком допатченные ядра. Отстали вы от жизни однако со своими тестами криокамеры http://www.opennet.me/opennews/art.shtml?num=34218
	Ответить | Правка | ^ к родителю #327 | Наверх | Cообщить модератору

	389. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 25-Сен-12, 19:01
	> Отстали вы от жизни однако со своими тестами криокамеры http://www.opennet.me/opennews/art.shtml?num=34218 Я что-то не понял - в чем проблема? Оракл как раз одна из этих контор. Они сами для себя решили оказывать поддержку по btrfs. Их право.
	Ответить | Правка | ^ к родителю #329 | Наверх | Cообщить модератору

	331. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Сен-12, 20:55
	> Ну то-есть, по словам изена, ZFS - кривая ФС. Дефрага - нету, > fsck - тоже, trim не поддерживается. В общем красота. TRIM собираются спереть из ZFSoL, ибо припёрло. Интересно, как обойдут GPL...
	Ответить | Правка | ^ к родителю #327 | Наверх | Cообщить модератору

	336. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 24-Сен-12, 21:47
	>> Ну то-есть, по словам изена, ZFS - кривая ФС. Дефрага - нету, >> fsck - тоже, trim не поддерживается. В общем красота. > TRIM собираются спереть из ZFSoL, ибо припёрло. Интересно, как обойдут GPL... Никак — все изменения под CDDL, чего требует оригинальная лицензия ZFS. Добавленные файлы тоже под CDDL. :p
	Ответить | Правка | ^ к родителю #331 | Наверх | Cообщить модератору

	396. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 25-Сен-12, 20:24
	>>> Ну то-есть, по словам изена, ZFS - кривая ФС. Дефрага - нету, >>> fsck - тоже, trim не поддерживается. В общем красота. >> TRIM собираются спереть из ZFSoL, ибо припёрло. Интересно, как обойдут GPL... > Никак — все изменения под CDDL, чего требует оригинальная лицензия ZFS. Добавленные > файлы тоже под CDDL. :p Интересно если все изменения в ZFS могут быть только под CDDL то каким местом zfs v30 закрыто ?
	Ответить | Правка | ^ к родителю #336 | Наверх | Cообщить модератору

	400. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 25-Сен-12, 22:16
	> Интересно если все изменения в ZFS могут быть только под CDDL то > каким местом zfs v30 закрыто ? CDDL - это пермиссив для "юзеров". У компании-автора, априори, неограниченная лицензия. И ничего под CDDL они назад не бэкпортили. Поэтому могут перелицензировать, ни у кого, кроме себя, не спрашивая.
	Ответить | Правка | ^ к родителю #396 | Наверх | Cообщить модератору

	390. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 25-Сен-12, 19:03
	> TRIM собираются спереть из ZFSoL, ибо припёрло. Неужели маркетинговый буллшит прокатывать перестал? Какая досада! Зато мы скоро сможем лицезреть как эти лицемерные клоуны вопившие насчет "ненyжной" фичи начнут ее резко нахваливать на все лады :)
	Ответить | Правка | ^ к родителю #331 | Наверх | Cообщить модератору

	391. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 25-Сен-12, 19:06
	>> TRIM собираются спереть из ZFSoL, ибо припёрло. > Неужели маркетинговый буллшит прокатывать перестал? Какая досада! Зато мы скоро сможем > лицезреть как эти лицемерные клоуны вопившие насчет "ненyжной" фичи начнут ее > резко нахваливать на все лады :) TRIM практически увеличит скорость записи на флэш. Зачем отказываться от такой фичи?!
	Ответить | Правка | ^ к родителю #390 | Наверх | Cообщить модератору

	445. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 30-Сен-12, 19:20
	>> лицезреть как эти лицемерные клоуны вопившие насчет "ненyжной" фичи начнут ее >> резко нахваливать на все лады :) > TRIM практически увеличит скорость записи на флэш. Зачем отказываться от такой фичи?! Ну, что я говорил? Приятно чувствовать себя провидцем :)
	Ответить | Правка | ^ к родителю #391 | Наверх | Cообщить модератору

	465. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 15:16
	> TRIM собираются спереть из ZFSoL, ибо припёрло. ZFSLoL :) //fixed
	Ответить | Правка | ^ к родителю #331 | Наверх | Cообщить модератору

	86. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 20-Сен-12, 16:11
	>> 1. вначале люстру санки насильно прогнули под zfs и не доделали. теперь в этих недоделках оракл конечно виноват. > Не "не доделали", а "не успели доделать до поглощения Ораклом". могу ещё раз повторить, если вы не поняли - есть мнение, что таки доделали. но результат (как и ожидалось в общем-то. по техническим причинам) оказался хуже, чем оригинал. >"Там" -- это где? В Lustre? Или в ldiskfs? >Если в Lustre, то там никаких архитектурных ограничений нет... мы тут всё ещё про zfs говорим? или уже нет? :D или как обычно - и не zfs, и не целиком, и не в люстре. >Я что-то не пойму, вы с каким утверждением пытаетесь полемизировать? ваше высказывание - "Впрочем, "на практике для больших" оно тоже лучше, чем BtrFS."? не? где практика то? или тут - "В BtrFS ничего подобного нет, и, насколько я понимаю, в обозримом будущем не предвидится."? тоже не? >> в топ500 нет люстры+zfs. и есть подозрения (переходящие в уверенность) что и не будет >Это у вас откуда такая уверенность, что нет? >Лично я высказывал _подозрения_, что есть -- соотнося разработчика Lustre/ZFS и владельца Sequoia. Вы лично в LLNL звонили, что ли? вы высказывали УТВЕРЖДЕНИЯ. обосновывая их _подозрения_ми_. оригинально. похоже на серьёзную маркетинговую школу. вот только целевой аудиторией вы ошиблись.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	94. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Andrew Kolchoogin on 21-Сен-12, 01:14
	> могу ещё раз повторить, если вы не поняли - есть мнение, что таки доделали. > но результат (как и ожидалось в общем-то. по техническим причинам) оказался хуже, > чем оригинал. Слуште, я спрашивал у ZFS'ников уже после поглощения Sun'а Oracle'ом на последних Sun Tech Days, как дела с использованием DMU в Lustre. Мне совершенно чётко было отвечено: в 1.8 НЕ будет, потому что есть проблемы с выносом подсчёта контрольных сумм ZFS на сторону клиента -- ZFS всё, что можно, чексуммирует -- и связка Lustre+ZFS DMU делает это не на стороне DMU, а на стороне клиента -- чтобы ещё и сетку чексуммить. А вы откуда взяли свои домыслы? > мы тут всё ещё про zfs говорим? или уже нет? :D Нет, и не начинали. Мы говорим про использование ZFS DMU в Lustre под Linux. > ваше высказывание - "Впрочем, "на практике для больших" оно тоже лучше, чем BtrFS."? > не? где практика то? Хм. LLNL -- не "большие"? Они пишут код поддержки ZFS DMU для Lustre в теории, не на практике? Чего ж они хвалёный BtrFS не заюзали?-) > вы высказывали УТВЕРЖДЕНИЯ. "Это иллюзии". А вы таки в LLNL звонили, или нет? А то вы с такой уверенностью утверждаете, что Секвойя что-то там не использует... ;)
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	99. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от ананим on 21-Сен-12, 01:50
	>Слуште, я спрашивал у ZFS'ников уже после... а я пробовал. .. и участвовал.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

8. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–3 +/–
Сообщение от nagual (ok) on 19-Сен-12, 14:09
ZFS под линь пилят две комерческие конторы, бэтээру такое финансирование и не снилось. Вероятно бэтээр уже труп ... Многие кто был в нем заинтерисован посмотрели в сторону ZFS.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+10 +/–
	Сообщение от Одмин on 19-Сен-12, 15:01
	> бэтээру такое финансирование и не снилось. действительно, откуда у оракл деньги
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	12. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Crazy Alex (ok) on 19-Сен-12, 15:03
	Вот только btrfs  в ядре, так что user base  у него будет всяко много больше => больше баг-репортов и людей, к нему привычных.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	22. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от Vadim (??) on 19-Сен-12, 15:33
	> Вот только btrfs  в ядре, так что user base  у > него будет всяко много больше => больше баг-репортов и людей, к > нему привычных. Начиная с zfs-linux 0.0.6-rc10 модуль для ядра ставится при помощи dkms одной командой.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	27. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от Аноним (??) on 19-Сен-12, 15:56
	> Начиная с zfs-linux 0.0.6-rc10 модуль для ядра ставится при помощи dkms одной командой. Полная фигня, по сравнению с btrfs, которая идет из коробки. На нее даже систему можно ставить :)
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	33. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от Elhana (ok) on 19-Сен-12, 16:55
	> Полная фигня, по сравнению с btrfs, которая идет из коробки. На нее > даже систему можно ставить :) На zfs тоже можно систему ставить. А btrfs у меня пол года назад падала с грохотом через 15 минут моих издевательств.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	37. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+2 +/–
	Сообщение от Аноним (??) on 19-Сен-12, 17:15
	> На zfs тоже можно систему ставить. Вот так прям взять и выбрать в инсталляторе? > А btrfs у меня пол года назад падала с грохотом через 15 минут моих издевательств. Сказано же: допилят лет через пять.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	103. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Сен-12, 03:15
	> Сказано же: допилят лет через пять. Оракель и суся ее недавно в продакшновые ынтырпрайзные дистры засунули и объявили официальную поддержку. Другое дело что до кернеля 3.5 примерно его лучше не юзать - багов много. Но вообще оно уже работает, если не очень сильно извращаться.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	114. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от nagual (ok) on 21-Сен-12, 08:07
	>> Сказано же: допилят лет через пять. > Оракель и суся ее недавно в продакшновые ынтырпрайзные дистры засунули и объявили > официальную поддержку. Другое дело что до кернеля 3.5 примерно его лучше > не юзать - багов много. Но вообще оно уже работает, если > не очень сильно извращаться. Там был один баг не закрытый всего и связанный с большой нагрузкой ...
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	183. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 12:40
	> Там был один баг не закрытый всего и связанный с большой нагрузкой Опять этот Ыксперт и его сферические кони в вакууме.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	535. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 03-Авг-17, 20:02
	>> А btrfs у меня пол года назад падала с грохотом через 15 минут моих издевательств. > Сказано же: допилят лет через пять. Не допилили - хотят выбросить: https://www.opennet.me/opennews/art.shtml?num=46955
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	56. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 19-Сен-12, 21:12
	>На zfs тоже можно систему ставить. можно. но сложно. и сконвертировать имеющийся ext2/3/4 нельзя, как в бтрфс. >А btrfs у меня пол года назад падала с грохотом через 15 минут моих издевательств. не верю. год как на руте живёт (генту, куча сменившихся ядер и тд) - всё ок. с другой стороны историй с падающими zfs в тырнете тоже не мало. так что случаев не более, чем с любой другой фс.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	50. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–2 +/–
	Сообщение от nagual (ok) on 19-Сен-12, 18:00
	>> Начиная с zfs-linux 0.0.6-rc10 модуль для ядра ставится при помощи dkms одной командой. > Полная фигня, по сравнению с btrfs, которая идет из коробки. На нее > даже систему можно ставить :) Можно  ... но ненужно :-) потому как без гига оперы под кеш оно так же прекрасно как и ZFS :-)
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	68. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 20-Сен-12, 10:36
	> Можно  ... но ненужно :-) потому как без гига оперы под > кеш оно так же прекрасно как и ZFS :-) Вот только у ZFS кеш "плюсом" к системному, а BTRFS нормально юзает системный кеш. Разница "на лице".
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	70. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от nagual (ok) on 20-Сен-12, 11:08
	>> Можно  ... но ненужно :-) потому как без гига оперы под >> кеш оно так же прекрасно как и ZFS :-) > Вот только у ZFS кеш "плюсом" к системному, а BTRFS нормально юзает > системный кеш. Разница "на лице". Эксперименты показывают отсутствие разницы :-)) ...ох уж этот маркетинг.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	74. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 20-Сен-12, 13:02
	> Эксперименты показывают отсутствие разницы :-)) ...ох уж этот маркетинг. Эксперименты где? На локалхосте?
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	184. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 12:41
	> Эксперименты где? На локалхосте? Я думаю что он вообще не экспериментировал. Иначе он бы не втирал булшит про 1-2 гига памяти, актуальный только для ZFS с его отдельным кешом.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	199. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от nagual (ok) on 23-Сен-12, 17:15
	>> Эксперименты где? На локалхосте? > Я думаю что он вообще не экспериментировал. Сразу видно кто пробовал а кто книжки пишет :-)))
	Ответить | Правка | ^ к родителю #184 | Наверх | Cообщить модератору

	228. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 20:27
	> Сразу видно кто пробовал а кто книжки пишет :-))) Я то btrfs гоняю на регулярной основе. Просто потому что он мне нужен и я заинтересован в этом результате. А вот вы судя по тому какой маразм втираете видели его сугубо на картинке. Иначе не понятно откуда бред про 2 гига оперативки достали.
	Ответить | Правка | ^ к родителю #199 | Наверх | Cообщить модератору

	76. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 20-Сен-12, 13:47
	один раз вы уже вбрасывали эту дезу - http://www.opennet.me/openforum/vsluhforumID3/85027.html?n=n... . теперь вот опять. так вот - БРЕХНЯ. Эксперименты показывают, что бтр гораздо менее требовательна к ресурсам.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	80. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–2 +/–
	Сообщение от nagual (ok) on 20-Сен-12, 14:04
	> один раз вы уже вбрасывали эту дезу - http://www.opennet.me/openforum/vsluhforumID3/85027.html?n=n... > . > теперь вот опять. > так вот - БРЕХНЯ. > Эксперименты показывают, что бтр гораздо менее требовательна к ресурсам. У правильных экспериментаторов бульдозер проигрывает core i5 ... хотя в некоторых тестах core i5 волшебным образом становится core i7 раскаченным за 5ГГц ...
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	81. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от ананим on 20-Сен-12, 14:32
	понятно. вопросов больше не имею.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	97. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от Andrew Kolchoogin on 21-Сен-12, 01:31
	> теперь вот опять. > так вот - БРЕХНЯ. > Эксперименты показывают, что бтр гораздо менее требовательна к ресурсам. Чьи? Ваши? Опишите методику. Не ваши? Дайте ссылку. И вообще, что значит "гораздо менее требовательна к ресурсам" применительно к файловой системе? Нормальная файловая система должна стараться использовать _все_ доступные ресурсы ОЗУ и микропроцессора -- Disk I/O -- bottleneck _всегда_, если у вас не СХД на InfiniBand'е, так что извините, но это не ZFS требует много ресурсов -- это все остальные FS не умеют их использовать, не подменяйте понятия. Далее по курсу: в ZFS существуют архитектурные ограничения, свойственные _всем_ аналогично устроенным хранилищам. Заполненный zpool на 95-97% тормозит _жутко_ -- но так же будет тормозить, к примеру, Squid, если его раздел с кэшем заполнен на эти самые ~95-97%. Это особенность _всех_ COW-стораджей, она не лечится, это бага^Wхорошо задокументированная фича. И последнее: дефолтные настройки ZFS сделаны под некий "средний по больнице" workload: скажем, если у вас специфичный workload, требующий одномоментной аллокации здоровых кусков ОЗУ, ZFS с дефолтными настройками будет работать плохо. Гайка, закручивающая размер ARC, описана в ZFS Evil Tuning Guide, там же описаны corner cases, когда этот тюнинг надо делать. Читайте доки -- они рулез, как известно...
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	100. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 21-Сен-12, 01:56
	>> Эксперименты показывают, что бтр гораздо менее требовательна к ресурсам. >Чьи? Ваши? Опишите методику. Не ваши? Дайте ссылку. методику? :D извольте - есть у меня вайфай-роутер, нетгир wndr3700. а тут вдруг я сенд/ресив попробовал. уже почти все винты. на нетгире (последняя опенврт). во-о-от. есть винт по усб, на бтр. раздаётся с него на 2.5-3. по самбе. вот так то. лучше нтфс. а zfs в опе.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	514. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 02-Окт-12, 21:22
	>> Эксперименты показывают, что бтр гораздо менее требовательна к ресурсам. > Чьи? Ваши? Опишите методику. Не ваши? Дайте ссылку. Я по приколу запускал на железке с 64Мб рам на все про все. Без свопа. Даже довольно сносно работает. EXT4 конечно лучше, но...
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	104. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Сен-12, 03:20
	> кеш оно так же прекрасно как и ZFS :-) Лучше, ибо экстентные аллокаторы - не такие слоупоки как блочные. Плюс дефрагер встроенный есть, что для CoW ФС актуально. Так что вон фороникс только на днях бенчей сделал, забенчив на свежем ядре EXT4, XFS и BTRFS. В целом получилось довольно забавно: никто не победил. В целом EXT4 немного порезвее, но в целом - на одних тестах получше ext4, на других XFS, на третьих btrfs, при том в большинстве тестов разница не особо велика. В общем то вся троица показала весьма приличный результат, а то что у них разные сильные и слабые стороны - вполне ожидаемо в силу ряда отличий в устройстве ФС, так что одним удобнее одни типы нагрузок, а другим - другие.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	54. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от BratSinot on 19-Сен-12, 19:00
	> с btrfs, которая идет из коробки И ничего, что этот модуль тоже собирать надо?
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	57. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 19-Сен-12, 21:14
	ничего. поддержка бтр "из коробки" уже почти во всех ядрах современных дистров. и, что не маловажно, почти любых ливсиди.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	105. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Сен-12, 03:21
	> И ничего, что этот модуль тоже собирать надо? Самому его надо собирать только если вы гентушник. В бинарных дистрах он как правило по дефолту собран вместе с остальными модулями ФС. Что да, крупный плюс. Можно с места в карьер поюзать.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	53. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Crazy Alex (ok) on 19-Сен-12, 18:36
	Это если исходник есть в репозиториях... И где оно будет? В дебиане и редхете - не будет точно. В убунте - тоже вряд ли. То есть как минимум надо тащить для этого дополнительную репу. Что явно снизит количество желающих попробовать - одно дело тупо при инсталляции для пары разделов btrfs выбрать по принципу "а дай поиграюсь", другое - целенаправленно что-то ставить.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	58. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 19-Сен-12, 21:16
	ну, с бтр можно начать играться и уже на готовой системе - сконвертнул из ext4 и всё. не понравилось, вернул ext4 обратно.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	106. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Сен-12, 03:22
	> не понравилось, вернул ext4 обратно. Кстати да, гибкость BTRFS в плане размещения данных и метаданных - доставляет. Для нее EXT4 завраппленый в нее - это вот такой вот "типа, снапшот". Просто потому что это можно офрмить как снапшот. Здорово придумано, кстати :)
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	15. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+2 +/–
	Сообщение от Аноним (??) on 19-Сен-12, 15:14
	> Многие кто был в нем заинтерисован посмотрели в сторону ZFS. Ага, два раза :) Особенно оракл, который создал btrfs с учетом ошибок, сделанных в архитектуре ZFS.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	20. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Vadim (??) on 19-Сен-12, 15:30
	Неделю назад в рассылке zfs-discuss как раз была ссылка на позицию Oracle по портированию на linux: Regarding Oracle's position on ZFS (and other  technologies  inherited from Sun), here's an interesting  article: http://www.serverwatch.com/server-trends/oracle-pushing-forw... Regarding ZFS specifically, here's what  Wim Coekearts, a "Senior VP"  at Oracle, has declared:       "According to Coekaerts, porting ZFS to Linux involves a non-optimal approach that is not native. As such, there is likely not a need to attempt to bring ZFS to Linux since Btrfs is now around to fit the bill. " As long as Oracle doen't try to interfere and stop others like the ZFSOnLinux folks from doing so, I for one am happy enough with Oracle's decision to get out of the way in regards to porting ZFS to Linux.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	47. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от nagual (ok) on 19-Сен-12, 17:54
	>> Многие кто был в нем заинтерисован посмотрели в сторону ZFS. > Ага, два раза :) > Особенно оракл, который создал btrfs с учетом ошибок, сделанных в архитектуре ZFS. Но коник не взлетел ... и не взлетит потому как рядом рухнул купленный коник MySQL и все это возле мучительно умирающиго коника солярки ... Может что то с кормом не то ? :-)))
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	55. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от filosofem (ok) on 19-Сен-12, 19:06
	>Может что то с кормом не то ? :-))) Да, комбикорма приготовили из полуразложившегося трупа ZFS.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	62. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 20-Сен-12, 10:10
	> Но коник не взлетел ... и не взлетит О, пипец доморощенные аналитики. А чуваки из майнлайн ядра пилят его толпой и не знают что какой-то там nagual уже оказывается btrfs'а давно закoпал. Поскольку вы генерируете только трындеж на форуме, а те парни генерируют код который у меня работает - им я буду верить несколько больше, извините.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	63. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 20-Сен-12, 10:12
	> купленный коник MySQL То-то все хостинги по сей день юзают оный. А если оракл будет слишком выпендриваться, есть MariaDB совместимая с ним но от других граждан, так что удачи ораклу в попытках обнаглеть. Как максимум получат повтор истории с либрофисом :)
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	66. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от nagual (ok) on 20-Сен-12, 10:29
	>> купленный коник MySQL > То-то все хостинги по сей день юзают оный. А если оракл будет > слишком выпендриваться, есть MariaDB совместимая с ним но от других граждан, > так что удачи ораклу в попытках обнаглеть. Как максимум получат повтор > истории с либрофисом :) Месье застрял в криокамере? Безусловно ОРАкля не сломает мускуль за один день ... все таки много лет делалось но купили имеено с этой целью. Все более людей уходит с мусуля на его клоны. Кстати о btrfs и ZFS как только они стали хотябы теоритически составлять конкуренцию хардварным решениям ОРАкля их тут же купило, нет не чтобы похерить. Ога.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	67. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 20-Сен-12, 10:35
	C чего бы? Мы наоборот вернулись с MariaDB на MySQL, потому, что в 5.5 много вкусного, а у MariaDB как-то с форком долго было глухо.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	107. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Сен-12, 04:19
	> Месье застрял в криокамере? Безусловно ОРАкля не сломает мускуль за один день > ... все таки много лет делалось но купили имеено с этой целью. Наврядли. Ну не конкурент мускуль их базе, просто потому что мускуль - просто гольная скульная база. А оракель - нев....й фреймворк для разработки бизнес хрени. Прогулочная яхта не такой уж и страшный конкурент круизному лайнеру. > Все более людей уходит с мусуля на его клоны. Просто потому что оракл не умеет рулить открытыми проектами, только и всего. > Кстати о btrfs и ZFS как только они стали хотябы теоритически составлять > конкуренцию хардварным решениям ОРАкля их тут же купило, нет не чтобы > похерить. Ога. Оракль вообще не особо занимается оборудованием. С санями они получили это направление, но судя по всему - просрyт все полимеры. Сани они купили в основном потому что ява и клиентская база. Btrfs им нужен как подложка для их БД. Вполне способная работать так как им надо и позволяющая админить все-таки файлы в ФС а не черти-что в RAW разделах, что админам удобнее.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	115. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 21-Сен-12, 08:12
	>> Месье застрял в криокамере? Безусловно ОРАкля не сломает мускуль за один день >> ... все таки много лет делалось но купили имеено с этой целью. > Наврядли. Ну не конкурент мускуль их базе, просто потому что мускуль - > просто гольная скульная база. А оракель - нев....й фреймворк для разработки > бизнес хрени. Прогулочная яхта не такой уж и страшный конкурент круизному > лайнеру. Вот кластер рампочты на мускуле если верить слонику а мог бы быть на оракле ... И таких потенциальных клиентов множество.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	120. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Сен-12, 12:29
	> Вот кластер рампочты на мускуле если верить слонику а мог бы быть на оракле ... Прогулочную яхту арендовать несколько дешевле чем круизный лайнер, знаете ли. Поэтому когда хватает мелкой яхты - очень мало кто побежит арендовать целый лайнер. > И таких потенциальных клиентов множество. Мало кто будет арендовать трансокеанский лайнер для вечеринки. Тем более что готовых предоставить свои яхты стоит целая толпа. В свете чего профит с потуги пересадить всех с мелких яхт на огромные лайнеры выглядит неубедительно. Будут жить и те и другие - разная весовая категория.
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	123. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 21-Сен-12, 12:35
	> Прогулочную яхту арендовать несколько дешевле чем круизный лайнер, знаете ли. Поэтому когда > хватает мелкой яхты - очень мало кто побежит арендовать целый лайнер. Х...се 1к серверов в кластере :))) что то с круизным лайнером не то если 1к яхт лучше :))) > Мало кто будет арендовать трансокеанский лайнер для вечеринки. Тем более что готовых > предоставить свои яхты стоит целая толпа. В свете чего профит с > потуги пересадить всех с мелких яхт на огромные лайнеры выглядит неубедительно. > Будут жить и те и другие - разная весовая категория. Там проект уже прибит к мускулю гвоздями с клеем и так просто без изменения структуры проекта на оракл не переделать, а переделывать стоит кучу денег и в условиях кризиса одержимых безумнными идеями все переделать гонят ссаными тряпками. Вобщем оракл там нужен как в бане лыжи и только менагеры оракла могут не понимать это ...
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	185. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 12:46
	> Х...се 1к серверов в кластере :))) что то с круизным лайнером не то если 1к яхт лучше :))) 1К яхт обойдутся дешевле чем 1К круизных лайнеров ;) > Там проект уже прибит к мускулю гвоздями с клеем и так просто > без изменения структуры проекта на оракл не переделать, Тем более. Переделывать чтобы попасть на жесткий вендор лок-ин и заплатить бабла чуть ли не больше чем стоят сервера? Ну да, за кадром слышен конский топот сферических коней в вакууме. Побежавших переписывать все и вся под оракл. Ради... ради чего?
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	188. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от анон on 23-Сен-12, 12:52
	> Вот кластер рампочты на мускуле если верить слонику Много раз читаю про кластер рампочты и не понимаю, кто этот кластер нагружает. В последний раз почта, заканчивающаяся на @rambler.ru, встречалась мне лет... уфф, лет семь или восемь назад
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	161. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от iZEN (ok) on 23-Сен-12, 11:22
	> Btrfs им нужен > как подложка для их БД. Вполне способная работать так как им > надо и позволяющая админить все-таки файлы в ФС а не черти-что > в RAW разделах, что админам удобнее. Btrfs в конфигурации для Oracle DB не поддерживается официально.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	186. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 12:46
	> Btrfs в конфигурации для Oracle DB не поддерживается официально. А *bsd и тем более ZFS на оной и тем более с оракловой базой - вообще никак не поддерживается.
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

	189. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 12:53
	>> Btrfs в конфигурации для Oracle DB не поддерживается официально. > А *bsd и тем более ZFS на оной и тем более с > оракловой базой - вообще никак не поддерживается. Так свободные системы для свободных людей, разве нет? Какая же в Linux свобода, если в нём заправляют корпорации и диктуют условия использования недоделанных продуктов (Btrfs пока не сертифицирована для использования с СУБД)?
	Ответить | Правка | ^ к родителю #186 | Наверх | Cообщить модератору

	232. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 20:31
	> Так свободные системы для свободных людей, разве нет? Так я и не утверждал что мне нравится проприерасия от оракла и что я горю желанием в нее влопаться. Просто вы полезли меряться и получили резонное сравнение. Кстати свободные люди тоже бсды не особо серьезно воспринимают нынче. Вон интель недавно тут высказался о том что проблемы бсдшных слоупоков - не их проблемы, их это не интересует и они не собираются по этому поводу тормозить развитие линуксного кода. > Какая же в Linux свобода, если в нём заправляют корпорации Они если что и заправляют там то только бензобак. А с пустым бензобаком далеко не уедешь. > и диктуют условия использования недоделанных продуктов (Btrfs пока > не сертифицирована для использования с СУБД)? Охренеть, производитель СУБД диктует ее системные требования и перечисляет проверенные и заведомо рабочие конфигурации. Шок! Сенсация! Караул! Грабеж!
	Ответить | Правка | ^ к родителю #189 | Наверх | Cообщить модератору

	61. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 20-Сен-12, 10:00
	> ZFS под линь пилят две комерческие конторы, бэтээру такое финансирование и не снилось. А бтр пилят разработчики майнлайнового ядра. Не знаю считается ли это за финансирование, но пилят его довольно интенсивно и в майнлайне. А не где-то сбоку под левой лицензией. За чем будущее - несложно догадаться. Проект ФС вне майнлайна обречен быть маргинальной хренотенью нужной немногим, с невнятными перспективами всего этого начинания. ...просто потому что BTRFS сможет то что и ZFS. И даже больше. И лучше. Чем будут после этого зарабатывать указанные коммерческие конторы - вопрос интересный. И что случится с этой кодовой базой - тоже интересно, да. Поскольку если 2 коммерческие конторы окажутся без дохода от этого начинания и выбросят его на свалку - тогда чего? Как с опенсолярой и ораклем, да? :)
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	64. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–3 +/–
	Сообщение от nagual (ok) on 20-Сен-12, 10:23
	>> ZFS под линь пилят две комерческие конторы, бэтээру такое финансирование и не снилось. > А бтр пилят разработчики майнлайнового ядра. Не знаю считается ли это за > финансирование, но пилят его довольно интенсивно и в майнлайне. А не > где-то сбоку под левой лицензией. За чем будущее - несложно догадаться. Еще одна FS в коллекцию недофс линукса ... > Проект ФС вне майнлайна обречен быть маргинальной хренотенью нужной немногим, с > невнятными перспективами всего этого начинания. Скорее все чего касаются менеджеры и все что удается монетизировать неизбежно становится маргинальной хренотенью ... > ...просто потому что BTRFS сможет то что и ZFS. И даже больше. > И лучше. Чем будут после этого зарабатывать указанные коммерческие конторы - > вопрос интересный. И что случится с этой кодовой базой - тоже > интересно, да. Поскольку если 2 коммерческие конторы окажутся без дохода от > этого начинания и выбросят его на свалку - тогда чего? Как > с опенсолярой и ораклем, да? :) Ну не летают кони у Оракла ... корма не те :-)))
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	108. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Сен-12, 05:59
	> Еще одна FS в коллекцию недофс линукса ... Ну да, и только вы на белом коне. Сферическом. В вакууме. А ничего что у всяких соляр и бздей на выбор полторы ФС, при том одна переросточная и тормозная ынтырпрайзятина ZFS а вторая - ископаемое с архитектурой каменноугольного периода UFS. Еще есть всякие там шиндошсы, но там тоже ничего интересного. Совсем античный FAT да тормозной и старинный NTFS. Ну и все. Еще есть UDF (правда толку то с него?) и странная хрень exfat. Смесь ископаемых и совсем ископаемых. Ну в общем покажите ФС которые не "недо" по вашему мнению тогда. > Скорее все чего касаются менеджеры и все что удается монетизировать неизбежно > становится маргинальной хренотенью ... Где вы такую дурь берете? И кстати просветите, в чем состоит монетизация BTRFS? То что она нужна толпе народа, в том числе и для всевозможных дел приносящих бабки - так это нормально вполне. Не верите? Попробуйте поработать на регулярной основе без зарплаты и расскажите как вам оно. Тогда глядишь и других за зарабатывание денег само по себе осуждать не захочется. Просто зарабатывать можно по разному. Есть хорошие методы, а есть не очень. >> этого начинания и выбросят его на свалку - тогда чего? Как >> с опенсолярой и ораклем, да? :) > Ну не летают кони у Оракла ... корма не те :-))) Да, сферические кони в вакууме - это прерогатива адептов *BSD :)
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	116. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от nagual (ok) on 21-Сен-12, 08:16
	> Ну да, и только вы на белом коне. Сферическом. В вакууме. А > ничего что у всяких соляр и бздей на выбор полторы ФС, > при том одна переросточная и тормозная ынтырпрайзятина ZFS а вторая - > ископаемое с архитектурой каменноугольного периода UFS. Еще есть всякие там шиндошсы, > но там тоже ничего интересного. Совсем античный FAT да тормозной и > старинный NTFS. Ну и все. Еще есть UDF (правда толку то > с него?) и странная хрень exfat. Смесь ископаемых и совсем ископаемых. > Ну в общем покажите ФС которые не "недо" по вашему мнению > тогда. Судя по этом бреду месье не часто инсталит ОС ... > Где вы такую дурь берете? И кстати просветите, в чем состоит монетизация > BTRFS? То что она нужна толпе народа, в том числе и > для всевозможных дел приносящих бабки - так это нормально вполне. Не > верите? Попробуйте поработать на регулярной основе без зарплаты и расскажите как > вам оно. Тогда глядишь и других за зарабатывание денег само по > себе осуждать не захочется. Просто зарабатывать можно по разному. Есть хорошие > методы, а есть не очень. Вай вай да месье маркетолог :)) внимательнее нужно быть оракля как раз планирует загубить бтр. > Да, сферические кони в вакууме - это прерогатива адептов *BSD :) У вандовс самая быстрая ФС потому что операция линейного чтения всегда быстрее :)) кстати.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	119. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Сен-12, 12:17
	>> Ну в общем покажите ФС которые не "недо" по вашему мнению тогда. > Судя по этом бреду месье не часто инсталит ОС ... Иногда - инсталлит. Но не слишком часто, ибо не является эникейщиком протирающим мышки. > Вай вай да месье маркетолог :)) внимательнее нужно быть оракля как раз > планирует загубить бтр. Зачем бы это ораклу? Когда нечто происходит, всегда есть вопрос: кому это выгодно и кто в этом заинтересован. Оракл заинтересован в BTRFS как в подстилке для своих БД. >> Да, сферические кони в вакууме - это прерогатива адептов *BSD :) > У вандовс самая быстрая ФС потому что операция линейного чтения всегда быстрее :)) кстати. Ваши данные протухли. Не, если сравнивать только с архаичным UFS и тормозным ZFS - вы даже может быть и правы. А если вспомнить о "недо-ФС" Linux и взять например, XFS то на больших файлах он обставит NTFS как делать нефиг. К тому же он намного меньше фрагментируется, там с фрагментацией борятся очень здорово. А если еще и более чем 1 диск в хранилище, XFS просто эпически рвет всех. Просто потому что ориентирован на параллельный доступ с его группами аллокации и поэтому почти всегда юзает диски параллельно, независимо от того как именно это хранилище сделано. EXT4 тоже спуску как-то никому давать не намерен, как миниимум на 1-дисковых конфигурациях. Будучи в отличие от древней битмап-ориентированной NTFS-ины экстентным, он не нуждается в педалинге гигантских битовых карт на каждый пшик. Стоит ли говорить что работает сие не в пример шустрее в ряде случаев? Вообще, очень позитивная и резвая ФС вышла. По сути это лучшее что можно выжать из заюзанных технологий. А btrfs мало того что не особо то и тормознут и вполне меряется с ext4 и xfs (пруфлинк: http://www.phoronix.com/scan.php?page=article&item=ubuntu_12... - небольшой недавний бенчик, вполне обычный вроде, без каких либо особенностей) так еще и фич предлагает много. Но вы мне и моим тестовым BTRFSным томам можете конечно рассказать о том как там все плохо, я с удовольствием послушаю о том как очередной бсдшник лечит про сферических коней в вакууме. Которых оказывается еще и кормят плохо.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	121. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 21-Сен-12, 12:30
	> Зачем бы это ораклу? Когда нечто происходит, всегда есть вопрос: кому это > выгодно и кто в этом заинтересован. Оракл заинтересован в BTRFS как > в подстилке для своих БД. Какой то месье не замечательный ... ни ... не замечет что лушим друзьям оракла производителям рейд массивов ну на... ненужен бесплатный софтварный конкурент. >[оверквотинг удален] > как именно это хранилище сделано. EXT4 тоже спуску как-то никому давать > не намерен, как миниимум на 1-дисковых конфигурациях. Будучи в отличие от > древней битмап-ориентированной NTFS-ины экстентным, он не нуждается в педалинге гигантских > битовых карт на каждый пшик. Стоит ли говорить что работает сие > не в пример шустрее в ряде случаев? Вообще, очень позитивная и > резвая ФС вышла. По сути это лучшее что можно выжать из > заюзанных технологий. А btrfs мало того что не особо то и > тормознут и вполне меряется с ext4 и xfs (пруфлинк: http://www.phoronix.com/scan.php?page=article&item=ubuntu_12... > - небольшой недавний бенчик, вполне обычный вроде, без каких либо особенностей) > так еще и фич предлагает много. Я думал очевидно что скорость считывания файла после дефрагментации с NTFS будет выше чем с любой фс, не ? Месье неисилил школьный курс физики? И при чем тут райды? xfs быстрее и чем железные решения ? Несомневаюсь. > Но вы мне и моим тестовым BTRFSным томам можете конечно рассказать о > том как там все плохо, я с удовольствием послушаю о том > как очередной бсдшник лечит про сферических коней в вакууме. Которых оказывается > еще и кормят плохо. Для того чтоб раз и навсегда развеять бред красноглазых линуксаторов о пльзе btrfs в часности и linux вообще могу сказать - если у вас меньше чем 2GB оперативки не ставьте свой линукс на btrfs и вы сэкономите время на переустановку.
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	124. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Сен-12, 12:55
	> Какой то месье не замечательный ... ни ... не замечет что лушим друзьям оракла У оракла есть друзья? А я то думал что при капитализме человек человеку - волк и конкурент. И если можно набить карман лишний раз - это следует сделать. А тут прямо какие-то новые открытия. > производителям рейд массивов ну на... ненужен бесплатный софтварный конкурент. Как бы интересы оракла слабо пересекаются с производителями массивов. Им чем больше у них баз купят, тем лучше. И чем проще, быстрее и дешвле все остальное и чем проще оно админится и лучше работает - тем по идее выше спрос на БД. Так что в принципе btrfs вполне хорошо вписывается в их желание продавать их БД. Более того, желающие вполне могут покупать и аппаратные рэйд массивы, поверх которых раскладывать уютненький btrfs. Ничему не противоречит особо. Так что кто хотел аппаратный RAID - пойдет да купит его. А btrfs - просто полезняшка для админов этакая. > Я думал очевидно что скорость считывания файла после дефрагментации с NTFS будет > выше чем с любой фс, не ? Чего бы ради? В случае "сферического коня в вакууме", когда файл лежит идеально непрерывно, одним фрагментом - практически любая ФС будет читать со скоростью примерно равной RAW доступу к диску. Стормозить при этом - это еще суметь надо. Не на чем тормозить :). Так что я ставлю на то что большинство ФС в этом случае дружно покажут результат крайне близкий к физическим пределам накопителя при чтении этих блоков просто так, не в рамках разбора ФС. Алсо, бывает такая вещь как SSD. Там важнее сколько операций делает ФС и какой от этого оверхед. Потому что seek time накопителя близок к нулю, скорости выше, так что начинает сильно влиять то сколько лишних операций проделает ФС. И bitmap-based ФС в этом плане опять оказываются в полной опе. Потому что педалить большие битовые карты - не очень то и быстро. Основная проблема с указанным случаем - это сферический случай в вакууме, который почти никогда не случается в реальности и потому малоинтересен на практике. > Месье неисилил школьный курс физики? Мсье осилил институтский, далеко за пределами ваших самых смелых ожиданий. Поучите меня физике, особенно как раз разделам механики и электричества. Удачи в этом начинании :). Вот только я то как раз обычно достаточно отчетливо представляю себе во что именно физически и логически трансформируется то или иное  действо в цифровых девайсах. > И при чем тут райды? xfs быстрее и чем железные решения ? Несомневаюсь. А железные решения ничего такого фантастического не делают. Кроме того у них есть недостаток: они оперируют проприетарным форматом метаданных, так что если не дай боже железка вылетела а запасной такой же у вас нет - вы вообще остаетесь без доступа к данным. Резко, больно и внезапно. Кстати да, вон у гугля распределенная сетевая ФС обслуживает всю планету. Софтварно. Удачи вам собрать аппаратный RAID который осилит долбеж юзерами со всей планет. Ы? :) > Для того чтоб раз и навсегда развеять бред красноглазых линуксаторов о пльзе > btrfs в часности и linux вообще могу сказать - если у вас меньше чем 2GB оперативки > не ставьте свой линукс на btrfs и вы сэкономите время на переустановку. Не надо переносить проблемы ZFS и BSD на пингвины. Их там нет, в отличие от. Это у саней полностью отдельный кэш, живущий отдельно от системного зачем-то. И тормозной дизайн ФС, который без подпорки диким количеством кэша выставляет напоказ свою слоупочную натуру. Но в Linux и BTRFS нет ни одной из этих проблем.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	125. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 21-Сен-12, 13:12
	> У оракла есть друзья? А я то думал что при капитализме человек > человеку - волк и конкурент. И если можно набить карман лишний > раз - это следует сделать. А тут прямо какие-то новые открытия. Что то не везет вам в думании ... > Как бы интересы оракла слабо пересекаются с производителями массивов. Им чем больше > у них баз купят, тем лучше. Неужели после всего вышенаписанного для месье открытие что весь капитализм как явление природы принадлежит узкой группе сильно ограничсенных людей? Месье так и не заметил в силу своей природной незамечательности что иногда интересы очень разных корпараций вдруг удивительно сочетаются? > И чем проще, быстрее и > дешвле все остальное и чем проще оно админится и лучше работает > - тем по идее выше спрос на БД. Так что в > принципе btrfs вполне хорошо вписывается в их желание продавать их БД. > Более того, желающие вполне могут покупать и аппаратные рэйд массивы, поверх > которых раскладывать уютненький btrfs. Ничему не противоречит особо. Так что кто > хотел аппаратный RAID - пойдет да купит его. А btrfs - > просто полезняшка для админов этакая. Ну да ZFS рекомендуюут ставиь не на райды а на диски, уж остальное додумайте сами ... > Чего бы ради? В случае "сферического коня в вакууме", когда файл лежит > идеально непрерывно, одним фрагментом - практически любая ФС ... Дальше можно не читать. Странно что при всей своей эрудиции месье не понимает что файл идеально непрерывно может лежать только после дефрагментации и только в ntfs или fat :))) а для других фс даже дефрагментаторов нет :))) > Мсье осилил институтский, далеко за пределами ваших самых смелых ожиданий. Поучите меня > физике, особенно как раз разделам механики и электричества. Удачи в этом > начинании :). Вот только я то как раз обычно достаточно отчетливо > представляю себе во что именно физически и логически трансформируется то или > иное  действо в цифровых девайсах. Неужели месье асилил Левашева ? > А железные решения ничего такого фантастического не делают. Кроме того у них > есть недостаток: они оперируют проприетарным форматом метаданных, так что если не > дай боже железка вылетела а запасной такой же у вас нет > - вы вообще остаетесь без доступа к данным. Резко, больно и > внезапно. Да в курсе, работали  с хецнером и улетающими райдами... :))) Вот потому то zfs и нужно ставить на диски, а не на рейды - глюки контроллеров сразу идут лесом. > Кстати да, вон у гугля распределенная сетевая ФС обслуживает всю планету. Софтварно. > Удачи вам собрать аппаратный RAID который осилит долбеж юзерами со всей > планет. Ы? :) К чему это ... наверно обострение. > Не надо переносить проблемы ZFS и BSD на пингвины. Их там нет, > в отличие от. Это у саней полностью отдельный кэш, живущий отдельно > от системного зачем-то. И тормозной дизайн ФС, который без подпорки диким > количеством кэша выставляет напоказ свою слоупочную натуру. Но в Linux и > BTRFS нет ни одной из этих проблем. Так или иначе но linux на btrfs на 1-2 гига оперы это полный П...ц Ну если хотите в этом сами убедиться - попробуйте.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	129. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 22-Сен-12, 07:06
	> Что то не везет вам в думании ... Да ладно вам, нормально вполне. Кстати понимание работы этой механики еще не означает одобрение такого подхода и/или симпатий ко многим методам работы капиталистов. > заметил в силу своей природной незамечательности что иногда интересы очень разных > корпараций вдруг удивительно сочетаются? Они вдруг удивительно сочетаются лишь до той поры пока это выгодно. А как только дружба начинает мешать выгоде - так сразу же вчерашний друг-союзник радостно пыряется кинжалом в спину, приговаривая что-то там про "Это просто бизнес, ничего личного!". Поэтому глядя на улыбчивые физиономии друзей-капиталистов не забывайте о том что они улыбаясь и дружа с удовольствием прокатят "ближнего своего" и пырнут в спину, если это сулит хоть какую-то прибыль. При том чем больше прибыль, тем беспринципнее капиталист прет по головам и трупам. Природа настоящего капиталиста такова. >> хотел аппаратный RAID - пойдет да купит его. А btrfs - >> просто полезняшка для админов этакая. > Ну да ZFS рекомендуюут ставиь не на райды а на диски, уж остальное додумайте сами ... Да, я додумал: вы зациклены на *bsd и ZFS. И никак не можете понять, что архитектурно btrfs мало того что не слишком похож на zfs, так еще исправляет ряд его упущений и обладает рядом настроек которые в принципе позволят ему достаточно сухо и комфортно жить на весьма разных по своей природе накопителях. >> Чего бы ради? В случае "сферического коня в вакууме", когда файл лежит >> идеально непрерывно, одним фрагментом - практически любая ФС ... > Дальше можно не читать. Странно что при всей своей эрудиции месье не > понимает что файл идеально непрерывно может лежать только после дефрагментации Мсье сообщает что файл может лежать непрерывно и при просто быстрой записи файла на незасранный том. Более того, качественно реализованный аллокатор активно стремиться добиться именно такого случая настолько насколько позволяют реалии свободного места на диске. Чем больше свободного места на диске и меньше фрагментировано свободное место, тем лучше это получается. В клиническом случае если мы резво пишем файл на только что созданную пустую ФС, он скорее всего будет выложен идеально линейно. >  и только в ntfs или fat :))) Ну нихрена себе ламерство. А какие законы природы запрещают файлам лежать линейно на остальных ФС? Чисто теоретически, структуры большинства ФС это вполне допускают и приветствуют. Чисто практически - уж насколько получится. И даже мелкие неидеальности типа seek в сторону 1 раз на 100Мб мало чего меняют. Ну будет не 100% скорости а 99%, допустим. Никто и не заметит особой разницы. Фрагментация являет собой проблему когда том становится загажен и не удается выкроить непрерывный кусок. > а для других фс даже дефрагментаторов нет :))) Во первых, можно отдефрагать неудачно разложенный файл просто его копированием и удалением старого размазанного варианта, например. При этом используется свойство аллокатора пытаться разложить файл максимально линейно. Таким манером можно частично отдефрагментировать практически любую "классическую" ФС, как минимум для наиболее злободневных файлов. Лишь бы свободного места было много, иначе аллокатору негде будет развернуть деятельность по оптимизации и получится опа. Такое помогает от неудачно разместившихся файлов, если совсем опа в ФС еще не наступила. По поводу чего и не советуют тома забивать более чем на 70-90%. Иначе сильно фрагментируется свободное место и том коллапсирует. Что будет - отлично видно на примере изена, с его легендарными 6Мб/сек на шпиндель :) Во вторых, для ext4 дефрагер есть. С неких пор поставляется с остальными утилитками для файловой системы. Называется e4defrag. В свежих выпусках дистров обычно есть сразу. В третьих, в случае CoW файловых систем обязан быть garbage collector разгребающий устаревшие неиспользуемые блоки. Иначе CoW логика просто забьет том до отказа. А раз он всяко есть и кантует блоки - пусть заодно и дефрагит в процессе! В btrfs этот достаточно очевидный факт до разработчиков дошел и там GC совмещен с дефрагером, по поводу чего у btrfs есть встроенный дефраг. В ZFS такого не было, да. Почему? Наверное потому что это одна из первых CoW ФС. Так что ваши сведения кривоваты и староваты. FAIL. > Неужели месье асилил Левашева ? Не припоминаю такой фамилии. Но мсье знает некоторые другие фамилии. Например, Ланау и Лившиц. Забавные дяденьки - спокойно считают в уме интегралы на 2 страницы и полагают что все остальные могут не хуже, поэтому просто не приводят подобные преобразования в своей книжке :). Ну а в плане электроникм мсье попалась достаточно годная книжка по основам полупроводниковой схемотехники от У. Титце и К. Шенка (в переводе на русский, они изначально немцы). Все основы изложенные там до сих пор вполне актуальны. И да, смею заверить что грубо прикинуть как будет разложен файл, хоть немного преставляя себе логику работы ФС - я в состоянии. Как в состоянии предсказать некоторые сценарии, например то что получилось на томе у какого-нибудь изена :). Я даже не видя того что у него на томе могу примерно представить себе как сие выглядит, если отрисовать занятость тома. ИЧСХ, оно как-то так обычно и оказывается. >> - вы вообще остаетесь без доступа к данным. Резко, больно и внезапно. > Да в курсе, работали  с хецнером и улетающими райдами... :))) Вот > потому то zfs и нужно ставить на диски, а не на рейды - глюки контроллеров > сразу идут лесом. Собственно, одна из причин по которым не все юзают аппаратные рэйды. А также ФС с управлением томами самолично имеет больше шансов разложить данные по дискам более удачно если природа хранилища не скрыта от нее железкой. А так - оракл может чисто номинально дружить с кем угодно. Но в конечном итоге они базы продают. Рэйды им могут быть интересны, если это помогает базы продавать. Но в целом им перпендикулярно, существуют рэйды или нет. Это вообще кастомеровские проблемы и проблемы сторонних контор. А их интересуют продажи баз. Продастся ли при этом аппаратный рэйд - уж точно не проблема оракла. Поэтому называя вещи своими именами, ораклу более-менее все-равно. Тем более что если некое хранилище работает, то btrfs поверх него ничему не противоречит. Тем более что в btrfs настраивается как именно хранить данные и метаданные. Например если кто уверен что хранилище офигеть какое надежное - он может выключить зеркалирование метаданных, например. Скорость возрастет. А надежность... ну если хранилище надежное - сами знали на что шли. > К чему это ... наверно обострение. Да, обострение чувства голода. Кушать хочется после того как втирают всякое ламерство про фрагментацию :) > Так или иначе но linux на btrfs на 1-2 гига оперы это полный П...ц > Ну если хотите в этом сами убедиться - попробуйте. Это вы про ZFS. Не надо переносить его свойства на btrfs. Я его ради лулзов запускал на железке с 64Мб и хилым процом. Даже работало. Хотя ext4 показал себя несколько быстрее в такой конфигурации и меньше нагружал проц, что для мелкой железки актуально. А на типовом девайсе типа нотика с 2Гб оперативы оно себя будет чувствовать вполне по королевски. Оно в целом помедленнее ext4 (который вышел на удивление шустрым), но в последнее время основательно подтянули. Я ссылочку на недавние бенчи привел.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	131. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 22-Сен-12, 10:12
	> Они вдруг удивительно сочетаются лишь до той поры пока это выгодно. А > как только дружба начинает мешать выгоде - так сразу же вчерашний > друг-союзник радостно пыряется кинжалом в спину, приговаривая что-то там про "Это > просто бизнес, ничего личного!". Поэтому глядя на улыбчивые физиономии друзей-капиталистов > не забывайте о том что они улыбаясь и дружа с удовольствием > прокатят "ближнего своего" и пырнут в спину, если это сулит хоть > какую-то прибыль. При том чем больше прибыль, тем беспринципнее капиталист прет > по головам и трупам. Природа настоящего капиталиста такова. Нет никакой необходимости записывать свои открытия в форуме. > Да, я додумал: вы зациклены на *bsd и ZFS. И никак не > можете понять, что архитектурно btrfs мало того что не слишком похож > на zfs, так еще исправляет ряд его упущений и обладает рядом > настроек которые в принципе позволят ему достаточно сухо и комфортно жить > на весьма разных по своей природе накопителях. Мы тут много обсуждали натройки zfs но ниразу не видели настроек btrfs ... странно. > Мсье сообщает что файл может лежать непрерывно и при просто быстрой записи > файла на незасранный том. Более того, качественно реализованный аллокатор активно стремиться > добиться именно такого случая настолько насколько позволяют реалии свободного места на > диске. Чем больше свободного места на диске и меньше фрагментировано свободное > место, тем лучше это получается. В клиническом случае если мы резво > пишем файл на только что созданную пустую ФС, он скорее всего > будет выложен идеально линейно. Последняя враза явная лож :))) как минимум для половины фс. > Ну нихрена себе ламерство. А какие законы природы запрещают файлам лежать линейно > на остальных ФС? Чисто теоретически, структуры большинства ФС это вполне допускают > и приветствуют. Чисто практически - уж насколько получится. И даже мелкие > неидеальности типа seek в сторону 1 раз на 100Мб мало чего > меняют. Ну будет не 100% скорости а 99%, допустим. Никто и > не заметит особой разницы. Фрагментация являет собой проблему когда том становится > загажен и не удается выкроить непрерывный кусок. Вы что то упустили в теории. > Во первых, можно отдефрагать неудачно разложенный файл просто его копированием и удалением > старого размазанного варианта, например. При этом используется свойство аллокатора пытаться > разложить файл максимально линейно. Таким манером можно частично отдефрагментировать > практически любую "классическую" ФС, как минимум для наиболее злободневных файлов. Лишь > бы свободного места было много, иначе аллокатору негде будет развернуть деятельность > по оптимизации и получится опа. Такое помогает от неудачно разместившихся файлов, > если совсем опа в ФС еще не наступила. По поводу чего > и не советуют тома забивать более чем на 70-90%. Иначе сильно > фрагментируется свободное место и том коллапсирует. Что будет - отлично видно > на примере изена, с его легендарными 6Мб/сек на шпиндель :) Месье может назвать хоть одну фс в линуксе которая попадает под его критерий- практически любую "классическую" ? > Во вторых, для ext4 дефрагер есть. С неких пор поставляется с остальными > утилитками для файловой системы. Называется e4defrag. В свежих выпусках дистров обычно > есть сразу. Есть но до виндозного ему еще очень далеко :)) > В третьих, в случае CoW файловых систем обязан быть garbage collector разгребающий > устаревшие неиспользуемые блоки. Иначе CoW логика просто забьет том до отказа. > А раз он всяко есть и кантует блоки - пусть заодно > и дефрагит в процессе! В btrfs этот достаточно очевидный факт до > разработчиков дошел и там GC совмещен с дефрагером, по поводу чего > у btrfs есть встроенный дефраг. В ZFS такого не было, да. > Почему? Наверное потому что это одна из первых CoW ФС. Палундра в ZFS нет дефрагментатора %) > Не припоминаю такой фамилии. Я почему то не ожидал другова ответа :-)) >Но мсье знает некоторые другие фамилии. Например, Ланау > и Лившиц. Забавные дяденьки - спокойно считают в уме интегралы на > 2 страницы и полагают что все остальные могут не хуже, поэтому > просто не приводят подобные преобразования в своей книжке :). И какая практическая польза от этой ментальной маструбации ? > Это вы про ZFS. Не надо переносить его свойства на btrfs. Я > его ради лулзов запускал на железке с 64Мб и хилым процом. > Даже работало. Хотя ext4 показал себя несколько быстрее в такой конфигурации > и меньше нагружал проц, что для мелкой железки актуально. А на > типовом девайсе типа нотика с 2Гб оперативы оно себя будет чувствовать > вполне по королевски. Оно в целом помедленнее ext4 (который вышел на > удивление шустрым), но в последнее время основательно подтянули. Я ссылочку на > недавние бенчи привел. Оно себя будет чуствовать по королевски пока вы не запустите лису или что там у вас на ноуте, тоесть пока 2 гига памяти свободны и могут использоваться под кеш. С счастью большинство читателей не станут тратить время на этот бред. В целом это называется калейдоскапический идиотизм. Диагноз гуглится.
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	142. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 09:47
	> Оно себя будет чуствовать по королевски пока вы не запустите лису или > что там у вас на ноуте, тоесть пока 2 гига памяти > свободны и могут использоваться под кеш. Бугыг. Только хотел этому кексу написать "а ты текущую из всех щелей лису на что-нибудь другое менять пробовал" - как он сам сразу и спалился.
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	200. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 17:58
	> Нет никакой необходимости записывать свои открытия в форуме. Ну я не виноват что вы не знаете элементарных вещей, приходится разъяснять и в ротик класть. Я бы предпочел этого не делать, честно-честно. >> настроек которые в принципе позволят ему достаточно сухо и комфортно жить >> на весьма разных по своей природе накопителях. > Мы тут много обсуждали натройки zfs но ниразу не видели настроек btrfs ... странно. Вообще-то это было про btrfs. А то что вы не видели - не удивительно. Вы видите только то что хотите видеть, а не то что есть на самом деле. Вы всегда пытаетесь выдать желаемое за действительное и ужасно палитесь на различных нестыковках :) >> пишем файл на только что созданную пустую ФС, он скорее всего будет выложен идеально линейно. > Последняя враза явная лож :))) Хоть это и не форум русского языка, но орфографические ошибки за которые ученикам 3 класса лепят двойки - напрягают. Вообще-то, "ложь" пишется с мягким знаком на конце. > как минимум для половины фс. Почему для половины? А не четверти? Или трех восьмых? Обоснуйте. Столь фундаментальная заява должна иметь под собой простое и понятное даже кухарке обоснование. Со своей стороны я могу себе представить как на свежесозданной ФС файл будет разложен линейно вплоть до почти полной емкости диска. Просто потому что ничего не валяется на проходе и не мешает его так раскладывать. >> не заметит особой разницы. Фрагментация являет собой проблему когда том становится >> загажен и не удается выкроить непрерывный кусок. > Вы что то упустили в теории. Что именно? Укажите и обоснуйте. С моей колокольни это выгялдит так: скорость заметно падает если диск заметный процент времени проводит делая перемещения голов нежели чтение данных. Такая формулировка не исключает фрагментацию, но показывает зависимость между скоростью чтения файла и расположением фрагментов. Это подтверждено многочисленными наблюдениями, изучением расположения файлов соотв. утилитами и просто здравым смыслом. > Месье может назвать хоть одну фс в линуксе которая попадает под его > критерий- практически любую "классическую" ? Например, ext4 (в принципе и все ext2...ext4). JFS. До некоторой степени - XFS. У него правда есть allocation groups - он как раз не совсем линейно раскладывает файлы, нарезая их кусками. Но куски большие и по этому поводу скорость не только не проседает, но и вообще, это очень шустрая ФС. Особенно - в плане работы с большими файлами как раз. А за счет такой нарезки оно выигрывает в скорости на многодисковых хранилищах. >> утилитками для файловой системы. Называется e4defrag. В свежих выпусках дистров обычно есть сразу. > Есть но до виндозного ему еще очень далеко :)) Да, гламурных кнопочек нету. Какая трагедия. >> Почему? Наверное потому что это одна из первых CoW ФС. > Палундра в ZFS нет дефрагментатора %) Да вон iZEN уже ощущает результат. И даже если он осовободит место, сильно лучше может и не стать. В общем то нет простого метода расчистить такое без дефрагментатора. >> Не припоминаю такой фамилии. > Я почему то не ожидал другова ответа :-)) Наверное потому что это достаточно специфичный субъект. В то время как меня интересуют в основном более-менее проверенные фактами и экспериментами вещи, а не просто домыслы. По этой причине я вообще достаточно осторожно отношусь к любым теориям которые не подтверждены практикой и/или когда теоретический результат сильно отличается от практически наблюдаемого. >> просто не приводят подобные преобразования в своей книжке :). > И какая практическая польза от этой ментальной маструбации ? Мне нравится узнавать об устройстве мира. Этого достаточно. Нет, это не даст миллионов в кармане. И даже набить брюхо не поможет. Просто у некоторых людей интересы простираются чуть дальше. > Оно себя будет чуствовать по королевски пока вы не запустите лису или что там > у вас на ноуте, тоесть пока 2 гига памяти свободны и могут использоваться под кеш. А оно и при небольшом кеше не сдувается так как ZFS. Вы прикиньте? Да, там нормальный экстентный аллокатор а не черт знает что с блоками переменного размера. > С счастью большинство читателей не станут тратить время на этот бред. В > целом это называется калейдоскапический идиотизм. Диагноз гуглится. Да уж. Диагноз называется "BSDшник-пионер".
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	202. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 18:28
	> ... приходится разъяснять > и в ротик класть. Я бы предпочел этого не делать, честно-честно. И не делайте, тем более половина неверная ... > Вообще-то это было про btrfs. А то что вы не видели - > не удивительно. Вы видите только то что хотите видеть, а не > то что есть на самом деле. Вы всегда пытаетесь выдать желаемое > за действительное и ужасно палитесь на различных нестыковках :) Наверно поиск по Crtl F по маске sysctl тоже находит только то что хочет ... Поделитесь с нами тонкостью настройки своей чудо btrfs или опять одна лирика ? > Хоть это и не форум русского языка, но орфографические ошибки за которые > ученикам 3 класса лепят двойки - напрягают. Вообще-то, "ложь" пишется с > мягким знаком на конце. Судя по вашим познаниям в русском языке с информационными технологиями вы сталкиваетесь не часто ... > Со своей стороны я могу себе представить как на свежесозданной ФС файл > будет разложен линейно вплоть до почти полной емкости диска. Просто потому > что ничего не валяется на проходе и не мешает его так > раскладывать. В UFS и ZFS это точно не так :-))) >>> не заметит особой разницы. Фрагментация являет собой проблему когда том становится > Что именно? Укажите и обоснуйте. С моей колокольни это выгялдит так: скорость > заметно падает если диск заметный процент времени проводит делая перемещения голов > нежели чтение данных. Такая формулировка не исключает фрагментацию, но показывает зависимость > между скоростью чтения файла и расположением фрагментов. Это подтверждено многочисленными > наблюдениями, изучением расположения файлов соотв. утилитами и просто здравым смыслом. Все эти построения основаны на необходимости считывать данные которые могут хотябы потенциально быть записаны последовательно. Вот тут здравый смысл подсказывает что либо они принадлежат одному файлу либо это удивительное совпадение которых в реальной жизни не бывает. > Да, гламурных кнопочек нету. Какая трагедия. Как насчет объединения свободного пространства ? > Наверное потому что это достаточно специфичный субъект. В то время как меня > интересуют в основном более-менее проверенные фактами и экспериментами вещи, а не > просто домыслы. По этой причине я вообще достаточно осторожно отношусь к > любым теориям которые не подтверждены практикой и/или когда теоретический результат сильно > отличается от практически наблюдаемого. Неужели вам удалось поймать нейтрино? > Мне нравится узнавать об устройстве мира. Этого достаточно. Нет, это не даст > миллионов в кармане. И даже набить брюхо не поможет. Просто у > некоторых людей интересы простираются чуть дальше. В двух словах пользы никакой :-))) > А оно и при небольшом кеше не сдувается так как ZFS. Вы > прикиньте? Да, там нормальный экстентный аллокатор а не черт знает что > с блоками переменного размера. Именно переменные блоки дают преимущества над железными RAID. У btrfs его нет увы, поэтому фаны линукса начинают ругать переменные блоки ... знакомо :-))) > Да уж. Диагноз называется "BSDшник-пионер". Ох уж эти маркетологи.
	Ответить | Правка | ^ к родителю #200 | Наверх | Cообщить модератору

	248. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 21:01
	> И не делайте, тем более половина неверная ... Не так уж плохо по сравнению с вашими сообщениями. У вас КПД намного хуже, увы. >> то что есть на самом деле. Вы всегда пытаетесь выдать желаемое >> за действительное и ужасно палитесь на различных нестыковках :) > Наверно поиск по Crtl F по маске sysctl тоже находит только то что хочет ... Не совсем понимаю при чем тут ваш sysctl. Что за перевод стрелок? Из ярких примеров - вы откуда-то взяли про 2 гига потребные btrfs. Явно путая его с ZFS или просто откровенно завирая на форуме. > Поделитесь с нами тонкостью настройки своей чудо btrfs или опять одна лирика ? Тонкости настройки более-менее описаны в мануале. Пересказывать забесплатно ман всяким ламерюгам желания совершенно нет. Вот если вы опишете конфигурацию и что хотите получить - тогда можно будет подумать что можно покрутить. И то большинство твиков очевидны и я не вижу смысла метать бисер. > Судя по вашим познаниям в русском языке с информационными технологиями вы сталкиваетесь > не часто ... Просто если некто изъясняется на уровне папуаса, возникает ощущение что у него и интеллект в целом на уровне папуаса остался. Вон например тут рядом изен - типовой папуас рассказывающий про то как работает микроволновка: кладем еду, жмем это и это - она жужжит - получается еда. Во. При слове "магнетрон" или "волны" у папуаса случается кернелпаник :) >> Со своей стороны я могу себе представить как на свежесозданной ФС файл >> будет разложен линейно вплоть до почти полной емкости диска. Просто потому >> что ничего не валяется на проходе и не мешает его так раскладывать. > В UFS и ZFS это точно не так :-))) На каком-то фундаментальном уровне они могли бы изобразить по крайней мере что-то близкое к этому. Если это не так - ну ой, сочувствую, плохо значит там с аллокаторами дела. Я в этом не виноват. И если для CoW это еще можно понять (хотя опять же, а что мешает класть фрагменты друг за другом последовательно?) то для "классики" это вообще трындец какой-то. >> наблюдениями, изучением расположения файлов соотв. утилитами и просто здравым смыслом. > Все эти построения основаны на необходимости считывать данные которые могут хотябы > потенциально быть записаны последовательно. Так мы вроде и говорили о идеальном случае когда 1 файл пишется на пустую ФС линейно. Большинство ФС его при этом весьма линейно и впихнет. При этом почти любая ФС покажет скорость записи и чтения сравнимую с скоростью работы диска в режиме RAW доступа без разбора ФС. Просто потому что в этой ситуации нечему тормозить. > Вот тут здравый смысл подсказывает что либо они принадлежат одному файлу > либо это удивительное совпадение которых в реальной жизни не бывает. А тут вы попались на невнимательности, поскольку это было про случай столь симпатичных вам сферических коней в вакууме - создаем файл на пустой ФС и смотрим какая скорость. >> Да, гламурных кнопочек нету. Какая трагедия. > Как насчет объединения свободного пространства ? Хм, вот это не помню, может и не умеет. В принципе объединение пространства неплохая идея, но в конечном итоге это уже относительно некритичный улучшайзер. Если уж посмотреть на бсды, там и такого нет. >> отличается от практически наблюдаемого. > Неужели вам удалось поймать нейтрино? Их в общем то нынче уже регулярно ловят, если что. Можно считать что на промышленной основе. Самолично не ловил, т.к. это требует слишком монструозного реквизита, который на дороге не валяется. Зато методика опробована кучей различных команд и работает. Нейтрино слабо взаимодействуют с веществом. Поэтому чтобы хоть что-то поймать, вещества должно быть много. Значит, установка будет большой. >> некоторых людей интересы простираются чуть дальше. > В двух словах пользы никакой :-))) Для желающих просто набить брюхо - ну да. Впрочем ваши бзди примерно так же в этом плане. Так что странно что вы ими умудряетесь при этом пользоваться. Хотя судя по тому что вы так хорошо знаете виндовый дефрагер, вероятно как десктоп ваша любимая бздя действительно не фонтан. > Именно переменные блоки дают преимущества над железными RAID. А обосновать столь громкую заяву? В чем преимущества, откуда получаются, чем обусловлены на уровне физики и логики процесса? > У btrfs его нет увы, У btrfs есть экстенты. Чем-то похожее по смыслу, но у них есть один важный нюанс. Они не ограничены 128Кб (дефолт) или 1Мб (максимум) как в ZFS. Что это означает? То что при непрерывной записи больщих файлов большими кусками будет лопатиться меньше метаданных. Так что если некто хочет записать кусок "хренадцать мегабайт", btrfs вполне может оформить его его как ОДНУ запись экстента. А вот ZFS при этом будет вынужден перелопатить куда больше метаданных, помечая все хренадцать блоков как занятых. Что быстрее: пометить регион в хренадцать мегов как занятый за 1 присест или за хренадцать раз? Вывод очевиден. Да и бенчмарки недвусмысленно намекают. > поэтому фаны линукса начинают ругать переменные блоки ... знакомо :-))) Так экстенты - то же самое по смыслу, только без тупых ограничений на максимальный размер в всего 128 кило/1 мег. >> Да уж. Диагноз называется "BSDшник-пионер". > Ох уж эти маркетологи. Да уж, основательно промыли ваши мозги маркетинговым буллшитом.
	Ответить | Правка | ^ к родителю #202 | Наверх | Cообщить модератору

	261. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 22:04
	> У btrfs есть экстенты. Чем-то похожее по смыслу, но у них есть > один важный нюанс. Они не ограничены 128Кб (дефолт) или 1Мб (максимум) > как в ZFS. Что это означает? То что при непрерывной записи > больщих файлов большими кусками будет лопатиться меньше метаданных. Так что если > некто хочет записать кусок "хренадцать мегабайт", btrfs вполне может оформить его > его как ОДНУ запись экстента. А вот ZFS при этом будет > вынужден перелопатить куда больше метаданных, помечая все хренадцать блоков как занятых. > Что быстрее: пометить регион в хренадцать мегов как занятый за 1 > присест или за хренадцать раз? Вывод очевиден. Да и бенчмарки недвусмысленно > намекают. Тест от 27 июня 2012 года: "For the 8GB IOzone write test, ZFS on the OCZ Solid 2 SSD was right in the middle between EXT4 and Btrfs while on the HDD it was tied with EXT4 for being the slowest." http://www.phoronix.com/scan.php?page=article&item=linux_zfs... На HDD Ext4 чуточку слила LLNL ZFS v0.6.0-rc9. Так что вы там про экстенты говорили и про "лопатитЬся меньше данных"?... ;)
	Ответить | Правка | ^ к родителю #248 | Наверх | Cообщить модератору

	272. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 23:21
	На Threaded I/O Write Test, особенно на HDD, ZFS можно сравнивать только с BTRFS. Почему - уже объяснял в этой теме.
	Ответить | Правка | ^ к родителю #261 | Наверх | Cообщить модератору

	446. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 30-Сен-12, 19:25
	> http://www.phoronix.com/scan.php?page=article&item=linux_zfs... > На HDD Ext4 чуточку слила LLNL ZFS ...а про то что их в этих тестах на механике совершенно дико порвал btrfs - тактично промолчал. Ох уж эти бсдшники! :) "Если факты не подтверждают теорию, от них надо избавиться!" (законы мерфи). К сожалению для вас я иногда хожу по ссылкам :P
	Ответить | Правка | ^ к родителю #261 | Наверх | Cообщить модератору

	263. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 22:47
	> Не совсем понимаю при чем тут ваш sysctl. Ох уж эти провалы в памяти ... > Тонкости настройки более-менее описаны в мануале. Пересказывать забесплатно ман всяким > ламерюгам желания совершенно нет. С такими провалами в памяти да забесплатно ? Я бы тоже не согасился :-)) >> В UFS и ZFS это точно не так :-))) > На каком-то фундаментальном уровне они могли бы изобразить по крайней мере что-то > близкое к этому. Безусловно месье знает лучше разработчиков но его забыли стросить. Похоже у месье ЧСВ в потолок уперлось. :-))) >> Все эти построения основаны на необходимости считывать данные которые могут хотябы >> потенциально быть записаны последовательно. Вероятно разработчики UFS хотели чтоб при любой степени заполненности диска данные читались приблизительно с одинаковой скоростью ? Не ? > Хм, вот это не помню, может и не умеет. В принципе объединение > пространства неплохая идея, но в конечном итоге это уже относительно некритичный > улучшайзер. Если уж посмотреть на бсды, там и такого нет. Опять провалы в памяти ... > Их в общем то нынче уже регулярно ловят, если что. Можно считать > что на промышленной основе. Самолично не ловил, т.к. это требует слишком > монструозного реквизита, который на дороге не валяется. Зато методика опробована кучей > различных команд и работает. Нейтрино слабо взаимодействуют с веществом. Поэтому чтобы > хоть что-то поймать, вещества должно быть много. Значит, установка будет большой. Нейтрино не взаимодействует ни с чем ... месье далек от физики ? :-)) > Для желающих просто набить брюхо - ну да. Впрочем ваши бзди примерно > так же в этом плане. Так что странно что вы ими > умудряетесь при этом пользоваться. Хотя судя по тому что вы так > хорошо знаете виндовый дефрагер, вероятно как десктоп ваша любимая бздя действительно > не фонтан. Анекдот в тему: приходят два недо-пхп-программиста сисадминами на работу устраиваться, и один другому говорит: - не bsdи? прорвемся ... >> Именно переменные блоки дают преимущества над железными RAID. > У btrfs есть экстенты. Чем-то похожее по смыслу, но у них есть > один важный нюанс. Они не ограничены 128Кб (дефолт) или 1Мб (максимум) > как в ZFS. Что это означает? То что при непрерывной записи > больщих файлов большими кусками будет лопатиться меньше метаданных. Так что если > некто хочет записать кусок "хренадцать мегабайт", btrfs вполне может оформить его > его как ОДНУ запись экстента. Ага а если питаение в этот момент пропадет то его одним куском и похерит :-))
	Ответить | Правка | ^ к родителю #248 | Наверх | Cообщить модератору

	332. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 21:17
	>> Не совсем понимаю при чем тут ваш sysctl. > Ох уж эти провалы в памяти ... Так продолжите мыслю в нормальном виде. >> ламерюгам желания совершенно нет. > С такими провалами в памяти да забесплатно ? Я бы тоже не согасился :-)) Ну и замечательно, мне же меньше геморроя. > Безусловно месье знает лучше разработчиков но его забыли стросить. Похоже у месье > ЧСВ в потолок уперлось. :-))) Я могу себе представить как выглядело бы соответствующее размещение структур на диске. Только и всего. Насколько близко к этому приблизится реальный аллокатор - зависит от его реализации, разумеется. Просто в отличие от вас, полагающих что вам в высокие материи врубиться не дано, я предпочитаю понимать основы того как все это работает. И это не ЧСВ а констатация очевидных фактов. Просто капитанинг. > Вероятно разработчики UFS хотели чтоб при любой степени заполненности диска данные читались > приблизительно с одинаковой скоростью ? Не ? Они хотели одного: не бубухать в его переделку людские ресурсы которых у бсдшников сроду нет. Поэтому они оставили архаичный дизайн, примотав к нему скотчем и проволокой улучшайзеры. А указанную вами цель на 100% не достигает практически ни 1 дизайн ФС. Ну кроме случая когда ФС отдефрагят, но там свои проблемы, в том что в клиническом случае дефраг может не справиться ни за какое разумное время вообще. Например, мсье как-то раз видел как виндовый дефрагер не осилил заметно улучшить картину на сильно забитом разделе на всего жалких 40Гб за целые сутки непрерывного хрустения. Какая скорость работы всего этого - несложно догадаться. Да-да, хваленый вами нтфс выдавал 5-10Мб/сек, что для десктопного винча просто смехотворно. В итоге оказалось проще сдвинуть оттуда все файлы и переформатить. Не в пример быстрее и результативнее. >> пространства неплохая идея, но в конечном итоге это уже относительно некритичный >> улучшайзер. Если уж посмотреть на бсды, там и такого нет. > Опять провалы в памяти ... Ох, правда? Тогда покажите мне дефрагеры в вашей любимой bsd. > Нейтрино не взаимодействует ни с чем ... Вообще-то, достаточно сильный поток нейтрино повстречавшись с достаточно большим объемом вещества все-таки немного но взаимодействует. Т.к. нейтрино почти не взаимодействуют с веществом, детекторы являют собой достаточно исполинские сооружения. Ну чтобы повысить вероятность детектирования, детектор должен быть большим, а нейтрино - побольше. Более того, я вполне себе следил за приколами типа "якобы сверхсветовых" нейтрино и узнал что теория относительности не пошатнулась, просто GPS используемый для синхронизации малость налажал. > месье далек от физики ? :-)) Мсье вполне себе интересуется элементарными частицами. Между прочим, если ввести в гугл "детектор нейтрино" - даже расскажут про них, какие бывают, где строят и прочая. Хотя может быть, все эти лохи тоже далеки от физики и только nagual у нас тут умный. Вот только он упустил слово "почти". Ну тогда допплеровского эффекта - почти нет. Его относительная величина - мизер. А как же тогда радар у гайцев работает? А почему в GPS его учитывают? Они еще и теорию относительности учитывают. Хотя казалось бы, эффекты мизерные и можно отделаться ньютоновской механикой. А вот ФИГ. > и один другому говорит: - не bsdи? прорвемся ... Да, вам этот анекдот подходит, судя по постам :) >> некто хочет записать кусок "хренадцать мегабайт", btrfs вполне может оформить его >> его как ОДНУ запись экстента. > Ага а если питаение в этот момент пропадет то его одним куском и похерит :-)) Это не баг, это фича. CoW реализует подвид полного журналинга. Поэтому файл или будет в старом состоянии, или в новом. А что вы будете делать с полу(пере)записанным файлом? Он все-равно в общем случае неюзабелен. Зато выглядит почти как живой. В этом плане btrfs вообще монстр. Всегда можно отмотать на снапшот. Это настолько простая и легкая операция что он их на автомате делает. И при сбое просто отматывает на последний успешный снапшот. И рекавери при сбое быстрое и состояние файлов  куда предсказуемее чем обычно в классических ФС. В UFS это малость подлечили побочным методом, но общей тормознутости и архаичности дизайна этой ФС сие не отменяет. Сколько запорожцу подушки безопасности не ставь, мерседесом он от этого не станет.
	Ответить | Правка | ^ к родителю #263 | Наверх | Cообщить модератору

	338. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 24-Сен-12, 22:15
	>> Безусловно месье знает лучше разработчиков но его забыли стросить. Похоже у месье >> ЧСВ в потолок уперлось. :-))) > Я могу себе представить как выглядело бы соответствующее размещение структур на диске. > Только и всего. Насколько близко к этому приблизится реальный аллокатор - > зависит от его реализации, разумеется. Ссылка на статью с описанием уже постилась. > Просто в отличие от вас, полагающих > что вам в высокие материи врубиться не дано, я предпочитаю понимать > основы того как все это работает. Судя по всему получается плохо ... > И это не ЧСВ а > констатация очевидных фактов. Просто капитанинг. nagual выглядывая в окно - Однако осень. > Поэтому они оставили архаичный дизайн, примотав к нему > скотчем и проволокой улучшайзеры. ext2 ext3 ext4 ... ждем ext5 ? :-)) > Например, мсье как-то раз видел как > виндовый дефрагер не осилил заметно улучшить картину на сильно забитом разделе > на всего жалких 40Гб за целые сутки непрерывного хрустения. Неужели месье за столько лет работы с разными фс так и не понял что любую фс нельзя забивать выше 70% ? >> Нейтрино не взаимодействует ни с чем ... > Вообще-то, достаточно сильный поток нейтрино повстречавшись с достаточно большим объемом > вещества все-таки немного но взаимодействует. Т.к. нейтрино почти не взаимодействуют > с веществом, детекторы являют собой достаточно исполинские сооружения. Ну чтобы повысить > вероятность детектирования, детектор должен быть большим, а нейтрино - побольше. Более > того, я вполне себе следил за приколами типа "якобы сверхсветовых" нейтрино > и узнал что теория относительности не пошатнулась, просто GPS используемый для > синхронизации малость налажал. Товарищ сержант а танки летают ? летают только очень низко ... :-))) > Мсье вполне себе интересуется элементарными частицами. Между прочим, если ввести в гугл > "детектор нейтрино" Если бы месье асилил хотябы первый том Левашева ему бы в голову не пришло вводить в гугл "детектор нейтрино"  :-))) > даже расскажут про них, какие бывают, где строят > и прочая. Хотя может быть, все эти лохи тоже далеки от > физики и только nagual у нас тут умный. Эти лохи раскрутили евросоюз на трилионы евро для постройки коллайдера :-))) Ну и где практическая польза от вложения ? > Вот только он > упустил слово "почти". Ну тогда допплеровского эффекта - почти нет. Его > относительная величина - мизер. А как же тогда радар у гайцев > работает? А почему в GPS его учитывают? Они еще и теорию > относительности учитывают. Хотя казалось бы, эффекты мизерные и можно отделаться ньютоновской > механикой. А вот ФИГ. Это те радары которые постоянно глючат ? :-))) > Это не баг, это фича. CoW реализует подвид полного журналинга. Поэтому файл > или будет в старом состоянии, или в новом. А что вы > будете делать с полу(пере)записанным файлом? Он все-равно в общем случае неюзабелен. Вспоминается копирование файла в несколько гиг по сети в вин 98 ... копирует копирует бац сеть глюкнула и опять с самого начала копирует копирует :-))) > Зато выглядит почти как живой. В этом плане btrfs вообще монстр. > Всегда можно отмотать на снапшот. Это настолько простая и легкая операция > что он их на автомате делает. И при сбое просто отматывает > на последний успешный снапшот. И рекавери при сбое быстрое и состояние > файлов  куда предсказуемее чем обычно в классических ФС. В UFS > это малость подлечили побочным методом, но общей тормознутости и архаичности дизайна > этой ФС сие не отменяет. Сколько запорожцу подушки безопасности не ставь, > мерседесом он от этого не станет. Абсолютно с вами сгласен пока fsck лечит ext4 до неузноваемости ... в продакшен ни ни ...
	Ответить | Правка | ^ к родителю #332 | Наверх | Cообщить модератору

	340. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Сен-12, 22:35
	> Неужели месье за столько лет работы с разными фс так и не > понял что любую фс нельзя забивать выше 70% ? [root@storage ~]# dd if=/data/Anime/Viewed/Macross\ Frontier/TV1/\[Coalgirls\]_Macross_Frontier_02_\(1920x1080_Blu-ray_FLAC\)_\[B0A02588\].mkv of=/dev/null bs=1048576 1088+1 записей считано 1088+1 записей написано скопировано 1141045654 байта (1,1 GB), 0,379371 c, 3,0 GB/c [root@storage ~]# dd if=/data/Anime/Viewed/Macross\ Frontier/TV1/\[Coalgirls\]_Macross_Frontier_03_\(1920x1080_Blu-ray_FLAC\)_\[115BDB01\].mkv of=/dev/null bs=1048576 1044+1 записей считано 1044+1 записей написано скопировано 1095420279 байт (1,1 GB), 11,2429 c, 97,4 MB/c [root@storage ~]# dd if=/data/Anime/Viewed/Macross\ Frontier/TV1/\[Coalgirls\]_Macross_Frontier_04_\(1920x1080_Blu-ray_FLAC\)_\[73670FA5\].mkv of=/dev/null bs=1048576 1068+1 записей считано 1068+1 записей написано скопирован 1120538941 байт (1,1 GB), 10,574 c, 106 MB/c [root@storage ~]# dd if=/dev/zero of=/data/Anime/test.t2 bs=1048576 count=1024 1024+0 записей считано 1024+0 записей написано скопировано 1073741824 байта (1,1 GB), 3,41094 c, 315 MB/c [root@storage ~]# dd if=/dev/zero of=/data/Anime/test.t3 bs=1048576 count=1024 1024+0 записей считано 1024+0 записей написано скопировано 1073741824 байта (1,1 GB), 3,32492 c, 323 MB/c [root@storage ~]# dd if=/dev/zero of=/data/Anime/test.t4 bs=1048576 count=4096 4096+0 записей считано 4096+0 записей написано скопировано 4294967296 байт (4,3 GB), 16,3468 c, 263 MB/c [root@storage ~]# dd if=/data/Anime/test.t2 bs=1048576 of=/dev/null 1024+0 записей считано 1024+0 записей написано скопировано 1073741824 байта (1,1 GB), 5,15343 c, 208 MB/c [root@storage ~]# dd if=/data/Anime/test.t3 bs=1048576 of=/dev/null 1024+0 записей считано 1024+0 записей написано скопировано 1073741824 байта (1,1 GB), 5,09285 c, 211 MB/c [root@storage ~]# dd if=/data/Anime/test.t4 bs=1048576 of=/dev/null 4096+0 записей считано 4096+0 записей написано скопировано 4294967296 байт (4,3 GB), 20,0763 c, 214 MB/c [root@storage ~]# df -h Файловая система      Разм  Исп  Дост  Исп% смонтирована на /dev/mapper/Anime-Anime                       1,3T  1,2T   30G  98% /data/Anime [root@storage ~]# mount /dev/mapper/Anime-Anime on /data/Anime type ext4 (rw,user_xattr) Что я делаю не так? Том забит на 98%, новые файлы пишутся и читаются быстрее, чем некоторые старые, "разложенные" торрент-клиентом... Все зависит от ворклоада. Ну и да - там, где блочный аллокатор сдохнет, экстентный живет вполне нормально. Кэш? Ни разу. Вызывает небольшую погрешность измерений при записи, но не более того. # cat /proc/meminfo MemTotal:        1020596 kB
	Ответить | Правка | ^ к родителю #338 | Наверх | Cообщить модератору

	345. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 24-Сен-12, 23:39
	> Что я делаю не так? Том забит на 98%, новые файлы пишутся > и читаются быстрее, чем некоторые старые, "разложенные" торрент-клиентом... > Все зависит от ворклоада. Ну и да - там, где блочный аллокатор > сдохнет, экстентный живет вполне нормально. > Кэш? Ни разу. Вызывает небольшую погрешность измерений при записи, но не более > того. > # cat /proc/meminfo > MemTotal:        1020596 kB Во первых диск ссд а не хдд, во вторых кеширование, в третих интересна только запись. Если у месье все тесты проводятся с такой точностью то наверно не стоит тратить время ...
	Ответить | Правка | ^ к родителю #340 | Наверх | Cообщить модератору

	354. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Сен-12, 23:51
	> Во первых диск ссд а не хдд, во вторых кеширование, в третих Seagate 7200.11, RAID 5 > интересна только запись Дык, она выше есть.
	Ответить | Правка | ^ к родителю #345 | Наверх | Cообщить модератору

	357. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Сен-12, 23:55
	> Seagate 7200.11, RAID 5 3 диска в массиве. Параллельно с этого же массива выполняются 7 виртуальных машин, из которых 4 достаточно бодренькие по отношению к диску - MySQL, две площадки LA(M)P, и MaNGOS. Роутерная виртуалка со сквидом не в счёт.
	Ответить | Правка | ^ к родителю #354 | Наверх | Cообщить модератору

	362. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 25-Сен-12, 00:20
	>скопировано 1141045654 байта (1,1 GB), 0,379371 c, 3,0 GB/c Да нет там кеширования :-)) Это виртуалка ? :-)) Диск 30 гиг ? Файло за 1 раз записано ? :-)) Вот и в современной науке полно ученых с такими навыками тестирования :-))
	Ответить | Правка | ^ к родителю #354 | Наверх | Cообщить модератору

	369. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 25-Сен-12, 07:34
	> Да нет там кеширования :-)) "Вызывает небольшую погрешность измерений при записи, но не более того." - не предполагает отсутствия кэша, какбэ. Естественно, кэш есть. <512 Мб свободных на площадке, и 512 Мб в контроллере (общий на всю платформу). Поэтому если при записи 1Гб+ он еще дает какую-никакую погрешность - то при записи 4Гб она уже собственно минимальна. Специально показал скорость кэша в первой же строчке, и во второй - то, что при чтении следующего гигового файла кеш уже не актуален - он меньше гига объёмом. > Это виртуалка ? :-)) Диск 30 гиг ? Файло за 1 раз Виртуалка. ESXi 5.0, VMFS объемом в 1.3 тера, 98% занято.
	Ответить | Правка | ^ к родителю #362 | Наверх | Cообщить модератору

	375. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 25-Сен-12, 08:42
	>Ну что ты какой тупой? Это КЭШ, блджад. Специально показал скорость кэша. Смотри дальше. Модератор опенета вполне может написать статью на тему "Cклонномть к паталогической лжи как осложнение ЛГМ". :-)) Месье не ожидал что его поймают на подтасовках? Читатели опенета оказались проницательнее начальства на работе ? Ай яй яй :-)))
	Ответить | Правка | ^ к родителю #369 | Наверх | Cообщить модератору

	378. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok) on 25-Сен-12, 09:17
	>>Ну что ты какой тупой? Это КЭШ, блджад. Специально показал скорость кэша. Смотри дальше. > Модератор опенета вполне может написать статью на тему "Cклонномть к паталогической лжи > как осложнение ЛГМ". :-)) Месье не ожидал что его поймают на > подтасовках? Читатели опенета оказались проницательнее начальства на работе ? Ай яй > яй :-))) Один конкретный читатель оказался настолько туп, что увидев строчку с тестом кеша пустил сопли.
	Ответить | Правка | ^ к родителю #375 | Наверх | Cообщить модератору

	447. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 30-Сен-12, 19:28
	> Во первых диск ссд а не хдд, И что? Ну выпускаются они. Массово. Стало быть с ними надлежит нормально работать.
	Ответить | Правка | ^ к родителю #345 | Наверх | Cообщить модератору

	342. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Сен-12, 22:39
	>> Поэтому они оставили архаичный дизайн, примотав к нему >> скотчем и проволокой улучшайзеры. > ext2 ext3 ext4 ... ждем ext5 ? :-)) Между ext3 и ext4 - огромная пропасть. В ext4 запилен экстентный аллокатор.
	Ответить | Правка | ^ к родителю #338 | Наверх | Cообщить модератору

	349. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от nagual (ok) on 24-Сен-12, 23:45
	>>> Поэтому они оставили архаичный дизайн, примотав к нему >>> скотчем и проволокой улучшайзеры. >> ext2 ext3 ext4 ... ждем ext5 ? :-)) > Между ext3 и ext4 - огромная пропасть. Скотч проволка клей и спички ?
	Ответить | Правка | ^ к родителю #342 | Наверх | Cообщить модератору

	466. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 15:21
	> Скотч проволка клей и спички ? Прямо описание процесса разработки UFS. Надо же, к антикварному драндулету приклеили антикрыло. Которое впрочем там нафиг не упало из-за аэродинамики класса "кирпич".
	Ответить | Правка | ^ к родителю #349 | Наверх | Cообщить модератору

	515. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 02-Окт-12, 21:26
	> Скотч проволка клей и спички ? Хоть слезы девственницы, если оно работает и делает это быстро и хорошо.
	Ответить | Правка | ^ к родителю #349 | Наверх | Cообщить модератору

	365. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 25-Сен-12, 00:36
	>>> Поэтому они оставили архаичный дизайн, примотав к нему >>> скотчем и проволокой улучшайзеры. >> ext2 ext3 ext4 ... ждем ext5 ? :-)) > Между ext3 и ext4 - огромная пропасть. В ext4 запилен экстентный аллокатор. ZFSv29 — RAID-Z/mirror hybrid allocator Это то, о чём вы думаете?
	Ответить | Правка | ^ к родителю #342 | Наверх | Cообщить модератору

	373. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 25-Сен-12, 08:04
	>> Между ext3 и ext4 - огромная пропасть. В ext4 запилен экстентный аллокатор. > ZFSv29 — RAID-Z/mirror hybrid allocator > Это то, о чём вы думаете? Иногда лучше читать, прежде чем говорить...
	Ответить | Правка | ^ к родителю #365 | Наверх | Cообщить модератору

	377. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–2 +/–
	Сообщение от nagual (ok) on 25-Сен-12, 08:50
	>>> Между ext3 и ext4 - огромная пропасть. В ext4 запилен экстентный аллокатор. >> ZFSv29 — RAID-Z/mirror hybrid allocator >> Это то, о чём вы думаете? > Иногда лучше читать, прежде чем говорить... Я заметил некоторые каментаторы статей с острыми симтомами ЛГМ этих самых статей не читали ...
	Ответить | Правка | ^ к родителю #373 | Наверх | Cообщить модератору

	379. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok) on 25-Сен-12, 09:17
	> Я заметил некоторые каментаторы статей с острыми симтомами ЛГМ этих самых статей > не читали ... И я о том же.
	Ответить | Правка | ^ к родителю #377 | Наверх | Cообщить модератору

	494. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 02-Окт-12, 11:00
	> Между ext3 и ext4 - огромная пропасть. В ext4 запилен экстентный аллокатор. Чтож вы не предупредили что запилено совсем недавно ? http://forum.ubuntu.ru/index.php?topic=80218.0 Это очередная обкатка технологий корпорациями ? Оказывается стабильная фс XFS а не ext4 и уж тем более не btrfs которую ждут с концу года http://www.opennet.me/opennews/art.shtml?num=32974 ЗЫ Вот так некоторые начитаются слоника в домене и строят проекты на нестабильном дистрибутиве, на нестабильной фс ...
	Ответить | Правка | ^ к родителю #342 | Наверх | Cообщить модератору

	497. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok) on 02-Окт-12, 12:42
	А между тем, в продакшне ext4 работает, и работает абсолютно стабильно.
	Ответить | Правка | ^ к родителю #494 | Наверх | Cообщить модератору

	533. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 06-Окт-12, 15:52
	> Оказывается стабильная фс XFS а не ext4 и уж тем более не btrfs Вообще-то, XFS и ext4 официально заявлены стабильными уже фиг знает сколько. XFS - вообще черт знает когда. Где-то в районе 2.6.28 был прибит последний более-менее чувствительный баг касающихся зануления файлов. С тех пор крутых багов там вообще особо не чинилось. А EXT4 тогда только-только собирался выйти из -dev еще. И стал реально юзабелен в районе 2.6.32 примерно. И то - пару кондовых но к счастью суперредких багов потом починили. Один баг мог приводить к разрушению ФС, но вероятность на него наступить такова что проще выиграть джек-пот в лотерею, т.к. это происходит только при работе с очень большими файлами (более скольких-то Тб размером).
	Ответить | Правка | ^ к родителю #494 | Наверх | Cообщить модератору

	534. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 06-Окт-12, 18:06
	> Вообще-то, XFS и ext4 официально заявлены стабильными уже фиг знает сколько. Кем заявлено ораклом ? А недавно микрософ заяволо о стабильности вин8 ага ... > XFS- вообще черт знает когда. Где-то в районе 2.6.28 был прибит > последний более-менее чувствительный баг касающихся зануления файлов. С тех пор крутых > багов там вообще особо не чинилось. А EXT4 тогда только-только собирался > выйти из -dev еще. И стал реально юзабелен в районе 2.6.32 > примерно. И то - пару кондовых но к счастью суперредких багов > потом починили. Один баг мог приводить к разрушению ФС, но вероятность > на него наступить такова что проще выиграть джек-пот в лотерею, т.к. > это происходит только при работе с очень большими файлами (более скольких-то > Тб размером). Ну про xfs верим.
	Ответить | Правка | ^ к родителю #533 | Наверх | Cообщить модератору

	393. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 25-Сен-12, 20:02
	>> Только и всего. Насколько близко к этому приблизится реальный аллокатор - >> зависит от его реализации, разумеется. > Ссылка на статью с описанием уже постилась. Что - ссылка? Если вы не можете кратенько, в двух словах изложить что вы имели в виду без отсылок к различным простыням - грош вам цена в базарный день. Это означает что вы сами не поняли что там написано. > Судя по всему получается плохо ... По крайней мере, лучше чем у вас. Во всяком случае, я могу своим мозгом прикинуть что получится и что может получиться при том или ином дизайне ФС. А вы только и умеете что куда-то отсылать. Сами сформулировать мысль вы вообще не в состоянии. > nagual выглядывая в окно - Однако осень. Да уж, школьники и студенты вернулись с каникул, блин. Вы домашку то уже сделали, мсье спорщик? :) > ext2 ext3 ext4 ... ждем ext5 ? :-)) Думаю что таковым станет btrfs. И да, в 4-й версии по крайней мере перешли на экстентный аллокатор, так что оно хотя-бы стало работать с скоростью современных ФС. >> на всего жалких 40Гб за целые сутки непрерывного хрустения. > Неужели месье за столько лет работы с разными фс так и не > понял что любую фс нельзя забивать выше 70% ? Почему-же, мсье в курсе. Правда 70% это довольно пессимистичный порог. На практике EXT-ы не испытывают особых проблем где-то до 90% забитости диска. Но лучше так все-таки не делать. Хотя с дефрагером уже и можно пожировать: в случае чего отдефрагать можно. > Товарищ сержант а танки летают ? летают только очень низко ... :-))) Простите, у вас 1 извилина, и та от фуражки? Ну или почему вы не в состоянии вбить в гугль фразу "детектор нейтрино" и узнать много нового о существовании таковых? >> "детектор нейтрино" > Если бы месье асилил хотябы первый том Левашева ему бы в голову > не пришло вводить в гугл "детектор нейтрино"  :-))) А что, от Левашова настолько тупеют? Извините, я интересуюсь только экспериментально доказанными фактами. В частности, нейтрино не только детектируют, но и использовали их в ряде экспериментов на БАК. В том числе как раз потому что они очень слабо взаимодействуют с веществом и поэтому без проблем пролетяют прямо через заметный кусок планеты без особых проблем, потеряв по пути достаточно небольшой процент частиц. Что делает их достаточно любопытными частицами. Мало какая частица протиснется через полпланеты без построения специальных каналов для удержания и предотвращения взаимодействий с веществом (что дорого и проблематично). А нейтрино - запросто. Что делает его ценной штукой для посылки в сильно удаленную лабораторию через что попало, т.е. достаточно отправить пучок в нужную сторону и все, готово. Это же свойство и затрудняет детектирование. Но "затрудняет" != "делает невозможным". На практике поток нейтрино вполне себе детектируется. Просто эффективность детектирования - низкая, поэтому требуется большой детектор для сколь-нибудь заметного результата. >> физики и только nagual у нас тут умный. > Эти лохи раскрутили евросоюз на трилионы евро для постройки коллайдера :-))) Ну > и где практическая польза от вложения ? Эти лохи по сути нашли бозон Хиггса, тем самым подтвердив ряд теорий насчет мира элементарных частиц. Хомякам от этого ничего не будет, по крайней мере немедленно и сейчас. Но в целом знания о том где мы живем и как это устроено - нужны. Должны же мы эволюционировать дальше, не ограничиваясь примитивными инстинктами как остальная живность? Желание познавать устройство мира - одно из проявлений интеллекта. >> относительности учитывают. Хотя казалось бы, эффекты мизерные и можно отделаться >> ньютоновской механикой. А вот ФИГ. > Это те радары которые постоянно глючат ? :-))) Когда гражданин полицейский заинтересован палку срубить - тогда глючит. А так - эффект есть и работает. Впрочем он намного нагляднее слышен когда проезжающий мимо поезд издает гудок. При этом монотонный звук гудка превращается в очень характерный звук меняющийся по высоте. Удачи оспорить столь вопиющее проявление. > копирует копирует бац сеть глюкнула и опять с самого начала копирует копирует :-))) Крокодил^W нейтрино не ловится, не растет кокос^W^W^W сеть глючит. Как вы живете вообще? :) > Абсолютно с вами сгласен пока fsck лечит ext4 до неузноваемости ... в > продакшен ни ни ... Ну вообще с учетом тенденций указанных выше я не удивлен что у вас ext4 не чинится. И ZFS наверное рассыпется скоро.
	Ответить | Правка | ^ к родителю #338 | Наверх | Cообщить модератору

	395. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 25-Сен-12, 20:19
	> По крайней мере, лучше чем у вас. Во всяком случае, я могу > своим мозгом прикинуть что получится и что может получиться при том > или ином дизайне ФС. А вы только и умеете что куда-то > отсылать. Сами сформулировать мысль вы вообще не в состоянии. ВЫ главное результаты своих изысканий никому не показывайте :-)) > Думаю что таковым станет btrfs. И да, в 4-й версии по крайней > мере перешли на экстентный аллокатор, так что оно хотя-бы стало работать > с скоростью современных ФС. А современные это какие если не ufs ext4 b zfs ? Неужно ntfs ? :)))) > Почему-же, мсье в курсе. Правда 70% это довольно пессимистичный порог. На практике > EXT-ы не испытывают особых проблем где-то до 90% забитости диска. Но > лучше так все-таки не делать. Хотя с дефрагером уже и можно > пожировать: в случае чего отдефрагать можно. Учитывая скорость работы мозга особенно у руководства 70% это как раз тот момент когда нужно искать новое хранилище. > Простите, у вас 1 извилина, и та от фуражки? Ну или почему > вы не в состоянии вбить в гугль фразу "детектор нейтрино" и > узнать много нового о существовании таковых? У меня такое впечатление что вы распрямитель рук для головы применили. Не все йогурты одинаково полезны ... > А что, от Левашова настолько тупеют? Извините, я интересуюсь только экспериментально доказанными > фактами. Экспериментально доказано что неуловимый Джо пойман ... :-))) >[оверквотинг удален] > что они очень слабо взаимодействуют с веществом и поэтому без проблем > пролетяют прямо через заметный кусок планеты без особых проблем, потеряв по > пути достаточно небольшой процент частиц. Что делает их достаточно любопытными частицами. > Мало какая частица протиснется через полпланеты без построения специальных каналов для > удержания и предотвращения взаимодействий с веществом (что дорого и проблематично). А > нейтрино - запросто. Что делает его ценной штукой для посылки в > сильно удаленную лабораторию через что попало, т.е. достаточно отправить пучок в > нужную сторону и все, готово. Это же свойство и затрудняет детектирование. > Но "затрудняет" != "делает невозможным". На практике поток нейтрино вполне себе > детектируется. А еще месье до сих пор верит в Деда Мороза. > Просто эффективность детектирования - низкая, поэтому требуется большой > детектор для сколь-нибудь заметного результата. Летают но очень низко ... :-))) > Эти лохи по сути нашли бозон Хиггса, тем самым подтвердив ряд теорий > насчет мира элементарных частиц. Хомякам от этого ничего не будет, по > крайней мере немедленно и сейчас. Но в целом знания о том > где мы живем и как это устроено - нужны. Должны же > мы эволюционировать дальше, не ограничиваясь примитивными инстинктами как остальная живность? > Желание познавать устройство мира - одно из проявлений интеллекта. Месье так же верит что в наперстки можно выиграть ? :-))) Вы случайно все это не по телевизору увидели ? :-)))))
	Ответить | Правка | ^ к родителю #393 | Наверх | Cообщить модератору

	212. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 19:13
	>> Палундра в ZFS нет дефрагментатора %) > Да вон iZEN уже ощущает результат. И даже если он осовободит место, > сильно лучше может и не стать. В общем то нет простого > метода расчистить такое без дефрагментатора. Было: http://www.opennet.me/openforum/vsluhforumID3/86368.html#433 //--- % dd if=/downloads1/Margin\ Call.mkv of=/store/video/Margin\ Call.mkv bs=20M 74+1 records in 74+1 records out 1561257376 bytes transferred in 908.455462 secs (1718584 bytes/sec) % df /store/video Filesystem     Size    Used   Avail Capacity  Mounted on store/video    790G    789G    1.1G   100%    /store/video ---// Стало: % dd if=/downloads1/Margin\ Call.mkv of=/store/video/Margin\ Call.mkv bs=20M 74+1 records in 74+1 records out 1561257376 bytes transferred in 18.599765 secs (83939630 bytes/sec) % df /store/video Filesystem     Size    Used   Avail Capacity  Mounted on store/video    789G    757G     32G    96%    /store/video И как? Стало лучше, по-твоему? ;) На самом деле тут одна особенность выяснилась. Тормозила не столько запись на RAID-Z пул (кстати, состоящий из трёх разделов ноутбучных винчестеров с 5400 rpm), сколько чтение с заполненного скачанными файлами пула, состоящего из одного диска Western Digital Caviar Blue WD6400AAKS. Последний результат показан для записи файла, который был предварительно закэширован в ARC ZFS (dd выполнялась два раза, представлен второй, наилучший результат её работы).
	Ответить | Правка | ^ к родителю #200 | Наверх | Cообщить модератору

	218. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 19:36
	>>> Палундра в ZFS нет дефрагментатора %) >> Да вон iZEN уже ощущает результат. И даже если он осовободит место, >> сильно лучше может и не стать. В общем то нет простого >> метода расчистить такое без дефрагментатора. > Было: http://www.opennet.me/openforum/vsluhforumID3/86368.html#433 > Стало: Косяк. Надо скорость чтения файла, который клался на том под конец его захламливания. Понятно, что если стереть всё с тома и набить одним заходом заново - будет лучше. Но вот тому, что уже набито, от освобождения места лучше не станет.
	Ответить | Правка | ^ к родителю #212 | Наверх | Cообщить модератору

	223. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 20:14
	>[оверквотинг удален] >>> Да вон iZEN уже ощущает результат. И даже если он осовободит место, >>> сильно лучше может и не стать. В общем то нет простого >>> метода расчистить такое без дефрагментатора. >> Было: http://www.opennet.me/openforum/vsluhforumID3/86368.html#433 >> Стало: > Косяк. Надо скорость чтения файла, который клался на том под конец его > захламливания. > Понятно, что если стереть всё с тома и набить одним заходом заново > - будет лучше. Но вот тому, что уже набито, от освобождения > места лучше не станет. А оно изначально было "набито" без модификации, на новый чистый пул. Потом шла дозапись данными. Чему там тормозить?!
	Ответить | Правка | ^ к родителю #218 | Наверх | Cообщить модератору

	229. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 20:27
	> А оно изначально было "набито" без модификации, на новый чистый пул. Потом > шла дозапись данными. Чему там тормозить?! Ключевое слово - "дозапись". А если там еще и удаления были - вот тут уже всё интереснее. Покажи скорость чтения одного из файлов, заливавшихся непосредственно перед забитием тома до 99% :)
	Ответить | Правка | ^ к родителю #223 | Наверх | Cообщить модератору

	238. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 20:37
	>> А оно изначально было "набито" без модификации, на новый чистый пул. Потом >> шла дозапись данными. Чему там тормозить?! > Ключевое слово - "дозапись". А если там еще и удаления были - > вот тут уже всё интереснее. > Покажи скорость чтения одного из файлов, заливавшихся непосредственно перед забитием тома > до 99% :) А мне хватало — видео Full HD 1080p/MKV 14GB не тормозит при просмотре и ладно. ;) Сейчас: % dd if=/store/video/Трон\ \(1982\).mkv of=/dev/null bs=20M 726+1 records in 726+1 records out 15235365714 bytes transferred in 149.126454 secs (102164071 bytes/sec)
	Ответить | Правка | ^ к родителю #229 | Наверх | Cообщить модератору

	242. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 20:40
	> А мне хватало — видео Full HD 1080p/MKV 14GB не тормозит при > просмотре и ладно. ;) Ну я и говорю - 100/1/1/0. На серверы (кроме долгосрочек CDN) такое ставить жутковато.
	Ответить | Правка | ^ к родителю #238 | Наверх | Cообщить модератору

	243. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 20:42
	>> А мне хватало — видео Full HD 1080p/MKV 14GB не тормозит при >> просмотре и ладно. ;) > Ну я и говорю - 100/1/1/0. На серверы (кроме долгосрочек CDN) такое > ставить жутковато. Сейчас: % dd if=/store/video/Трон\ \(1982\).mkv of=/dev/null bs=20M 726+1 records in 726+1 records out 15235365714 bytes transferred in 149.126454 secs (102164071 bytes/sec) Второй раз: % dd if=/store/video/Трон\ \(1982\).mkv of=/dev/null bs=20M 726+1 records in 726+1 records out 15235365714 bytes transferred in 125.197637 secs (121690521 bytes/sec)
	Ответить | Правка | ^ к родителю #242 | Наверх | Cообщить модератору

	250. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 21:05
	> 1561257376 bytes transferred in 908.455462 secs (1718584 bytes/sec) Да-да, скорость хуже чем у самой засраной флешки. >  32G    96%    /store/video > И как? Стало лучше, по-твоему? ;) По-моему, если ты возьмешь файл который читался со скоростью 6мб/сек и сотрешь другой файл, то он продолжит читаться со скоростью 6мб/сек. Просто потому что его некому дефрагментировать ;) > диска Western Digital Caviar Blue WD6400AAKS. Последний результат показан для записи > файла, который был предварительно закэширован в ARC ZFS У, блин, так ты еще и читер. Если я закеширую что-нибудь в оперативку - я тебе покажу и гигазы в секунду запросто :)
	Ответить | Правка | ^ к родителю #212 | Наверх | Cообщить модератору

	258. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 21:47
	>> диска Western Digital Caviar Blue WD6400AAKS. Последний результат показан для записи >> файла, который был предварительно закэширован в ARC ZFS > У, блин, так ты еще и читер. Если я закеширую что-нибудь в > оперативку - я тебе покажу и гигазы в секунду запросто :) Уже не различаешь скорость чистой записи в пул? Так вот, после кэширования файла в ARC и повторной операции записи показана чистая, ничем незамутнённая скорость записи данных на пул. А как ещё её проверить? Расскажи, послушаем, вместе посмеёмся. :))
	Ответить | Правка | ^ к родителю #250 | Наверх | Cообщить модератору

	252. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 21:16
	>[оверквотинг удален] > Avail Capacity  Mounted on > store/video    789G    757G     >  32G    96%    /store/video > И как? Стало лучше, по-твоему? ;) > На самом деле тут одна особенность выяснилась. Тормозила не столько запись на > RAID-Z пул (кстати, состоящий из трёх разделов ноутбучных винчестеров с 5400 > rpm), сколько чтение с заполненного скачанными файлами пула, состоящего из одного > диска Western Digital Caviar Blue WD6400AAKS. Последний результат показан для записи > файла, который был предварительно закэширован в ARC ZFS (dd выполнялась два > раза, представлен второй, наилучший результат её работы). А сколько было в самом начале до заполнения на 100% ?
	Ответить | Правка | ^ к родителю #212 | Наверх | Cообщить модератору

	259. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 21:50
	>[оверквотинг удален] >> store/video    789G    757G >>  32G    96%    /store/video >> И как? Стало лучше, по-твоему? ;) >> На самом деле тут одна особенность выяснилась. Тормозила не столько запись на >> RAID-Z пул (кстати, состоящий из трёх разделов ноутбучных винчестеров с 5400 >> rpm), сколько чтение с заполненного скачанными файлами пула, состоящего из одного >> диска Western Digital Caviar Blue WD6400AAKS. Последний результат показан для записи >> файла, который был предварительно закэширован в ARC ZFS (dd выполнялась два >> раза, представлен второй, наилучший результат её работы). > А сколько было в самом начале до заполнения на 100% ? Где? На том диске, с которого считывается тестовый файл, или на тому пуле, куда он записывается? Около 2-6 МБ/с. Где-то так. Скорость записи на освобождённый пул уже значительно больше.
	Ответить | Правка | ^ к родителю #252 | Наверх | Cообщить модератору

	264. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 22:53
	>>> Последний результат показан для записи файла, который был предварительно закэширован в ARC ZFS (dd выполнялась два раза, представлен второй, наилучший результат её работы). Бугага, лол. Не заметил сначала эту фразу. ЧИТ. ЭПИК ЧИТ. Ты показал скорость кэша, не более того. Да и для памяти что-то как-то очень хреново.
	Ответить | Правка | ^ к родителю #212 | Наверх | Cообщить модератору

	284. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 24-Сен-12, 00:01
	>>>> Последний результат показан для записи файла, который был предварительно закэширован в ARC ZFS (dd выполнялась два раза, представлен второй, наилучший результат её работы). > Бугага, лол. Не заметил сначала эту фразу. ЧИТ. ЭПИК ЧИТ. Ты показал > скорость кэша, не более того. Из кэша памяти на пул записываются данные. Что в этом не так?
	Ответить | Правка | ^ к родителю #264 | Наверх | Cообщить модератору

	333. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 21:21
	> Из кэша памяти на пул записываются данные. Что в этом не так? Ну знаешь, у меня DVD-sized iso улетает в кэщ за пару секунд. Если все так, давай тогда считать что у меня скорость записи на винч 2Гб/сек, чтоли. А то что винч максимум 150Мб/сек на крайних треках выдает мы умолчим, во :)
	Ответить | Правка | ^ к родителю #284 | Наверх | Cообщить модератору

	337. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 24-Сен-12, 21:56
	>> Из кэша памяти на пул записываются данные. Что в этом не так? > Ну знаешь, у меня DVD-sized iso улетает в кэщ за пару секунд. > Если все так, давай тогда считать что у меня скорость записи > на винч 2Гб/сек, чтоли. А то что винч максимум 150Мб/сек на > крайних треках выдает мы умолчим, во :) Давай воспроизведи с помощью dd(1) скорость копирования данных на DVD в районе 2ГБ/с — вместе посмеёмся. Это только cp(1) так может. dd — честная утилита и пишет данные синхронно, иначе информация о скорости, выводимая в конце операции, стала бы филькиной грамотой.
	Ответить | Правка | ^ к родителю #333 | Наверх | Cообщить модератору

	339. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Сен-12, 22:28
	> Давай воспроизведи с помощью dd(1) скорость копирования данных на DVD в районе > 2ГБ/с — вместе посмеёмся. Это только cp(1) так может. dd — > честная утилита и пишет данные синхронно, иначе информация о скорости, выводимая > в конце операции, стала бы филькиной грамотой. Спасибо, повеселил. # dd if=/data/Anime/Viewed/Macross\ Frontier/TV1/\[Coalgirls\]_Macross_Frontier_02_\(1920x1080_Blu-ray_FLAC\)_\[B0A02588\].mkv of=/data/Anime/test.t1 bs=16777216 68+1 записей считано 68+1 записей написано скопировано 1141045654 байта (1,1 GB), 9,42692 c, 121 MB/c # dd if=/data/Anime/Viewed/Macross\ Frontier/TV1/\[Coalgirls\]_Macross_Frontier_02_\(1920x1080_Blu-ray_FLAC\)_\[B0A02588\].mkv of=/data/Anime/test.t1 bs=16777216 68+1 записей считано 68+1 записей написано скопировано 1141045654 байта (1,1 GB), 4,67428 c, 244 MB/c Это скорость операций с диском магически удвоилась, или все-таки ты не прав насчёт кеша? Как считаешь?
	Ответить | Правка | ^ к родителю #337 | Наверх | Cообщить модератору

	363. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 25-Сен-12, 00:29
	>[оверквотинг удален] > 68+1 записей считано > 68+1 записей написано >  скопировано 1141045654 байта (1,1 GB), 9,42692 c, 121 MB/c > # dd if=/data/Anime/Viewed/Macross\ Frontier/TV1/\[Coalgirls\]_Macross_Frontier_02_\(1920x1080_Blu-ray_FLAC\)_\[B0A02588\].mkv > of=/data/Anime/test.t1 bs=16777216 > 68+1 записей считано > 68+1 записей написано >  скопировано 1141045654 байта (1,1 GB), 4,67428 c, 244 MB/c > Это скорость операций с диском магически удвоилась, или все-таки ты не прав > насчёт кеша? Как считаешь? Я считаю, что таким образом ты сравниваешь скорость чтения-записи (суммарно) со скоростью записи (только) из кэша. В первом случае идёт разогревание файлового кэша путём считывания в него данных с диска, а во втором случае кэш уже разогрет и измеряется практически чистая скорость записи данных из оперативной памяти (разогретого файлового кэша) на диск без особых накладных расходов на чтение с механического устройства. Если у меня файл 14 ГБ с одного диска 5400 rpm будет читаться со скоростью 10-20 МБ/с и одновременно записываться на RAID10, который имеет среднюю скорость записи в районе 200 МБ/с, то, как ты думаешь, какая будет скорость записи? Правильно — не больше 20 МБ/с, потому что данные поступаю на запись с такой скоростью из медленного источника. Источник (медленный механический диск) — это бутылочное горлышко потока байтов. Чистая скорость записи измеряется записью данных на испытуемый носитель из оперативной памяти (буфера на запись — в общем случае), а не из какого-то ущербного соска. Я просто измерил чистую скорость записи на RAID-Z, вот и всё.
	Ответить | Правка | ^ к родителю #339 | Наверх | Cообщить модератору

	364. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 25-Сен-12, 00:35
	>[оверквотинг удален] > Если у меня файл 14 ГБ с одного диска 5400 rpm будет > читаться со скоростью 10-20 МБ/с и одновременно записываться на RAID10, который > имеет среднюю скорость записи в районе 200 МБ/с, то, как ты > думаешь, какая будет скорость записи? Правильно — не больше 20 МБ/с, > потому что данные поступаю на запись с такой скоростью из медленного > источника. Источник (медленный механический диск) — это бутылочное горлышко потока > байтов. Чистая скорость записи измеряется записью данных на испытуемый носитель из > оперативной памяти (буфера на запись — в общем случае), а не > из какого-то ущербного соска. Я просто измерил чистую скорость записи на > RAID-Z, вот и всё. Ох уж эта осень. :-)) Даже у thg.ru результаты тестирования raid5 из трех дисков намного скромнее http://www.thg.ru/storage/raid_scaling_2/images/image005.png Кстати 4 диска по цене столько же как 3 + контроллер :-)) а из raid0+1 можно вытащить 2 любых диска :-))
	Ответить | Правка | ^ к родителю #363 | Наверх | Cообщить модератору

	366. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 25-Сен-12, 01:12
	>[оверквотинг удален] >> имеет среднюю скорость записи в районе 200 МБ/с, то, как ты >> думаешь, какая будет скорость записи? Правильно — не больше 20 МБ/с, >> потому что данные поступаю на запись с такой скоростью из медленного >> источника. Источник (медленный механический диск) — это бутылочное горлышко потока >> байтов. Чистая скорость записи измеряется записью данных на испытуемый носитель из >> оперативной памяти (буфера на запись — в общем случае), а не >> из какого-то ущербного соска. Я просто измерил чистую скорость записи на >> RAID-Z, вот и всё. > Ох уж эта осень. :-)) Даже у thg.ru результаты тестирования raid5 из > трех дисков намного скромнее http://www.thg.ru/storage/raid_scaling_2/images/image005.png Наверно потому, что для модификации полосы набора данных на аппаратном RAID-5 нужна дополнительная операция чтения? RAID-Z обходится без этой промежуточной операции. (У меня RAID-Z сделан на ноутбучных винчестерах Samsung SpinPoint M7E). > а из raid0+1 можно вытащить 2 любых диска :-)) Нет, не любые два, а только из одной страйп-ветви. RAID-6 из четырёх дисков "позволяет" потерять два любых диска.
	Ответить | Правка | ^ к родителю #364 | Наверх | Cообщить модератору

	367. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 25-Сен-12, 01:44
	>[оверквотинг удален] >>> из какого-то ущербного соска. Я просто измерил чистую скорость записи на >>> RAID-Z, вот и всё. >> Ох уж эта осень. :-)) Даже у thg.ru результаты тестирования raid5 из >> трех дисков намного скромнее http://www.thg.ru/storage/raid_scaling_2/images/image005.png > Наверно потому, что для модификации полосы набора данных на аппаратном RAID-5 нужна > дополнительная операция чтения? RAID-Z обходится без этой промежуточной операции. (У меня > RAID-Z сделан на ноутбучных винчестерах Samsung SpinPoint M7E). >> а из raid0+1 можно вытащить 2 любых диска :-)) > Нет, не любые два, а только из одной страйп-ветви. > RAID-6 из четырёх дисков "позволяет" потерять два любых диска. Vmware на диск пишет чествно и здравый смысл не обгоняет. umount -f /dev/da10p1 gpart delete -i 1 da10 gpart destroy da10 gpart create -s gpt /dev/da10 gpart add -t freebsd-ufs -l disk0 da10 newfs -J -O2 -U /dev/da10p1 mkdir -p /mnt/da10p1 mount /dev/da10p1 /mnt/da10p1 touch /mnt/da10p1/test dd if=/dev/random of=/mnt/da10p1/test bs=1M count=2000 df -H |grep da10 da10p1 deleted da10 destroyed da10 created da10p1 added /dev/da10p1: 2048.0MB (4194232 sectors) block size 32768, fragment size 4096         using 4 cylinder groups of 512.00MB, 16384 blks, 65536 inodes.         with soft updates super-block backups (for fsck_ffs -b #) at: 192, 1048768, 2097344, 3145920 /mnt/da10p1: write failed, filesystem is full dd: /mnt/da10p1/test: No space left on device 1983+0 records in 1982+0 records out 2078277632 bytes transferred in 31.129022 secs (66763345 bytes/sec) /dev/da10p1       2.1G    2.1G   -165M   109%    /mnt/da10p1 скорость приблизительно одинаковая 66763345 bytes/sec без -J 2078277632 bytes transferred in 30.756519 secs (67571939 bytes/sec) без -S 2078277632 bytes transferred in 30.515984 secs (68104559 bytes/sec) Вобщем в виртуалке результаты тестов сомнительны.
	Ответить | Правка | ^ к родителю #366 | Наверх | Cообщить модератору

	372. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 25-Сен-12, 08:03
	> /dev/da10p1       2.1G    2.1G   -165M   109%    /mnt/da10p1 Минус 165 Мб свободного места и 109% утилизации диска? Это такая точность в *BSD всегда, или надо как-то специфично изголяться?
	Ответить | Правка | ^ к родителю #367 | Наверх | Cообщить модератору

	467. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 15:26
	> Минус 165 Мб свободного места и 109% утилизации диска? Это такая точность > в *BSD всегда, или надо как-то специфично изголяться? Ух ты, отрицательное свободное место на диске :). Интересно, это как? :)
	Ответить | Правка | ^ к родителю #372 | Наверх | Cообщить модератору

	478. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 02-Окт-12, 00:25
	>> Минус 165 Мб свободного места и 109% утилизации диска? Это такая точность >> в *BSD всегда, или надо как-то специфично изголяться? > Ух ты, отрицательное свободное место на диске :). Интересно, это как? :) Это когда на диск в 6гиг под btrfs пишешь 5.2 и вдруг нет не так ВДРУГ место кончается ... Самое смешьное это когда одно из трех такое ВДРУГ лечится только ребутом :-))) ЗЫ linux сер ...
	Ответить | Правка | ^ к родителю #467 | Наверх | Cообщить модератору

	489. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 02-Окт-12, 07:32
	Ряд утилит с uint под показатель дискового места будут очень рады такому ответу системы (отрицательному значению)...
	Ответить | Правка | ^ к родителю #478 | Наверх | Cообщить модератору

	371. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 25-Сен-12, 08:00
	> а из raid0+1 можно вытащить 2 любых диска :-)) На хабре написали? Удачи в вытаскивании.
	Ответить | Правка | ^ к родителю #364 | Наверх | Cообщить модератору

	370. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 25-Сен-12, 07:59
	> Если у меня файл 14 ГБ с одного диска 5400 rpm будет > читаться со скоростью 10-20 МБ/с То пора выкинуть диск или раздел - чтобы достигнуть такой скорости чтения - надо очень постараться. Был спор: влияет ли кэш на dd. Ты сказал, что dd - какая-то "мегасинхронная" утилита, на которую кеш не влияет. Я тебе привёл опровержение. К чему все остальное словоблудие - непонятно. Чистая скорость записи на FS без компрессии измеряется просто и быстро: dd if=/dev/zero of=/path/thrashcache bs/count=двукратный объем кеша ; dd if=/dev/zero of=/path/test bs/count=четырехкратный объем кеша Результат второго запуска можно считать более-менее достоверным. Ну или просто вторую часть теста - там будет погрешность измерений порядка 10-15%, в зависимости от скорости дисков. # dd if=/dev/zero of=/data/Anime/thrash.t1 bs=1048576 count=2048 ; dd if=/dev/zero of=/data/Anime/test.t2 bs=1048576 count=4096 2048+0 записей считано 2048+0 записей написано скопировано 2147483648 байт (2,1 GB), 8,92 c, 241 MB/c 4096+0 записей считано 4096+0 записей написано скопировано 4294967296 байт (4,3 GB), 17,8542 c, 241 MB/c
	Ответить | Правка | ^ к родителю #363 | Наверх | Cообщить модератору

	376. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 25-Сен-12, 08:45
	> Если у меня файл 14 ГБ с одного диска 5400 rpm будет > читаться со скоростью 10-20 МБ/с Под freebsd на UFS не воспроизводится ... Наверно проблема в линуксе.
	Ответить | Правка | ^ к родителю #370 | Наверх | Cообщить модератору

	490. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 02-Окт-12, 07:33
	>> Если у меня файл 14 ГБ с одного диска 5400 rpm будет >> читаться со скоростью 10-20 МБ/с > Под freebsd на UFS не воспроизводится ... Наверно проблема в линуксе. У него FreeBSD, детка.
	Ответить | Правка | ^ к родителю #376 | Наверх | Cообщить модератору

	381. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 25-Сен-12, 12:44
	>> Если у меня файл 14 ГБ с одного диска 5400 rpm будет >> читаться со скоростью 10-20 МБ/с > То пора выкинуть диск или раздел - чтобы достигнуть такой скорости чтения > - надо очень постараться. "Очень постараться" — это иметь дедупликацию ZFS на заполненном пуле. ;) > Был спор: влияет ли кэш на dd. Ты сказал, что dd - > какая-то "мегасинхронная" утилита, на которую кеш не влияет. Я тебе привёл > опровержение. К чему все остальное словоблудие - непонятно. Я не говорил, что кэш не влияет на dd(1). Я показал, какую роль играет неразогретый и разогретый кэш при чтении-записи файла с помощью dd(1) с диска на диск (обмен данными между пулами). > Чистая скорость записи на FS без компрессии измеряется просто и быстро: > dd if=/dev/zero of=/path/thrashcache bs/count=двукратный объем кеша ; dd if=/dev/zero > of=/path/test bs/count=четырехкратный объем кеша Пишется на один диск WD: % dd if=/dev/zero of=/downloads1/test0.img bs=100M count=10 10+0 records in 10+0 records out 1048576000 bytes transferred in 23.079325 secs (45433564 bytes/sec) % dd if=/dev/zero of=/downloads1/test00.img bs=100M count=10 10+0 records in 10+0 records out 1048576000 bytes transferred in 23.802206 secs (44053732 bytes/sec) % dd if=/dev/zero of=/downloads1/test000.img bs=100M count=50 50+0 records in 50+0 records out 5242880000 bytes transferred in 200.131803 secs (26197136 bytes/sec) % dd if=/dev/zero of=/downloads1/test2000.img bs=2000M count=5 5+0 records in 5+0 records out 10485760000 bytes transferred in 913.458192 secs (11479190 bytes/sec)
	Ответить | Правка | ^ к родителю #370 | Наверх | Cообщить модератору

	382. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 25-Сен-12, 12:54
	>[оверквотинг удален] > 10+0 records out > 1048576000 bytes transferred in 23.079325 secs (45433564 bytes/sec) > % dd if=/dev/zero of=/downloads1/test00.img bs=100M count=10 > 10+0 records in > 10+0 records out > 1048576000 bytes transferred in 23.802206 secs (44053732 bytes/sec) > % dd if=/dev/zero of=/downloads1/test000.img bs=100M count=50 > 50+0 records in > 50+0 records out > 5242880000 bytes transferred in 200.131803 secs (26197136 bytes/sec) А представьте нам скрипт тестирования в полном виде, не для праздного интереса а чтоб мы могли повторить эксперимент и чтоб у нас небыло оснований обвинять вас в мошенничестве. Начиная с разметки диска и создании фс. ;-)
	Ответить | Правка | ^ к родителю #381 | Наверх | Cообщить модератору

	383. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 25-Сен-12, 13:13
	> А представьте нам скрипт тестирования в полном виде, не для праздного интереса > а чтоб мы могли повторить эксперимент и чтоб у нас небыло > оснований обвинять вас в мошенничестве. Начиная с разметки диска и создании > фс. ;-) Сейчас всё брошу и буду скрипт писать для вас.
	Ответить | Правка | ^ к родителю #382 | Наверх | Cообщить модератору

	384. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 25-Сен-12, 13:31
	Месье учил нас пользоваться гуглем, ну чтож: zfs core dump Результатов: примерно 33 900 (0,15 сек.) ой btrfs core dump Результатов: примерно 91 600 (0,12 сек.) ОО ufs2 core dump Результатов: примерно 19 100 (0,12 сек.) ээх ext4 core dump Результатов: примерно 142 000 (0,10 сек.) аяяйяй ext3 core dump Результатов: примерно 477 000 (0,37 сек.) вау ext2 core dump Результатов: примерно 212 000 (0,16 сек.) не зря не зря его пилили ... UFS core dump Результатов: примерно 434 000 (0,28 сек.) сумма за все годы ? xfs core dump Результатов: примерно 195 000 (0,45 сек.) если суммировать ext2-ext4 да еще это добавить :-)) ntfs failed Результатов: примерно 3 260 000 (0,11 сек.) лидер во всем :-)) raid failure Результатов: примерно 48 900 000 (0,28 сек.) hdd failure Результатов: примерно 13 700 000 (0,30 сек.) за все время ssd failure Результатов: примерно 6 690 000 (0,18 сек.) догоним и перегоним ? lvm failed Результатов: примерно 1 020 000 (0,24 сек.) lol geom failed Результатов: примерно 375 000 (0,26 сек.) да уж ... Поиск сила :-)))
	Ответить | Правка | ^ к родителю #383 | Наверх | Cообщить модератору

	386. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok) on 25-Сен-12, 17:06
	Ну да. У неуловимых Джо кейсов, естественно, близко к 0 - ибо никто не юзает и не собирается. ext4 in production Результатов: примерно 2 240 000 (0,45 сек.) ext3 in production Результатов: примерно 3 570 000 (0,43 сек.) ufs in production Результатов: примерно 871 000 (0,34 сек.) упс. zfs in production Результатов: примерно 536 000 (0,37 сек.) ой? :) raid in production Результатов: примерно 60 400 000 (0,33 сек.) argh!
	Ответить | Правка | ^ к родителю #384 | Наверх | Cообщить модератору

	448. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 30-Сен-12, 19:31
	> Поиск сила :-))) Неандерталец открыл для себя микроволновку :)
	Ответить | Правка | ^ к родителю #384 | Наверх | Cообщить модератору

	385. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok) on 25-Сен-12, 17:05
	> 5242880000 bytes transferred in 200.131803 secs (26197136 bytes/sec) 26Mb/sec Страшно фрагментированный том, видимо.
	Ответить | Правка | ^ к родителю #381 | Наверх | Cообщить модератору

	387. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 25-Сен-12, 18:26
	>> 5242880000 bytes transferred in 200.131803 secs (26197136 bytes/sec) > 26Mb/sec > Страшно фрагментированный том, видимо. Да нет. Просто на нём свободного места около 12 ГБ.
	Ответить | Правка | ^ к родителю #385 | Наверх | Cообщить модератору

	392. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 25-Сен-12, 19:09
	Итак давайте обсудим оптимальные для тестов  bs и count :-))
	Ответить | Правка | ^ к родителю #387 | Наверх | Cообщить модератору

	399. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 25-Сен-12, 22:11
	> Да нет. Просто на нём свободного места около 12 ГБ. Скорость записи не зависит от количества свободного места. А вот от его фрагментированности - запросто.
	Ответить | Правка | ^ к родителю #387 | Наверх | Cообщить модератору

	394. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 25-Сен-12, 20:03
	> Давай воспроизведи с помощью dd(1) скорость копирования данных на DVD в районе > 2ГБ/с — вместе посмеёмся. Да вон тебе перец показал уже скорость в 3Гб/сек. Тебе мало? :)
	Ответить | Правка | ^ к родителю #337 | Наверх | Cообщить модератору

	137. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 22-Сен-12, 23:36
	> у btrfs есть встроенный дефраг. В ZFS такого не было, да. > Почему? Наверное потому что это одна из первых CoW ФС. Наверно потому что в продажу пошли первые SSD диски. Это отлично что вы рассказали нам про встроенный в бтрфс дефрагментатор. Если вы не подскажете как его отключить нафиг через sysctl то будет считать что btrfs и SSD не совместимы ... В этом плане ZFS с ее COW и SSD друзья а так как ZFS позицианируется под BD то урреждающее чтение или дефрагментация там и нафиг ненужны.
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	147. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 09:55
	>>> В этом плане ZFS с ее COW и SSD друзья Снова садись, снова два. Без TRIM они не то, что не друзья, а вообще не совместимы генетически.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	155. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 11:13
	>>>> В этом плане ZFS с ее COW и SSD друзья > Снова садись, снова два. Без TRIM они не то, что не друзья, > а вообще не совместимы генетически. Месье неасилил смысл COW ? Печально ... В таком случае поведайте нам что вы понимаете под TRIM а то мало ли вдруг и тут что то левое :-))
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	162. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 11:23
	> Месье неасилил смысл COW ? Печально ... В таком случае поведайте нам > что вы понимаете под TRIM а то мало ли вдруг и > тут что то левое :-)) Бугага. TRIM нужен для того, чтобы флешка помечала свои блоки, как свободные, когда они освобождаются в ФС. Зачем это надо? Затем, что внутри флешки есть механизм веарлевелинга (по сути тот же CoW), который использует под новые данные незанятые блоки. Но вот - увы и ах - флешка ничего не знает про файловую систему. Чтобы сказать ей, что блок свободен - нужен TRIM. И поэтому, когда все рабочие блоки данных флешки окажутся забитыми (а с CoW "сверху" без TRIM они окажутся забитыми очень быстро) - флешке не останется ничего другого, кроме как использовать под веарлевелинг при любой записи небольшой "временный набор" - резерв пространства как раз для этих целей. По мере заполнения "надлежащей" файловой системы запись все чаще и чаще будет перезаписью, и срок работы флешки сократится в разы. Но это еще не всё. Когда нужно перезаписать кусочек внутреннего блока - флешка выполняет копирование блока с изменением нужного куска. Если во внутреннем блоке всё, кроме перезаписываемого куска, было сTRIM'ано - копирования не будет, только запись новых данных. Таким образом производительность без TRIM тоже под вопросом.
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	166. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 11:33
	> По мере заполнения "надлежащей" файловой системы запись все чаще и > чаще будет перезаписью Боюсь это принципиально невозможно :))) потому что ZFS в принципе не сможет адресовать места больше чем на диске :))) тоесть когда ZFS забьет все свбодное место она сама начнет перезаписывать самые старые неактуальные записи :-))) а писать в резервную область для ZFS принципиально невозможно потому что туда нет прямой адресации. Месье должен четко понимать что SSD диски портятся от перезаписи а не от гранения станых неактуальных блоков. >и срок работы флешки сократится в разы. С точностью до наоборот. > Но это еще не всё. Когда нужно перезаписать кусочек внутреннего блока - > флешка выполняет копирование блока с изменением нужного куска. Блок SSD и блок ZFS должны совпадать. > Если во внутреннем > блоке всё, кроме перезаписываемого куска, было сTRIM'ано - копирования не будет, > только запись новых данных. Таким образом производительность без TRIM тоже под > вопросом. Смотреть выше.
	Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

	171. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 12:08
	> Боюсь это принципиально невозможно :))) потому что ZFS в принципе не сможет Перечитай написанное мной еще раз - ты ниасилил...
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	191. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 16:56
	>> Боюсь это принципиально невозможно :))) потому что ZFS в принципе не сможет > Перечитай написанное мной еще раз - ты ниасилил... Зачем читать я на память помню :-) спецально для месье неасилившего мой предыдущий пост в случае с ZFS и SSD выбор наиболее неактуальных блоков перекладывается с контроллера ssd на zfs что при совпадении размера блока должно дать некоторый прирост производительности, так как контроллеру небудет необходипости считывать и сравнивать блок перед перезаписью.
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	203. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 18:35
	> Зачем читать я на память помню :-) спецально для месье неасилившего мой Чукча не читатель? > предыдущий пост в случае с ZFS и SSD выбор наиболее неактуальных > блоков перекладывается с контроллера ssd на zfs что при совпадении размера Ага, вот только контроллеру SSD совершенно неведомо, что там ZFS, и вести он себя будет вполне обычным образом - используя под веаринг резерв.
	Ответить | Правка | ^ к родителю #191 | Наверх | Cообщить модератору

	230. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 20:28
	> Ага, вот только контроллеру SSD совершенно неведомо, что там ZFS, и вести > он себя будет вполне обычным образом - используя под веаринг резерв. Как же туго с логикой. Вот если на SSD все блоки уже заняты и идет запись занятого блока SSD сделает запись в запасной или с тот который уже занят ?
	Ответить | Правка | ^ к родителю #203 | Наверх | Cообщить модератору

	233. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 20:33
	> Как же туго с логикой. Вот если на SSD все блоки уже > заняты и идет запись занятого блока SSD сделает запись в запасной > или с тот который уже занят ? В свободный. Предвосхищая вопрос: на SSD не бывает ситуации "все блоки заняты". Бывает ситуация "все блоки заполнены, включая резервные, но часть подлежит стиранию". В последней ситуации в довесок еще и GC запустится, и вот тут производительности настанет самый что ни на есть пушной зверёк.
	Ответить | Правка | ^ к родителю #230 | Наверх | Cообщить модератору

	262. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 22:27
	>> Как же туго с логикой. Вот если на SSD все блоки уже >> заняты и идет запись занятого блока SSD сделает запись в запасной >> или с тот который уже занят ? > В свободный. Как же туго с логикой 2. > Предвосхищая вопрос: на SSD не бывает ситуации "все блоки заняты". LOL > Бывает ситуация  "все блоки заполнены, включая резервные, но часть подлежит стиранию". Если ОС может адресовать только видимые ей то как могут быть заполнены резервные ? :-)) > В последней ситуации в довесок еще и GC запустится, и вот тут > производительности настанет самый что ни на есть пушной зверёк. Ну хоть один реальный тест это подтверждающий.
	Ответить | Правка | ^ к родителю #233 | Наверх | Cообщить модератору

	273. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 23:28
	> Как же туго с логикой 2. >> Предвосхищая вопрос: на SSD не бывает ситуации "все блоки заняты". > LOL Да, LOL. Полнейшее, лютое, вопиющее незнание логики работы накопителей на флеше детектед. Сюда хоть загляни, что-ли, для начального ликбеза: http://en.wikipedia.org/wiki/Write_amplification >> Бывает ситуация  "все блоки заполнены, включая резервные, но часть подлежит стиранию". > Если ОС может адресовать только видимые ей то как могут быть заполнены > резервные ? :-)) ОС не имеет отношения к тому, что происходит непосредственно на флеше. Она пинает контроллер, не более. И совершенно не в курсе внутренней структуры флеша. >> В последней ситуации в довесок еще и GC запустится, и вот тут >> производительности настанет самый что ни на есть пушной зверёк. > Ну хоть один реальный тест это подтверждающий. http://www.xbitlabs.com/articles/storage/display/kigston-hyp...
	Ответить | Правка | ^ к родителю #262 | Наверх | Cообщить модератору

	279. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 23:36
	>>> Бывает ситуация  "все блоки заполнены, включая резервные, но часть подлежит стиранию". >> Если ОС может адресовать только видимые ей то как могут быть заполнены >> резервные ? :-)) Элементарно, Ватсон. Левелер их уже заюзал, а стирания еще не произошло - оно фоновое, только по событию GC.
	Ответить | Правка | ^ к родителю #273 | Наверх | Cообщить модератору

	283. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 24-Сен-12, 00:00
	>>>> Бывает ситуация  "все блоки заполнены, включая резервные, но часть подлежит стиранию". >>> Если ОС может адресовать только видимые ей то как могут быть заполнены >>> резервные ? :-)) > Элементарно, Ватсон. Левелер их уже заюзал, а стирания еще не произошло - > оно фоновое, только по событию GC. И что device timeout ? Бред.
	Ответить | Правка | ^ к родителю #279 | Наверх | Cообщить модератору

	286. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Сен-12, 00:07
	> И что device timeout ? Бред. При чем тут device timeout? Нет, всего лишь задержка в несколько МС на стирание. Заметная, но не фатальная.
	Ответить | Правка | ^ к родителю #283 | Наверх | Cообщить модератору

	334. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 21:24
	> При чем тут device timeout? Нет, всего лишь задержка в несколько МС > на стирание. Заметная, но не фатальная. Пипец, хардкорные разработчики бсды должны сгореть со стыдухи за своих "коллег". С такими друзьями никаких врагов не надо.
	Ответить | Правка | ^ к родителю #286 | Наверх | Cообщить модератору

	251. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 21:05
	> Перечитай написанное мной еще раз - ты ниасилил... Он вообще какой-то деревянный. Еще один изен прямо.
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	169. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 11:45
	>> Месье неасилил смысл COW ? Печально ... В таком случае поведайте нам >> что вы понимаете под TRIM а то мало ли вдруг и >> тут что то левое :-)) > Бугага. TRIM нужен для того, чтобы флешка помечала свои блоки, как свободные, > когда они освобождаются в ФС. Зачем это надо? Затем, что внутри > флешки есть механизм веарлевелинга (по сути тот же CoW), который использует > под новые данные незанятые блоки. Но вот - увы и ах > - флешка ничего не знает про файловую систему. Чтобы сказать ей, > что блок свободен - нужен TRIM. Ой, а что же будет, если размер блока ФС случайно или по незнанию пользователя совпадает с размером блока SSD или в целое число раз больше размера блока SSD? > И поэтому, когда все рабочие блоки данных флешки окажутся забитыми (а с > CoW "сверху" без TRIM они окажутся забитыми очень быстро) - флешке > не останется ничего другого, кроме как использовать под веарлевелинг при любой > записи небольшой "временный набор" - резерв пространства как раз для этих > целей. По мере заполнения "надлежащей" файловой системы запись все чаще и > чаще будет перезаписью, и срок работы флешки сократится в разы. В Wiki про TRIM написано, что "Так как очистка ячеек в странице необходима перед тем, как в них можно будет записывать снова, но только целый блок может быть очищен, процесс перезаписи инициирует цикл чтение-очистка-модификация-запись: содержимое целого блока должно быть сохранено в кеше перед тем, как оно может быть удалено с накопителя, перезаписываемые данные модифицируются в кеше и только после этого целый блок (с обновленной страницей) записывается на накопитель. Это явление известно как усиление записи.". Никакого "резерва пространства" в SSD нет. > Но это еще не всё. Когда нужно перезаписать кусочек внутреннего блока - > флешка выполняет копирование блока с изменением нужного куска. Если во внутреннем > блоке всё, кроме перезаписываемого куска, было сTRIM'ано - копирования не будет, > только запись новых данных. Таким образом производительность без TRIM тоже под > вопросом. В кэш SSD помещаются данные из целого блока (SSD), так что применимость или не применимость TRIM тут никакой роли не играет — "усиление записи" для используемых страниц (так как в традиционных ФС размер блока много меньше размера блока SSD, то они будут) всё равно произойдёт.
	Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

	173. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 12:13
	> Ой, а что же будет, если размер блока ФС случайно или по > незнанию пользователя совпадает с размером блока SSD или в целое число > раз больше размера блока SSD? Ничего не будет. Флешка как не знала о том, что блок логически высвобожден, так и не узнает. И не будет использовать данный блок для левелинга. > В Wiki про TRIM написано, что "Так как очистка ячеек в странице На заборе тоже много чего написано. Да, кроме всего прочего, TRIM - нормальный способ выполнить очистку блока заранее, до того, как он понадобится системе. Стирание - не ахти какая быстрая операция, и именно поэтому производительность ZFS будет на флешке сильно ниже традиционок - эти FS не очищают блоки, и каждая перезапись на них будет инициировать стирание. Единственный способ этого избежать - TRIM'ать "устаревшие" ненужные более блоки после гарантированного завершения транзакций. Делает ли это BTRFS - не знаю. > В кэш SSD помещаются данные из целого блока (SSD), так что применимость > или не применимость TRIM тут никакой роли не играет Хотелось бы пруфлинк на спецификацию записи конкретным контроллером с обоснованием сказанного.
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

	179. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от iZEN (ok) on 23-Сен-12, 12:33
	>> Ой, а что же будет, если размер блока ФС случайно или по >> незнанию пользователя совпадает с размером блока SSD или в целое число >> раз больше размера блока SSD? > Ничего не будет. Флешка как не знала о том, что блок логически > высвобожден, так и не узнает. И не будет использовать данный блок > для левелинга. Для CoW аппаратный левелинг неактуален — он делается на программном уровне самой CoW ФС. >> В Wiki про TRIM написано, что "Так как очистка ячеек в странице > На заборе тоже много чего написано. Так сотри и напиши правильно. Кто мешает? > Да, кроме всего прочего, TRIM - нормальный способ выполнить очистку блока заранее, > до того, как он понадобится системе. Стирание - не ахти какая > быстрая операция, и именно поэтому производительность ZFS будет на флешке сильно > ниже традиционок - эти FS не очищают блоки, и каждая перезапись > на них будет инициировать стирание. Согласен. Каждая запись в ZFS будет инициировать стирание всех (если размеры блоков совпадают) страниц блока SSD, новые данные будут записываться после обнуления предыдущего содержимого. А в традиционных ФС вместо предварительного стирания страниц (они уже ранее обнулены GC после команды TRIM) будет происходить "усиление записи" немодифицированных страниц (так как размер блока ФС намного меньше размера блока SSD), что равносильно искусственному изнашиванию ячеек флэш-памяти. Таким образом за ZFS преимущество в том, что нет "усиления записи" отдельных (немодифицированных) страниц блока SSD, но теряется скорость записи данных за счёт дополнительной операции по обнулению блока SSD. За традиционными ФС преимущество в скорости записи, так как обнуление отдельных страниц под блок ФС было выполнено на аппаратном уровне после команды TRIM, однако "усиление записи" немодифицированных страниц в блоке SSD, куда записывается меньший по размеру блок ФС, приводит к износу ячеек памяти. >> В кэш SSD помещаются данные из целого блока (SSD), так что применимость >> или не применимость TRIM тут никакой роли не играет > Хотелось бы пруфлинк на спецификацию записи конкретным контроллером с обоснованием сказанного. Wiki/TRIM
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

	208. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 18:45
	> Для CoW аппаратный левелинг неактуален — он делается на программном уровне самой > CoW ФС. Ага, щаззз. Ну то-есть оно бы может и размазывало записи, не будь там контроллера. Но проблема не в том. Проблема в том что контроллер - есть. И он не знает какие блоки используются. Поэтому вынужден очищать блоки только когда туда пытаются писать по факту. А не заранее. И вот это является очень неоптимальным режимом работы. И места для маневра так что флеш быстрее затирается из-за невозможности оптимизировать операции записи, и запись медленнее происходит. > Согласен. Каждая запись в ZFS будет инициировать стирание всех (если размеры блоков > совпадают) страниц блока SSD, И вот это - плохо. Потому что операция стирания - медленная и деструктивная. Так и запишем: ZFS при прочих равных будет медленнее и деструктивнее чем конкуренты из-за неподдержки TRIM. > новые данные будут записываться после обнуления предыдущего содержимого. > А в традиционных ФС вместо предварительного стирания страниц (они уже > ранее обнулены GC после команды TRIM) будет происходить "усиление записи" Что есть "усиление записи"? Выражайся пожалуйста общепринятыми терминами. В любой ФС с поддержкой trim запись будет просто записью страниц без нужды что-то там стирать и перетрясать. > немодифицированных страниц (так как размер блока ФС намного меньше размера блока SSD), > что равносильно искусственному изнашиванию ячеек флэш-памяти. "Преимущество" ZFS в том что она поставит р@ком логику размазывания записи, загнав контроллер SSD в наихучший режим работы из всех возможных. По поводу чего оно будет тормознее работать и сильнее протирать флеш. Erase как раз весьма деструктивная операция. А т.к. пространства для маневра у GC контроллера будет минимум, erase будет делаться постоянно, по поводу и без. > Таким образом за ZFS преимущество в том, что нет "усиления записи" отдельных > (немодифицированных) страниц блока SSD, но теряется скорость записи данных за счёт > дополнительной операции по обнулению блока SSD. Таким образом, у ZFS вообще нет преимуществ на SSD и есть недостатки. А у btrfs вполне себе реализован trim. Вот в таком виде подобная ФС уже прилично накладывается на логику флеша и GC'у контроллера SSD не мешает. > За традиционными ФС преимущество в скорости записи, так как обнуление отдельных страниц > под блок ФС было выполнено на аппаратном уровне после команды TRIM, На фирмварном. Это сложная операция, при которой GC собирает все используемые страницы блока, группирует их, сохраняет нужные куда-то еще и наконец стирает блок. > однако "усиление записи" немодифицированных страниц в блоке SSD, куда записывается меньший > по размеру блок ФС, приводит к износу ячеек памяти. Больше всего изнашивает память erase как раз. Да еще для довольно большого региона сразу, в отличие от записей страниц. > Wiki/TRIM Там нет спецификаций касающихся логики работы конкретных контроллеров.
	Ответить | Правка | ^ к родителю #179 | Наверх | Cообщить модератору

	209. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 18:50
	> И вот это - плохо. Потому что операция стирания - медленная и > деструктивная. Так и запишем: ZFS при прочих равных будет медленнее и > деструктивнее чем конкуренты из-за неподдержки TRIM. > "Преимущество" ZFS в том что она поставит р@ком логику размазывания записи, загнав > контроллер SSD в наихучший режим работы из всех возможных. По поводу > чего оно будет тормознее работать и сильнее протирать флеш. Erase как > раз весьма деструктивная операция. А т.к. пространства для маневра у GC > контроллера будет минимум, erase будет делаться постоянно, по поводу и без. Абсолютно согласен. Чем меньше пространства у левелера под маневры, и чем чаще приходится делать ERASE - тем хуже флешу.
	Ответить | Правка | ^ к родителю #208 | Наверх | Cообщить модератору

	335. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 21:32
	> Абсолютно согласен. Чем меньше пространства у левелера под маневры, и чем чаще > приходится делать ERASE - тем хуже флешу. Я не понимаю почему они в такое не въезжают. Тупые какие-то - не могут массивы блоков представить и что произойдет в такой или эдакой ситуации.
	Ответить | Правка | ^ к родителю #209 | Наверх | Cообщить модератору

	222. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 20:05
	>> Для CoW аппаратный левелинг неактуален — он делается на программном уровне самой >> CoW ФС. > Ага, щаззз. Ну то-есть оно бы может и размазывало записи, не будь > там контроллера. Но проблема не в том. Проблема в том что > контроллер - есть. И он не знает какие блоки используются. Поэтому > вынужден очищать блоки только когда туда пытаются писать по факту. А > не заранее. И вот это является очень неоптимальным режимом работы. Откуда ты знаешь? Без TRIM контроллер не запускает механизм очистки, а значит нет вынужденной диспетчеризации потоков команд на запись данных от ФС и внутреннего процесса очистки. То есть тормозить и диспетчировать очереди обнуления/записи контроллеру не нужно. Запись ФС будет происходить без задержек кроме той, что нужна на полную очистку блока (принимаем, что размер блока ФС == размеру блока SSD). > И > места для маневра так что флеш быстрее затирается из-за невозможности оптимизировать > операции записи, и запись медленнее происходит. Вывод из посылки, которая не верна. >> Согласен. Каждая запись в ZFS будет инициировать стирание всех (если размеры блоков >> совпадают) страниц блока SSD, > И вот это - плохо. Потому что операция стирания - медленная и > деструктивная. Так и запишем: ZFS при прочих равных будет медленнее и > деструктивнее чем конкуренты из-за неподдержки TRIM. Почему она медленнее, если для традиционных ФС с поддержкой TRIM стирание тоже выполняется, но из-за малого размера блока ФС, содержимое блока SSD каждый раз помещается в кэш SSD, делается запись в заранее обнуленные страницы, но так же И делается "усиление записи" для всех остальных страниц блока SSD, не участвующие в хранении данных записываемого блока ФС. Контроллер SSD записывает данные на флэш только поблочно, при этом используется оперативный кэш для заполнения вновь затребованных страниц и освежения немодифицируемых страниц. Это способствует большему износу ячеек памяти, чем если бы блок ФС совпадал с размером блока SSD. Частая перезагрузка оперативного кэша контроллера SSD из-за малого размера блока традиционных ФС приводит к частому "освежению" немодифицированных страниц и уменьшается ресурс ячеек. TRIM тут никаким боком не поможет, кроме как увеличит скорость записи. Ресурс флэш тратиться на освежение, которого можно избежать в принципе — сделать размер блока ФС равным размеру блока SSD. >> новые данные будут записываться после обнуления предыдущего содержимого. >> А в традиционных ФС вместо предварительного стирания страниц (они уже >> ранее обнулены GC после команды TRIM) будет происходить "усиление записи" > Что есть "усиление записи"? Выражайся пожалуйста общепринятыми терминами. В любой ФС с > поддержкой trim запись будет просто записью страниц без нужды что-то там > стирать и перетрясать. Контроллер SSD по команде ФС записывает данные на флэш только поблочно, при этом имеются в виду не блоки ФС (хотя и они тоже в этом процессе участвуют), а более объёмная по отношению к ФС величина — блок SSD, имеющий размер 512 килобайт. Модификация данных происходит в оперативном кэше SSD с целым блоком. Если есть очищенные страницы в блоке, то их не нужно предварительно обнулять (это сделал GC после команды TRIM), скорость записи на них высока. Однако в блоке SSD присутствуют и другие блоки ФС, которые не модифицируются. Но они тоже будут перезаписаны (освежены), так как контроллер SSD записывает данные на флэш только целым блоком из оперативного кэша. Это называется "усилением записи". > "Преимущество" ZFS в том что она поставит р@ком логику размазывания записи, загнав > контроллер SSD в наихучший режим работы из всех возможных. Да ну. Оптимальное распределение блоков ФС по всему пространству носителя вроде как не тайна за семью печатями. > По поводу > чего оно будет тормознее работать и сильнее протирать флеш. Erase как > раз весьма деструктивная операция. А т.к. пространства для маневра у GC > контроллера будет минимум, erase будет делаться постоянно, по поводу и без. GC работает с отдельными страницами. И тут никак не влияет на скорость поблочной (пере)записи данных, так как за один раз стирается и модифицируется весь блок SSD — мы говорим для условия, когда размеры блоков ФС и SSD совпадают. Когда же размеры блоков ФС и SSD не совпадают, то тут начинается интересная штука: при интенсивных операциях записи-стирания данных GC может и не успеть обнулить помеченные TRIM страницы, поэтому новая запись в них будет происходить с ПРЕДВАРИТЕЛЬНЫМ обнулением содержимого непосредственно перед модификацией. И мы тут сильно потеряем в скорости записи на мелких блоках ФС, так как будет постоянная перезагрузка оперативного кэша SSD для модификации его блоков. В случае с совпадением размеров блоков операция очистки производится для всего блока SSD сразу, данные записываются большими порциями — нет оверхеда на подчистку отдельных страниц. >> Таким образом за ZFS преимущество в том, что нет "усиления записи" отдельных >> (немодифицированных) страниц блока SSD, но теряется скорость записи данных за счёт >> дополнительной операции по обнулению блока SSD. > Таким образом, у ZFS вообще нет преимуществ на SSD и есть недостатки. > А у btrfs вполне себе реализован trim. Вот в таком виде > подобная ФС уже прилично накладывается на логику флеша и GC'у контроллера > SSD не мешает. Осталось проверить поведение обеих ФС при интенсивных операциях записи-стирания данных. ;) Выяснится, что GC может и не успевает за подчистками. Заодно и проверить ресурс флэшатины под обеими ФС. ;) >> За традиционными ФС преимущество в скорости записи, так как обнуление отдельных страниц >> под блок ФС было выполнено на аппаратном уровне после команды TRIM, > На фирмварном. Это сложная операция, при которой GC собирает все используемые страницы > блока, группирует их, сохраняет нужные куда-то еще и наконец стирает блок. Ты действительно веришь, что GC после своей работы с блоком разделяет блок на отдельные страницы (очищенные и занятые), компонует очищенные в чистые блоки SSD и складирует их куда-то? Вот только КУДА — наверно, в Астрал, так как метаинформацию для такой перекомпоновки потребуется столько же, что и сам полезный объём SSD. ;)
	Ответить | Правка | ^ к родителю #208 | Наверх | Cообщить модератору

	225. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 20:24
	> контроллеру не нужно. Запись ФС будет происходить без задержек кроме той, > что нужна на полную очистку блока (принимаем, что размер блока ФС О боже. В этом и проблема. Очистка блока по меркам CPU/шины - операция длиною в вечность. Ее лучше делать в фоне, не заставляя шину ждать. А писать в свободные блоки левелера. Я тебе секрет открою, так и быть - современный контроллер всё равно не будет стирать целевой блок, запишет в свободный блок "резерва". Поэтому даже потерю производительности заметишь не всегда. Но вот блоков этих мало, и веаринг драйва в итоге будет неоптимальным. Совсем-совсем. > Контроллер SSD записывает данные на флэш только поблочно Бред. Поблочно производится только очистка. Запись может идти постранично. > Контроллер SSD по команде ФС записывает данные на флэш только поблочно Чушь. См. выше. > величина — блок SSD, имеющий размер 512 килобайт. На практике - от 64Кб до 2Мб в зависимости от организации флеша. Встречаются варианты и с <64Кб, но сомневаюсь, что идут в "бытовую" продажу в виде SSD. В основном это встроенные флеши на разных мобилках и прочем. > Модификация данных происходит в оперативном кэше SSD с целым блоком. Если есть Еще раз: никакой модификации данных не происходит. Данные пишутся в один из "резервных" блоков постранично, на чистые страницы. Если чистой страницы на данный момент нет - запускается GC левелера, превращая всю операцию в томительное ожидание. > Но они тоже будут перезаписаны (освежены), так как контроллер SSD записывает Это происходит только в моменты работы GC. > Да ну. Оптимальное распределение блоков ФС по всему пространству носителя вроде как > не тайна за семью печатями. Это делает сам контроллер. Все попытки навязать ему сверху какое-либо распределение приведут только к быстрому занятию всех активных блоков рабочего набора. А без TRIM - еще и к тому, что контроллер будет вынужден всегда веарить за счёт резерва. > для модификации его блоков. В случае с совпадением размеров блоков операция > очистки производится для всего блока SSD сразу, данные записываются большими порциями > — нет оверхеда на подчистку отдельных страниц. Только в случае, если есть полностью свободный блок. А учитывая, что TRIM у нас нет, и пишем, как попало - скорее всего полностью свободных блоков не будет, и на каждую запись будем получать ERASE. Малый размер блока даже несколько более выгоден в случае SSD, поскольку позволяет не делать ERASE на запись 1 байта, если в наличии есть свободная страница. В идеале блок должен быть именно размером со страницу, чтобы не выполнять копирования, и не стирать целые блоки при записи мелких файлов. > Ты действительно веришь, что GC после своей работы с блоком разделяет блок > на отдельные страницы (очищенные и занятые), компонует очищенные в чистые блоки > SSD и складирует их куда-то? Именно так он и работает. Читай публикации по веарлевелингу флешей. Работа GC чем-то сходна с классическими дефрагментаторами. Для перекомпоновки, к слову, достаточно всего лишь одного резервного блока. Но левелинг при этом будет никакой, естественно, поэтому на "резерв" реально берется обычно 5-10% от объёма флеша.
	Ответить | Правка | ^ к родителю #222 | Наверх | Cообщить модератору

	300. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 06:39
	> и веаринг драйва в итоге будет неоптимальным. Совсем-совсем. ... > Бред. Поблочно производится только очистка. Запись может идти постранично. Два чая этому гражданину. >> величина — блок SSD, имеющий размер 512 килобайт. > На практике - от 64Кб до 2Мб в зависимости от организации флеша. Ну это же изен. Я думаю что даташиты на микросхемы флеша он вообще никогда не читал. > Встречаются варианты и с <64Кб, но сомневаюсь, что идут в "бытовую" > продажу в виде SSD. В основном это встроенные флеши на разных мобилках и прочем. Собственно 512Кб достаточно типовой размер нынче. Но в целом это на усмотрение производителя чипов, так что чего ради изен к 512К привязался... как будто он еще и выровнять сможет на границу блока :) > "резервных" блоков постранично, на чистые страницы. Если чистой страницы на данный > момент нет - запускается GC левелера, превращая всю операцию в томительное ожидание. Ну вот это и будет модификацией. Только от этого SSD пытается уйти но без TRIM не особо получится. > только к быстрому занятию всех активных блоков рабочего набора. А без > TRIM - еще и к тому, что контроллер будет вынужден всегда > веарить за счёт резерва. А до изена это не доходит. Он видимо все-таки прочел как работает флеш память, но garbage collector + размазка записей кажется уже за пределами его понимания. > Только в случае, если есть полностью свободный блок. А учитывая, что TRIM > у нас нет, и пишем, как попало - скорее всего полностью свободных блоков не будет, > и на каждую запись будем получать ERASE. Вот именно. А изен почему-то этого не понимает. Ха-ха. > Малый размер блока даже несколько более выгоден в случае SSD, поскольку > позволяет не делать ERASE на запись 1 байта, если в наличии > есть свободная страница. Без trim чревато тем что постепенно все зафрагментируется и свалится в режим когда для записи 1 байта надо тереть erase block. А с trim - ну да, вполне нормально будет. > В идеале блок должен быть именно размером со страницу, ...и совпадать с ее границами :) > Именно так он и работает. Читай публикации по веарлевелингу флешей. Да это ж изен, для него нормально бред нести. Хотя как ни странно он начинает немного понимать как флеш работает в плане устройства по блокам. Глядишь, лет через 10 начнет понимать и работу wear leveling :)
	Ответить | Правка | ^ к родителю #225 | Наверх | Cообщить модератору

	297. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от Аноним (??) on 24-Сен-12, 06:15
	> Откуда ты знаешь? Интересовался устройством FTL (flash translation layer) и наблюдал как это вообще работает. Ну вот такое у меня хобби есть. Это как раз примерно то самое что в SSD нынче суют. > Без TRIM контроллер не запускает механизм очистки, Спасибо, Кэп. > а значит нет вынужденной диспетчеризации потоков команд на запись данных от ФС > и внутреннего процесса очистки. То есть тормозить и диспетчировать очереди > обнуления/записи контроллеру не нужно. Ты такой умный что пипец. Правда при всем этом ты не знаешь что то что именно сделает контроллер по поводу TRIM - вообще не специфицировано. То-есть, это всего лишь хинт контроллеру что мы не юзаем данные блоки и их можно разгрести. Когда именно и как контроллер это изволит разгрести и что он сделает по этому поводу - вообще его дело. Он может например подождать минимальной нагрузки на накопитель в фоне разрулить. > Запись ФС будет происходить без задержек кроме той, > что нужна на полную очистку блока (принимаем, что размер блока ФС == размеру > блока SSD). Опух? Erase block флеша как правило нынче 512Кб и поди еще попробуй угадать границы оного, да еще с блоками переменного размера которыми ты тут так понтуешься. И кстати erase - это весьма длительная операция. Если программирование страницы может быть довольно быстрой процедурой (и то не всегда), то erase блока запросто растягиватеся на многие миллисекунды. Максимальное время обычно указано в даташите на микросхемы флеша. >> места для маневра так что флеш быстрее затирается из-за невозможности оптимизировать >> операции записи, и запись медленнее происходит. > Вывод из посылки, которая не верна. Вполне себе верна. Чем больше пространства для маневра - тем реже приходится судорожно дергаться на каждый пшик и тем лучше можно соптимизировать операции. Собственно грубый прототип того что получается ты и так увидел на забитом под завязку томе. А тут похожая логика: размазывание записи - по сути вариант CoW получается. Ну и общие свойства стало быть похожи. Как ты понимаешь, закладывать большой маневровый запас всем обломно: его не видно в емкости накопителя которая написана на упаковке, а вот место в чипах памяти оно жрет. Производителю не нравится напаивать больше памяти при том что цифра на упаковке не увеличивается. Ведь хомячки покупают гигабайты :) > Почему она медленнее, если для традиционных ФС с поддержкой TRIM стирание тоже выполняется, В этом случае как раз контроллер имеет все шансы заранее сгрести мусор. Тогда стирания не будет, только программирование страниц. И чем больше места не занято - тем больше пространства для маневра: может получиться воткнуть желаемую запись куда-то в уже очищенные страницы. А если trim нет то постепенно все придет к схеме когда "проблема решается по мере возникновения" - т.е. при вообще каждой записи надо чистить какой-то блок чтобы оформить запись. Заранее почистить нельзя т.к. неизвестно что используется а что нет. По поводу чего и скорость записи просядет, и возможности оптимизации размещения записей у контроллера будут откушены по полной программе. Хинт: если бы все было так как ты говоришь, никто не стал бы геморроиться с реализацией команды TRIM от которой и так нет эффекта. По-моему, это даже детсадовцу понятно? :) > но из-за малого размера блока ФС, содержимое блока SSD каждый > раз помещается в кэш SSD, делается запись в заранее обнуленные страницы, > но так же И делается "усиление записи" для всех остальных страниц > блока SSD, не участвующие в хранении данных записываемого блока ФС. Еще раз: что такое "усиление записи"? Нельзя ли выражаться общепризнанными терминами? Ну там read, erase, page programming, ... ? > Контроллер SSD записывает данные на флэш только поблочно, В общем случае - постранично. У флеша 2 вида блоков. > способствует большему износу ячеек памяти, чем если бы блок ФС совпадал > с размером блока SSD. Проблема в том что в ZFS крайне маловероятно что блок ФС совпадет с блоком SSD. Поэтому - да, ты очень хорошо подсказываешь - часто будет тереться ДВА блока там где хватило бы одного. Ну а с блоками переменного размера ты еще и никогда не сможешь выровнять ФС так чтобы ее блоки совпали с блоками флеша. Так что многие блоки ФС попадут на пересечение блоков флеша. Вот ить незадача то. Тут вам и двукратный wear, и более тормозная запись лишний раз. В случае с TRIM это не такая уж проблема, т.к. erase не будет и будет только программирование страниц по количеству записываемого. А вот без него логика контроллера свалится в черти-какой штопор. Грубый прикидон мне подсказывает что экстенты + trim будут работать не в пример лучше, т.к. в идеальном случае SSD просто запрограммит страницы и по объему желаемой записи и ... все :). Юзание TRIM порядочно приближает к этому идеалу. Без него будет максимально паршивый сценарий вообще каждый раз. > Частая перезагрузка оперативного кэша контроллера SSD из-за малого размера блока традиционных > ФС приводит к частому "освежению" немодифицированных страниц и уменьшается ресурс ячеек. Ресурс ячеек прежде всего уменьшается от ERASE'а блоков на каждый пук. А если пространства для маневрирования и удовлетворения текущего запроса нет - поневоле придется дергаться и тереть блоки на каждый пук. Правда просто? > TRIM тут никаким боком не поможет, кроме как увеличит скорость записи. Он даст больше пространства для маневра: может получиться оформить операцию записи как только программирование страниц. Без стирания вообще. Откуда и рост скорости. И меньшая деструктивность процесса в среднем. Грубо говоря, повышается КПД логики SSDшного контроллера. > Ресурс флэш тратиться на освежение, которого можно избежать в принципе — > сделать размер блока ФС равным размеру блока SSD. Ну да, ну да, и угадать размещение блока ФС чтобы не попало на границы блоков флеша, когда будет на ровном месте тереться 2 блока вместо 1 просто потому что блок ФС угораздило же лежать в обоих. А блоки переменного размера окончательно испортят компот, сделав это начинание невозможным. Не говоря о том что тратить блок 512Кб на файлик в 1Кб размером будет достаточно обидно. > Контроллер SSD по команде ФС записывает данные на флэш только поблочно, Минимальной единицой записи в флеш является страница. Есть более крупные блоки - группы страниц, стирание в 0 происходит только большими группами. Ты о каких из блоков? > при этом имеются в виду не блоки ФС (хотя и они тоже > в этом процессе участвуют), а более объёмная по отношению к ФС > величина — блок SSD, имеющий размер 512 килобайт. Значит, видимо, об erase-блоках. Теоретически, если тебе удастся разложить блоки ФС с 512-Кб блоками так чтобы они совпали с секторами флеша - ты, натурально, выиграешь по скорости записи. Практически - флаг тебе в руки это сделать в ZFS с ее блоками переменного размера и смотри не удавись от жабы когда файл 1 Кб начнет жрать 512Кб блок, если это вдруг получится. > Модификация данных происходит в оперативном кэше SSD с целым блоком. Если есть > очищенные страницы в блоке, то их не нужно предварительно обнулять (это > сделал GC после команды TRIM), скорость записи на них высока. Однако > в блоке SSD присутствуют и другие блоки ФС, которые не модифицируются. > Но они тоже будут перезаписаны (освежены), Проблема в том что ты вроде бы начинаешь вкуривать что такое read-modify-write, но совершенно забыл про wear leveling. Который в общем случае постарается сделать запись в другое место флеша чтобы размазать запись. И вот тут возможны варианты. В случае когда юзается TRIM - есть свобода маневра и можно просто оформить это как программирование страниц. А вот если trim нет - с чистыми блоками небогато. И вот тут придется разгребать хлам по полной. Попав на дополнительные процедуры read-modify-write и erase "просто потому что это надо хоть куда-то записать, черт возьми". А когда нет того что хотелось - придется лепить из того что есть и распихивать ну хоть как-то. Как оптимально - всем понятно. Поэтому собственно и сделали trim ;) > так как контроллер SSD записывает данные на флэш только целым блоком > из оперативного кэша. Это называется "усилением записи". А я думал что это называется read-modify-write. > Да ну. Оптимальное распределение блоков ФС по всему пространству носителя вроде как > не тайна за семью печатями. С одной стороны, прикольно что до изена стало доползать как выравнивать фс на блоки флеша. С другой - я бы посмотрел как ты ZFS на блок флеша выровняешь :D. > GC работает с отдельными страницами. Логично - он расчищает блоки чтобы можно было их erase'нуть без потери данных, перегруппируя страницы в другие блоки, сдвигая их так что они без "прорех" из неактуальных данных. Вот только у этой логики отбирается вся свобода маневра когда trim нет. По поводу чего оно натужно дергается в попытках выкроить свободные блоки "ну хоть как нибудь" а не разрулить запрос "как оптимальнее". Trim это основательно лечит. > весь блок SSD — мы говорим для условия, когда размеры блоков > ФС и SSD совпадают. Кроме размера должны еще и границы блоков совпасть. А вот это уже не самое простое требование. А с блоками переменного размера - ну ты понял, да? :) > для модификации его блоков. В случае с совпадением размеров блоков операция > очистки производится для всего блока SSD сразу, данные записываются большими порциями > — нет оверхеда на подчистку отдельных страниц. Если забить на часть бреда, вот этот кусок даже в принципе верен. Вот только это весьма идеализированный случай. И маловероятно что ты нечто такое на ZFS вообще сможешь изобразить. > Осталось проверить поведение обеих ФС при интенсивных операциях записи-стирания данных. > ;) Выяснится, что GC может и не успевает за подчистками. В клиническом случае может и не успеть. Вот только в этом случае SSD придется менять с регулярностью чартерных рейсов. У современного MLC ресурс не больно огромный, порядка нескольких тысяч циклов всего. Так что (в идеальном случае) несколько тысяч записей объемом с накопитель и усе, он начнет рассыпаться. В реальном даже меньше благодаря упомянутым неоптимальностям. >  Заодно и проверить ресурс флэшатины под обеими ФС. ;) В режиме когда GC не успевает разгребаться, ресурс будет "ой, опять пора менять SSD" :). А в менее суровых случаях имхо ФС с trim выиграют. > Ты действительно веришь, что GC после своей работы с блоком разделяет блок > на отдельные страницы (очищенные и занятые), компонует очищенные в чистые блоки > SSD и складирует их куда-то? Естественно, на то и GC. Иначе он мог бы нарваться на тупые и смешные ситуации например когда в каждом блоке засрано по странице. Так что полную страницу записать уже нельзя. Вроде бы места дофига а записывать некуа. И чего? > Вот только КУДА — наверно, в Астрал, так как метаинформацию для такой > перекомпоновки потребуется столько же, что и сам полезный объём SSD. ;) Ну нифига себе у тебя технологии, если запись о трансляции блока занимает столько же сколько сам блок.
	Ответить | Правка | ^ к родителю #222 | Наверх | Cообщить модератору

	309. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Сен-12, 07:35
	> Интересовался устройством FTL (flash translation layer) и наблюдал как это вообще работает. > Ну вот такое у меня хобби есть. Это как раз примерно > то самое что в SSD нынче суют. О, хоть кто-то :) Я в свое время реверсил FTL (TFS) на Samsung'ах X100/X600/E700 - разбирал данные в т.ч. с полумертвых аппаратов. > Проблема в том что в ZFS крайне маловероятно что блок ФС совпадет > с блоком SSD. Поэтому - да, ты очень хорошо подсказываешь - > часто будет тереться ДВА блока там где хватило бы одного. Absolutely. А еще чаще будет тереться/писаться целая пачка блоков там, где хватило бы записи одной страницы. Пример - перезапись 1 байта в файле :) Для CoW это вообще страшнейшая операция. А в случае блок=блок ZFS - в любом случае получим запись целых блоков вместо страниц.
	Ответить | Правка | ^ к родителю #297 | Наверх | Cообщить модератору

	316. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 24-Сен-12, 11:28
	> А еще чаще будет тереться/писаться целая пачка блоков там, где хватило бы > записи одной страницы. Пример - перезапись 1 байта в файле :) Вот для этого существует дедуплекация. > Для CoW это вообще страшнейшая операция. А в случае блок=блок ZFS > - в любом случае получим запись целых блоков вместо страниц. Если там будет контроллер SF2*** там все будет свсем не так как вы думаете :-)))
	Ответить | Правка | ^ к родителю #309 | Наверх | Cообщить модератору

	320. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Сен-12, 12:19
	>> А еще чаще будет тереться/писаться целая пачка блоков там, где хватило бы >> записи одной страницы. Пример - перезапись 1 байта в файле :) > Вот для этого существует дедуплекация. При чем тут дедупликация, вообще? >> Для CoW это вообще страшнейшая операция. А в случае блок=блок ZFS >> - в любом случае получим запись целых блоков вместо страниц. > Если там будет контроллер SF2*** там все будет свсем не так как > вы думаете :-))) А если бы еще и во рту грибы росли...
	Ответить | Правка | ^ к родителю #316 | Наверх | Cообщить модератору

	321. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от nagual (ok) on 24-Сен-12, 12:23
	> А если бы еще и во рту грибы росли... Месье поял насколько он неправ ? Ну не расстраивайтесь так из-за ерунды. Вот позитивная статья http://b-a-t.livejournal.com/210090.html для поднятия настроения ... особенно каменты :-)))
	Ответить | Правка | ^ к родителю #320 | Наверх | Cообщить модератору

	322. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Сен-12, 12:24
	>> А если бы еще и во рту грибы росли... Пойми - ошибка конкретной фирмвари конкретного контроллера будет исправлена, если она есть. Да и мнение одного хомячка не определяет.
	Ответить | Правка | ^ к родителю #321 | Наверх | Cообщить модератору

	341. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 22:37
	> О, хоть кто-то :) Я в свое время реверсил FTL (TFS) на > Samsung'ах X100/X600/E700 - разбирал данные в т.ч. с полумертвых аппаратов. Сименсы, сэр. Все что на 166-м проце ;). Поскольку сименсу копание в некоторых блоках не нравилось, они перекрыли запись ряда интересных блоков через свой дебажный протокол. Пришлось пойти сложным путем: были написаны загрузчики которые шлются в девайс, инициализируют железо, детектируют тип флеща и его набор команд (intel, AMD) ну и делают чтение, стирание и запись (по сути некий эквивалент олдскульных программ-мониторов, только ремотненько, по UART-у). А кроме всего прочего был расковырян формат области EEPROM в флеше, оказавшийся простой флешовой файловой системой. С простой формой wear leveling и номерами блоков вместо названий файлов. Для наиболее интересных из них был отбабахан действующий макет read-modify-write. Правда полноценный GC делать меня заломало, так что в сильно экзотических случаях оно в принципе могло обломаться. Впрочем, на практике это случалось только у особо крутых извращенцев долго мучавших зону EEPROM, таковых было очень мало и проблема не существовала. Отличная штука для понимания устройства флешовых систем: простенько но со вкусом и все основные элементы - на месте. А потом мне вообще случайно попался в лапы сорц полновесного интеловского FTL который они уже тогда раздавали просто так. И я понял что большинство из логики работы этой штуки я уже где-то видел. В общем то вся эта механика у всех достаточно похожа по общей логике работы. >> часто будет тереться ДВА блока там где хватило бы одного. > Absolutely. Ну я то представляю себе что получится. А вот nagual-ы и izen-ы очень врядли. Зато пальцы то погнуть хочется :) > А еще чаще будет тереться/писаться целая пачка блоков там, где хватило бы > записи одной страницы. Ну да. Одно дело если GC будет надрываться и пытаться выкроить место из того что есть под то что хотелось и другое если просто страницы распихали и готово :) > Пример - перезапись 1 байта в файле :) Для CoW это вообще страшнейшая операция. Это почему? Оформляется выносок в сторону. Это достаточно быстро само по себе. Вот правда метаданных будет больше чем данных + фрагментация возрастет. Если все время глушить такие запросы - ФС деградирует разумеется, но это не есть типовой юзкейс. А ФС оптимизируют все-таки на более-менее типовые сценарии. То что всякими извращениями можно любую ФС на лопатки уложить - ни для кого не новость :) > А в случае блок=блок ZFS - в любом случае получим запись целых блоков вместо страниц. ИМХО эти чудики просто прикрывают свою голопопость и отсутствие надежды на поддержку trim своим бредом. Смешные они, эти юные бсдшники :)
	Ответить | Правка | ^ к родителю #309 | Наверх | Cообщить модератору

	343. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Сен-12, 22:51
	> Сименсы, сэр. Все что на 166-м проце ;). Поскольку сименсу копание в Ох как, значит коллеги :) > свой дебажный протокол. Пришлось пойти сложным путем: были написаны загрузчики которые > шлются в девайс, инициализируют железо, детектируют тип флеща и его набор Почти то же самое. Загрузчики только юзали самсунговские, но тоже реверсилась система команд, и прошивалка делалась, ага. SGHFD (SGH Flasher/Dumper, уже из области археологии ныне). > А кроме всего прочего был расковырян формат области EEPROM в флеше, > оказавшийся простой флешовой файловой системой. С простой формой wear leveling и > номерами блоков вместо названий файлов. У самсунгов внутри оказалось некое подобие FAT, разложенное поверх сносного веарлевелера. Реверсинг X100 (TFS 3.03) доставил много веселых часов, потому что некоторые значения номеров блоков в левелере считались откровенно через задницу. А реверсинг E700 (TFS 3.12) вообще сломал мозг - там левелер слегка нелинеен. --- [из сохранившегося]    POverEnd denotes the sector from which area after PStart + Remap Data    Length + Remap Info Length continues (probably, but it can be relatively    simply calculated without using this field).    One more thing. If remap sectors come over filesystem length (as    example mapping 23 sectors to 3C6 gets us to sector 3E8 which is    just outbound of the data area, then it is wrapped to sector 0    and further, so in our case 3E7 is 0 and 3E8 is really 1. Crap. --- [из сохранившегося] > Отличная штука для понимания устройства флешовых систем: простенько но со вкусом > и все основные элементы - на месте. +1 > А потом мне вообще случайно попался в лапы сорц полновесного интеловского FTL > который они уже тогда раздавали просто так. И я понял что > большинство из логики работы этой штуки я уже где-то видел. В > общем то вся эта механика у всех достаточно похожа по общей > логике работы. >> Пример - перезапись 1 байта в файле :) Для CoW это вообще страшнейшая операция. > Это почему? Оформляется выносок в сторону. > Вот правда метаданных будет больше чем данных. ВотЪ. Приятно говорить с понимающим человеком :)
	Ответить | Правка | ^ к родителю #341 | Наверх | Cообщить модератору

	397. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 25-Сен-12, 21:08
	> Ох как, значит коллеги :) Получается что так :) > Почти то же самое. Загрузчики только юзали самсунговские, А в этом случае свои были, сделанные на основе изучения сименсовских и штук от других граждан, etc. Сименсовские сильно ориентированы на флешинг апдейтов + у них протокол дурной: мелкие блоки. Заломало логику с окнами делать и прочая. Получилась штука простая как дубинка и с кучей упрощений. Но вполне работающая и в 10 раз меньше кода в бутлоадере + простой, понятный и неубиваемый протокол. Хоть и халтурка слегка (полная синхроншина, ни окон протокола, ни прерываний UART, которые поди еще найди в неизвестном проце). > но тоже реверсилась система команд, и прошивалка делалась, ага. > SGHFD (SGH Flasher/Dumper, уже из области археологии ныне). Ну и сименсы х3х-х5х тоже археология уже. Ну а знания о том как делают флешовые ФС и свойства флеша и по сей день актуальны :). Кстати у английских википедиков вполне доходчиво описано на уровне устройства чипа флеша откуда берется столь странная механика. >> номерами блоков вместо названий файлов. > У самсунгов внутри оказалось некое подобие FAT, разложенное поверх сносного веарлевелера. А это немного смахивает на ранние версии JFFS, чтоли. По крайней мере трюк с допрограммированием уже программированных байтов без стирания блока за счет читерства с битиками там тоже был. > E700 (TFS 3.12) вообще сломал мозг - там левелер слегка нелинеен. О как. > --- [из сохранившегося] О как, похоже на полноценный wear leveling. А немцы просто сгородили нечто типа флешовой ФС но попримитивнее. Потом они кстати похожий формат данных и для настоящей ФС заюзали. По сути ранний прототип flash file systems по типу JFFS получился. >> Отличная штука для понимания устройства флешовых систем: простенько но со вкусом >> и все основные элементы - на месте. >>> Пример - перезапись 1 байта в файле :) Для CoW это вообще страшнейшая операция. >> Это почему? Оформляется выносок в сторону. >> Вот правда метаданных будет больше чем данных. > ВотЪ. Приятно говорить с понимающим человеком :) Ага :). Просто извращенцев дописывающих все файлы в ФС по 1 байту в природе мало. Только Шишкину не говорите, а то он разопрется как PoC отгрохать том состоящий почти целиком из метаданных и будет орать что это отстой :)
	Ответить | Правка | ^ к родителю #343 | Наверх | Cообщить модератору

	401. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 25-Сен-12, 22:18
	> Ага :). Просто извращенцев дописывающих все файлы в ФС по 1 байту > в природе мало. Только Шишкину не говорите, а то он разопрется > как PoC отгрохать том состоящий почти целиком из метаданных и будет > орать что это отстой :) LAWL :) +100500
	Ответить | Правка | ^ к родителю #397 | Наверх | Cообщить модератору

	348. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 24-Сен-12, 23:44
	> ИМХО эти чудики просто прикрывают свою голопопость и отсутствие надежды на поддержку > trim своим бредом. Смешные они, эти юные бсдшники :) Ой ЧСВ пробило потолок :-))
	Ответить | Правка | ^ к родителю #341 | Наверх | Cообщить модератору

	312. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 24-Сен-12, 11:09
	> И кстати erase - это весьма длительная операция. Как то раз один дурак ляпнул и теперь все заучили как молитву. Это из раздела - переходные процессы длятся бесконечно долго :-))) Без тестов больше эту херню тут не пишите. >[оверквотинг удален] > Вполне себе верна. Чем больше пространства для маневра - тем реже приходится > судорожно дергаться на каждый пшик и тем лучше можно соптимизировать операции. > Собственно грубый прототип того что получается ты и так увидел на > забитом под завязку томе. А тут похожая логика: размазывание записи - > по сути вариант CoW получается. Ну и общие свойства стало быть > похожи. Как ты понимаешь, закладывать большой маневровый запас всем обломно: его > не видно в емкости накопителя которая написана на упаковке, а вот > место в чипах памяти оно жрет. Производителю не нравится напаивать больше > памяти при том что цифра на упаковке не увеличивается. Ведь хомячки > покупают гигабайты :) Еще производитель старается подгадать срок эксплуотации под гарантийный ... > В этом случае как раз контроллер имеет все шансы заранее сгрести мусор. > Тогда стирания не будет, только программирование страниц. И чем больше места > не занято - тем больше пространства для маневра: может получиться воткнуть > желаемую запись куда-то в уже очищенные страницы. А если trim нет > то постепенно все придет к схеме когда "проблема решается по мере > возникновения" - т.е. при вообще каждой записи надо чистить какой-то блок > чтобы оформить запись. Заранее почистить нельзя т.к. неизвестно что используется а > что нет. По поводу чего и скорость записи просядет, и возможности > оптимизации размещения записей у контроллера будут откушены по полной программе. Многие люди суют ssd в рейды встроенные в матери, и большая половина этих рейдов ну разве кроме последних моделей понятия неимеет о триме. Производителям не нужна конкуренция новым дорогим моделям со стороны старых, так что ждать обновлений биоса как погоды у моря. И что многие жалуются на ужасное - ужасное падение производительности ? Кеп покажи как ты умеешь гуглить :-)) > Хинт: если бы все было так как ты говоришь, никто не стал > бы геморроиться с реализацией команды TRIM от которой и так нет > эффекта. По-моему, это даже детсадовцу понятно? :) Трим маркетинговый ход на который есть патент :-)) или не ? > Проблема в том что в ZFS крайне маловероятно что блок ФС совпадет > с блоком SSD. Месье не делал но знает ... > Поэтому - да, ты очень хорошо подсказываешь - > часто будет тереться ДВА блока там где хватило бы одного. Ну > а с блоками переменного размера ты еще и никогда не сможешь > выровнять ФС так чтобы ее блоки совпали с блоками флеша. И все же это реально ... > Так > что многие блоки ФС попадут на пересечение блоков флеша. Вот ить > незадача то. Тут вам и двукратный wear, и более тормозная запись > лишний раз. Так тестов никто и не привел ... > В случае с TRIM это не такая уж проблема, > т.к. erase не будет и будет только программирование страниц по количеству > записываемого. А вот без него логика контроллера свалится в черти-какой штопор. > Грубый прикидон мне подсказывает что экстенты + trim будут работать не > в пример лучше, т.к. в идеальном случае SSD просто запрограммит страницы > и по объему желаемой записи и ... все :). Юзание TRIM > порядочно приближает к этому идеалу. Без него будет максимально паршивый сценарий > вообще каждый раз. Сан юзает ссд диски под кеш zfs и знать незнает что использует их неоптимально ... вот что бывает когда инженеры сана не читают каменты анонимусов на опенете :-))) ... > Ну да, ну да, и угадать размещение блока ФС чтобы не попало > на границы блоков флеша, когда будет на ровном месте тереться 2 > блока вместо 1 просто потому что блок ФС угораздило же лежать > в обоих. А блоки переменного размера окончательно испортят компот, сделав это > начинание невозможным. Не говоря о том что тратить блок 512Кб на > файлик в 1Кб размером будет достаточно обидно. А в других фс не обидно ... > Минимальной единицой записи в флеш является страница. Есть более крупные блоки - > группы страниц, стирание в 0 происходит только большими группами. Ты о > каких из блоков? > Значит, видимо, об erase-блоках. Теоретически, если тебе удастся разложить блоки ФС с > 512-Кб блоками так чтобы они совпали с секторами флеша - ты, > натурально, выиграешь по скорости записи. Практически - флаг тебе в руки > это сделать в ZFS с ее блоками переменного размера и смотри > не удавись от жабы когда файл 1 Кб начнет жрать 512Кб > блок, если это вдруг получится. А ьы хотели бд на zfs и там вообще 10 файлов максимум ... > С одной стороны, прикольно что до изена стало доползать как выравнивать фс > на блоки флеша. С другой - я бы посмотрел как ты > ZFS на блок флеша выровняешь :D. gnop create -S 4096 /dev/gpt/disk0 zpool create -o altroot=/mnt -o cachefile=/var/tmp/zpool.cache zroot /dev/gpt/disk0.nop Это ? > Кроме размера должны еще и границы блоков совпасть. А вот это уже > не самое простое требование. А с блоками переменного размера - ну > ты понял, да? :) Так чтоли zfs set recordsize=128k tank/mysql/iblogs ? > В клиническом случае может и не успеть. Вот только в этом случае > SSD придется менять с регулярностью чартерных рейсов. У современного MLC ресурс > не больно огромный, порядка нескольких тысяч циклов всего. Так что (в > идеальном случае) несколько тысяч записей объемом с накопитель и усе, он > начнет рассыпаться. В реальном даже меньше благодаря упомянутым неоптимальностям. Вот такое Г... просто ненужно покупать. > В режиме когда GC не успевает разгребаться, ресурс будет "ой, опять пора > менять SSD" :). А в менее суровых случаях имхо ФС с > trim выиграют. У ссд есть гарантия. Главое чтоб он сдох до того как она закончится :-)) Как же там все темно http://habrahabr.ru/post/143659/ дословно: Если у вашего SSD контроллер SandForce 2***, то TRIM вам не рекомендуется. Как говорят очевиды всё дело в том, что контроллер SF2*** обрабатывает удалённую пользователем информацию своим особым образом и вообще хранит данные на диске в виде одного большого архива ... Вобщем идем по ссылке в статье ищем свой диск и определяем нужен трим или нет.
	Ответить | Правка | ^ к родителю #297 | Наверх | Cообщить модератору

	318. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Сен-12, 12:17
	>> И кстати erase - это весьма длительная операция. > Как то раз один дурак ляпнул и теперь все заучили как молитву. http://www.datasheetcatalog.org/datasheet/SamsungElectronic/... Страница 19, tBERS. Ситуация типовая для NAND. > Это из раздела - переходные процессы длятся бесконечно долго :-))) > Без тестов больше эту херню тут не пишите. Садись, корень из двух в квадрате. Сначала пойми, как работает флеш, потом приходи. > Многие люди суют ssd в рейды встроенные в матери, и большая половина > этих рейдов ну разве кроме последних моделей понятия неимеет о триме. Хомячки с локалхостами в контексте обсуждения мало интересны. > Трим маркетинговый ход на который есть патент :-)) или не ? TRIM - насущная необходимость для нормального левелинга флеша. Тчк. > Сан юзает ссд диски под кеш zfs и знать незнает что использует Сан уже от'юзался. Унылый такой мертвячок. А SSD под кеши юзаются в основном на аппаратных контроллерах, которые знают про TRIM. > Вот такое Г... просто ненужно покупать. Просто нужно нормально юзать флеш - так, как обусловлено техническими характеристиками, а не так, как левая задняя нога чешется.
	Ответить | Правка | ^ к родителю #312 | Наверх | Cообщить модератору

	423. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Сен-12, 18:59
	> Садись, корень из двух в квадрате. Сначала пойми, как работает флеш, потом приходи. При том даже на (английской) википедии доступно разжевано каког оно именно так. > TRIM - насущная необходимость для нормального левелинга флеша. Тчк. Сейчас будет фокус: как только его запилят в ZFS - они это резко осознают. Люблю все-таки лицемеров - кормят хорошо и лулзов генерят море :) > основном на аппаратных контроллерах, которые знают про TRIM. Еще есть категория граждан пытающихся затыкать технические прорехи маркетинговым буллшитом. Правда настолько явно лажаться - не прокатит, да и вообще, что-то не помог саням их маркетинг.
	Ответить | Правка | ^ к родителю #318 | Наверх | Cообщить модератору

	344. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 23:38
	> Как то раз один дурак ляпнул и теперь все заучили как молитву. Этот "дурак" назывался между прочим даташитами на чипы. От производителей чипов. Вы уж простите, сэр, но я почему-то полагаю что производитель чипов лучше знает свойства своих поделий чем какой-то там nagual. И они, вероятно, менее дураки, поскольку в отличие от вас они эти чипы и производят. По поводу чего должны знать их свойства. И если все производители пишут в датащитах примерно одно и то же, обобщаем и делаем вывод что это свойство "технологии вообще". ИЧСХ, это действительно свойство "технологии вообще". > Это из раздела - переходные процессы длятся бесконечно долго :-))) > Без тестов больше эту херню тут не пишите. Вы это производителям чипов флеш-памяти расскажите. А то пишут, понимаешь, в своих даташитах. А всякие nagual-ы и изены - не верят, понимаешь. Они ж крутые мачо. Умнее производителей чипаков :) >> памяти при том что цифра на упаковке не увеличивается. Ведь хомячки >> покупают гигабайты :) > Еще производитель старается подгадать срок эксплуотации под гарантийный ... В случае с SSD это не получится хотя-бы потому что производитель не властен над объемом записываемых данных. Да и репутация от отказов накопителей сильно страдает. Так что специально никто не пакостит. Просто издержки особенностей технологии помноженные на желание хомяков купить побольше гигазов и подешевле дают свой результат. Все зависит от того насколько с умом подходить к делу. У меня например системный накопитель протерся на ~0.1% за полгода, судя по статистике SMART у накопителя :D. Т.е. в среднем произошел примерно 1 цикл перезаписи всех блоков. Из ~1000 гарантированных производителем чипов. Что-то мне подсказывает что если ничего не изменится, он еще доооооолго будет работать в таком режиме. Но во первых, я юзаю TRIM, во вторых я аккуратно оптимизнул и вынес все что делало не в меру активные записи на механику. В третьих я не забиваю накопитель на 99.9% т.к. сам себе не враг и не очень хочу дорогие SSD спускать пачками в трэш по своей глупости. >> что нет. По поводу чего и скорость записи просядет, и возможности >> оптимизации размещения записей у контроллера будут откушены по полной программе. > Многие люди суют ssd в рейды встроенные в матери, и большая половина > этих рейдов ну разве кроме последних моделей понятия неимеет о триме. А я что, виноват что дуралеев на свете много? Хотя в том же линуксе такой RAID обычно рюхается чисто программно и от контроллера вообще ничего такого не требуется. Собственно, там нет никакого RAID контроллера. Вся поддержка со стороны мамки сводится аж к добавочному ROM для системного BIOS который умеет показывать несколько дисков как якобы один для DOS и начальных загрузчиков, так что они с этого могут начать грузиться. А дальше ОС отбирает бразды правления и видит 2 независимых диска на контроллере. И уже сама из них изображает "RAID". > Производителям не нужна конкуренция новым дорогим моделям со стороны старых, так > что ждать обновлений биоса как погоды у моря. Лулз состоит в том что все современные операционки не используют в своей работе услуги BIOS и поэтому сие до лампочки. Эту работенку ВНЕЗАПНО делает кернель операционки. А вот незнание таких основ архитектуры современных операционок вам чести не делает. Так и запишем. > И что многие жалуются на ужасное - ужасное падение производительности ? > Кеп покажи как ты умеешь гуглить :-)) Я знаю основы архитектуры ОС и без гуглинга. А вот вы жесточайше пропалились. Понты вообще до добра не доводят. Особенно глупые и наивные. >> эффекта. По-моему, это даже детсадовцу понятно? :) > Трим маркетинговый ход на который есть патент :-)) или не ? Прежде всего это фича призванная ускорить работу и замедлить протирание SSD. Потому что возвраты по гарантии никому не уперлись, а хомяк за новым SSD и так придет, когда выкатят в 2 раза более емкий и в 2 раза более быстрый, зря чтоли корпоративщики потребццтво прокачивали? Хомяку неизбежно захочется больше, да :) >> Проблема в том что в ZFS крайне маловероятно что блок ФС совпадет с блоком SSD. > Месье не делал но знает ... Мсье делал и как раз именно поэтому - знает. Да, это был не ZFS, но это не мешает прикинуть на основе имеющихся знаний как оно получится. >> выровнять ФС так чтобы ее блоки совпали с блоками флеша. > И все же это реально ... Тогда ждем рецепт в студию с описанием технологии этого действа :). Я пока такое видел только для примитивных ФС и относительно примитивных флешек и SD карт. Там все проще. И блоки постоянного размера, и контроллеры потупее. >> Так что многие блоки ФС попадут на пересечение блоков флеша. Вот ить >> незадача то. Тут вам и двукратный wear, и более тормозная запись лишний раз. > Так тестов никто и не привел ... А какой смысл бисер метать? На тесты надо довольно много времени, так что если не попадется готовых очень кстати и нахаляву, я не буду такой объем работы воротить задаром для непойми кого. Особенно если он не знает что современные ОС BIOS'ом не пользуются в процессе работы для доступа к контроллеру мамки. А смысл то надрывать попу, меча бисер? >> порядочно приближает к этому идеалу. Без него будет максимально паршивый сценарий >> вообще каждый раз. > Сан юзает ссд диски под кеш zfs и знать незнает что использует их неоптимально ... У сана вообще маркетинговый буллшит вместо технологий был в норме вещей, как я погляжу. Но такой расклад устраивает далеко не всех. Вот вы и кушайте маркетинговый шит, а я хорошие, интересные и полезные технологии предпочитаю. > вот что бывает когда инженеры сана не читают каменты анонимусов на опенете :-))) ... Зато маркетологи с удовольствием втирали некомпетентному лошью маркетинговый буллщит про то как ZFS оптимизирован для SSD. Хотя инженеры саней пальца о палец для этого не ударили. Ну а что, доллары то не пахнут. Правда это не особо помогло и сани продались. Ну а оракл на этот маркетинговый шит уже забил. Благо ZFS для их БД не фонтан а больше им ничего и не надо. Тем более что клиентура все чаще желает линукс. >> файлик в 1Кб размером будет достаточно обидно. > А в других фс не обидно ... Так никто в здравом уме и не юзает блоки ФС фиксированного размера в 512Кб если вы не заметили. Как по мне - достаточно выравнивать на размер страницы. >> не удавись от жабы когда файл 1 Кб начнет жрать 512Кб >> блок, если это вдруг получится. > А ьы хотели бд на zfs и там вообще 10 файлов максимум ... А с ней опа будет по другим поводам. Там логика журналирования БД подерется с природой работы ФС и будет двойная работа. CoW радостно закопирует и изменения в БД, и изменения в журнале. Многократное умножение работы - совершенно на ровном месте. Просто потому что два алгоритма не подружились между собой. >> ZFS на блок флеша выровняешь :D. > gnop create -S 4096 /dev/gpt/disk0 > zpool create -o altroot=/mnt -o cachefile=/var/tmp/zpool.cache zroot /dev/gpt/disk0.nop > Это ? Я не вижу, что в этом списке помешает ZFS шпарить блоками переменного размера. Но может и спровоцировать выравнивание по страницам в лучшем случае, как я понимаю. Насколько эффективно? Хороший вопрос, для этого надо лезть в детали того как ZFS блоки переменного раскладывает. >> не самое простое требование. А с блоками переменного размера - ну ты понял, да? :) > Так чтоли zfs set recordsize=128k tank/mysql/iblogs ? Чисто теоретически, кручение этого параметра может до некоторой степени улучшить работу с SSD. Чисто практически там такой mindf...k, особенно с учетом навороченности устройства ZFS, блоков переменного размера и прочая, что я не взялся что-то гарантировать и даже прикинуть что будет если и смогу то сильно приблизительно. Но в целом - вы как ни странно, верно уловили что ориентированные на выравнивание по блокам RAID или секторам дисков опции частично применимы и для SSD. Правда с оговорками. Проблема в том что истинную геометрию флешатины скрывает контроллер, у которого к тому же есть некая своя логика работы в фирмваре. По этому поводу честно вычислить параметры технически невозможно. Можно подобрать, сделав ряд экспериментов. Для более простых ФС и контроллеров это даже народом освоено слегка. >> начнет рассыпаться. В реальном даже меньше благодаря упомянутым неоптимальностям. > Вот такое Г... просто ненужно покупать. Так другое особо и не производят. Хотя в принципе бывают SLC накопители иногда, но - стоят дофига, а объем мелкий. Что как-то не очень то и перевешивает бОльший срок службы и бОльшую скорость записи в большинстве случаев. Общество потребления, однако. >> trim выиграют. > У ссд есть гарантия. Главое чтоб он сдох до того как она закончится :-)) Мой системный SSD например судя по его SMART рискует сильно пережить и гарантию и вообще. А так - накопитель сдуру можно убить довольно быстро. > Как же там все темно http://habrahabr.ru/post/143659/ дословно: > Если у вашего SSD контроллер SandForce 2***, то TRIM вам не рекомендуется. > Как говорят очевиды всё дело в том, что контроллер SF2*** обрабатывает > удалённую пользователем информацию своим особым образом и вообще хранит данные на > диске в виде одного большого архива ... А sandforce вообще странные штуки. Они жульничают с скоростями чтения-записи и прочая, делая скоростное сжатие данных. По поводу чего на нежмущихся данных скорость заметно меньше чем на жмущихся. Странные люди - маркетинг такой маркетинг. ZFSники с этого мало что выигрывают: если они хотели сжатие - оно в ZFS и так было. Да и в btrfs есть. > Вобщем идем по ссылке в статье ищем свой диск и определяем нужен трим или нет. Спасибо, у меня хватает ума обходить ранние поколения сандфорсов за пушечный выстрел - наслышан об оном.
	Ответить | Правка | ^ к родителю #312 | Наверх | Cообщить модератору

	359. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 25-Сен-12, 00:11
	>> Как то раз один дурак ляпнул и теперь все заучили как молитву. > Этот "дурак" назывался между прочим даташитами на чипы. От производителей чипов. Вы > уж простите, сэр, но я почему-то полагаю что производитель чипов лучше > знает свойства своих поделий чем какой-то там nagual. Как правило инженеры которые делают и инженеры которые пишут это не одни и те же люди и вторые понимают первых очень плохо ... Кто может тот делает а кто неможет вот как вы других учит :-))) > И они, вероятно, > менее дураки, поскольку в отличие от вас они эти чипы и > производят. По поводу чего должны знать их свойства. И если все > производители пишут в датащитах примерно одно и то же Да любят они копипастить друг у друга :-)) как же без этого. >> Это из раздела - переходные процессы длятся бесконечно долго :-))) >> Без тестов больше эту херню тут не пишите. > Вы это производителям чипов флеш-памяти расскажите. А то пишут, понимаешь, в своих > даташитах. А всякие nagual-ы и изены - не верят, понимаешь. Они > ж крутые мачо. Умнее производителей чипаков :) Так и запишем - месье писатель, тесты это слоржно ... > Все зависит от того насколько с умом подходить к делу. У меня > например системный накопитель протерся на ~0.1% за полгода, судя по статистике > SMART у накопителя :D. Т.е. в среднем произошел примерно 1 цикл > перезаписи всех блоков. Из ~1000 гарантированных производителем чипов. Что-то мне подсказывает > что если ничего не изменится, он еще доооооолго будет работать в > таком режиме. Но во первых, я юзаю TRIM, во вторых я > аккуратно оптимизнул и вынес все что делало не в меру активные > записи на механику. В третьих я не забиваю накопитель на 99.9% > т.к. сам себе не враг и не очень хочу дорогие SSD > спускать пачками в трэш по своей глупости. Если бы месье асилил статью на хабре он бы узнал что для половины ссд дисков трм включать не только не полезно но даже вредно :-)) > А я что, виноват что дуралеев на свете много? Хотя в том > же линуксе такой RAID обычно рюхается чисто программно и от контроллера > вообще ничего такого не требуется. Собственно, там нет никакого RAID контроллера. > Вся поддержка со стороны мамки сводится аж к добавочному ROM для > системного BIOS который умеет показывать несколько дисков как якобы один для > DOS и начальных загрузчиков, так что они с этого могут начать > грузиться. А дальше ОС отбирает бразды правления и видит 2 независимых > диска на контроллере. И уже сама из них изображает "RAID". В двух словах люди использующие аппаратные рейды дуралеи ... Вы где нибудь на ссд диске видели надпись no raid ? или что то вроде ? >> Производителям не нужна конкуренция новым дорогим моделям со стороны старых, так >> что ждать обновлений биоса как погоды у моря. > Лулз состоит в том что все современные операционки не используют в своей > работе услуги BIOS и поэтому сие до лампочки. Эту работенку ВНЕЗАПНО > делает кернель операционки. А вот незнание таких основ архитектуры современных операционок > вам чести не делает. Так и запишем. Это делают драйвера ... > Я знаю основы архитектуры ОС и без гуглинга. А вот вы жесточайше > пропалились. Понты вообще до добра не доводят. Особенно глупые и наивные. Кеп неумеет гуглить ? > Мсье делал и как раз именно поэтому - знает. Да, это был > не ZFS, но это не мешает прикинуть на основе имеющихся знаний > как оно получится. На btrfs ext4 неудалось выровнять размер блока как в ссд а потому zfs гавно ... спасибо кеп ноу коментс. > Тогда ждем рецепт в студию с описанием технологии этого действа :). Кстати уже писалось если не асилите найти то медицина бессильна. > А какой смысл бисер метать? На тесты надо довольно много времени, так > что если не попадется готовых очень кстати и нахаляву, я не > буду такой объем работы воротить задаром для непойми кого. Особенно если > он не знает что современные ОС BIOS'ом не пользуются в процессе > работы для доступа к контроллеру мамки. А смысл то надрывать попу, > меча бисер? Короче с тестами опять не судьба ... > А с ней опа будет по другим поводам. Там логика журналирования БД > подерется с природой работы ФС и будет двойная работа. CoW радостно > закопирует и изменения в БД, и изменения в журнале. Многократное умножение > работы - совершенно на ровном месте. Просто потому что два алгоритма > не подружились между собой. Тоесть использовать raw поверх железного рейда без всяких там btrfs рулит ? > Я не вижу, что в этом списке помешает ZFS шпарить блоками переменного > размера. Но может и спровоцировать выравнивание по страницам в лучшем случае, > как я понимаю. Насколько эффективно? Хороший вопрос, для этого надо лезть > в детали того как ZFS блоки переменного раскладывает. И тут тоже с тестами не судьба ... > Чисто теоретически, кручение этого параметра может до некоторой степени улучшить работу > с SSD. Чисто практически там такой mindf...k, особенно с учетом навороченности > устройства ZFS, блоков переменного размера и прочая, что я не взялся > что-то гарантировать и даже прикинуть что будет если и смогу то > сильно приблизительно. Увы месье теоретик, он знает что будет работать плохо но тестами доказать не может... > Спасибо, у меня хватает ума обходить ранние поколения сандфорсов за пушечный выстрел > - наслышан об оном. Как это не печально но последние модели интела тоже на нем - кризис. И трим этим ссд нужен как в бане лыжи.
	Ответить | Правка | ^ к родителю #344 | Наверх | Cообщить модератору

	368. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 25-Сен-12, 07:32
	> Как правило инженеры которые делают и инженеры которые пишут это не одни > и те же люди и вторые понимают первых очень плохо ... И только nagual знает всё лучше вендоров. Вместе с братьями-акробатами на хабре. > Если бы месье асилил статью на хабре он бы узнал что для Я лучше по мануалам, чем по минному полю горе-экспериментаторов, не знающих теории. > половины ссд дисков трм включать не только не полезно но даже вредно :-)) Интересно, чьё больное воображение на хабре родило сей опус? Чистой воды буллшит же. > Тоесть использовать raw поверх железного рейда без всяких там btrfs рулит ? Для СУБД? Да. Либо RAW, либо FS без каких-либо извращений. > Как это не печально но последние модели интела тоже на нем - > кризис. И трим этим ссд нужен как в бане лыжи. Это только в ваших фантазиях, дарагой друх.
	Ответить | Правка | ^ к родителю #359 | Наверх | Cообщить модератору

	398. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 25-Сен-12, 21:33
	>> уж простите, сэр, но я почему-то полагаю что производитель чипов лучше >> знает свойства своих поделий чем какой-то там nagual. > Как правило инженеры которые делают и инженеры которые пишут это не одни > и те же люди и вторые понимают первых очень плохо ... Понимаете, как я написал выше, я когда-то делал специфичный софт и там был специфичный протокол. В силу небольшой халтурки с упрощением протокола, данный самопальный протоколец подклинивало между передачей блоков. В аккурат на время erase и program. По поводу чего я намного лучше вас представляю себе сколько какие процедуры касающиеся флеша занимают. Наверное потому что я же их и реализовывал и наслаждался результатом. Но вы в вашем праве полечить меня еще. Хотя я и разжирею с такого раскорма меня разными ламерами :) > Кто может тот делает а кто неможет вот как вы других учит :-))) Вообще-то я впполне себе реализовывал процедуры записи в флеш. По поводу чего и имею представление о том как это работает. >> производители пишут в датащитах примерно одно и то же > Да любят они копипастить друг у друга :-)) как же без этого. А там нет копипасты. Это как правило более-менее честно меряется и/или приводятся worst cases соответствующие аппаратным таймаутам. Хотя удобно конечно думать что все дураки а вот вы умный. Ну, надизайньте чип и пустите в производство - тогда поверю. >> ж крутые мачо. Умнее производителей чипаков :) > Так и запишем - месье писатель, тесты это слоржно ... Мсье писатель. Мсье лично писал процедуры стирания и программирования флеша. Поучите мсье тому сколько времени они занимают, лол :) >> т.к. сам себе не враг и не очень хочу дорогие SSD >> спускать пачками в трэш по своей глупости. > Если бы месье асилил статью на хабре Это ваша прерогатива - осиливать статьи на хабрашвабре. Специально для таких как вы ресурс. Еще можете всяких Левашовых читать. Хотя лучше сразу уж не мелочиться и взять МК бульвар. Там намного интереснее материалец попадается. > он бы узнал что для половины ссд дисков трм включать не только не полезно но даже > вредно :-)) Для дисков с дефективной реализацией контроллера и/или его фирмвары - да. Вот только это дефект диска. По хорошему с такими багами - сразу в гарантийку и пусть чинят как хотят. Sandforce ранних выпусков вообще прославился лютыми багами типа внезапных умираний и прочих приколов. > В двух словах люди использующие аппаратные рейды дуралеи ... В двух словах, некоторые дуралеи не знают что на мамках в 99.9% случаев райды чисто софтварные. > Вы где нибудь на ссд диске видели надпись no raid ? или что то вроде ? Нет. А должен был? >> вам чести не делает. Так и запишем. > Это делают драйвера ... Я догадывался. Но вы зачем-то вякнули про bios. Тем хуже для вас. >> Я знаю основы архитектуры ОС и без гуглинга. А вот вы жесточайше >> пропалились. Понты вообще до добра не доводят. Особенно глупые и наивные. > Кеп неумеет гуглить ? Насчет "кеп" не знаю а вот вы точно не умеете. Даже детектор нейтрино нагуглить не в состоянии. Хотя там есть все, вплоть до описания конструкции. > На btrfs ext4 неудалось выровнять размер блока как в ссд а потому > zfs гaвно ... спасибо кеп ноу коментс. Улыбают меня эти бсдшники :). "Ну и что что с голой попой, все-равно BSD рулез!!!111" :) >> Тогда ждем рецепт в студию с описанием технологии этого действа :). > Кстати уже писалось если не асилите найти то медицина бессильна. Процитируйте? >> работы для доступа к контроллеру мамки. А смысл то надрывать попу, меча бисер? > Короче с тестами опять не судьба ... Для нормального проведения таких тестов надо уйму времени. Пусть ее фороникс забабахает. Ну или вы. Правда вам я доверяю меньше чем форониксу, увы. >> работы - совершенно на ровном месте. Просто потому что два алгоритма >> не подружились между собой. > Тоесть использовать raw поверх железного рейда без всяких там btrfs рулит ? А в btrfs можно, внезапно, отключить CoW логику для конкретных файлов, если она совсем уж мешается. Правда забавно, да? :) > И тут тоже с тестами не судьба ... Затвердила сорока Якова одно про всякого :) > Увы месье теоретик, он знает что будет работать плохо но тестами доказать не может... Мсье такой теоретик что аж сам писал процедуры стирания и записи флеша. Ы? >> Спасибо, у меня хватает ума обходить ранние поколения сандфорсов за пушечный выстрел >> - наслышан об оном. > Как это не печально но последние модели интела тоже на нем - кризис. А это уже новые модели где старые ляпы частично исправлены. > И трим этим ссд нужен как в бане лыжи. Сандфорсы вообще какие-то странные контроллеры. Но кроме них есть навалом других. Себе я бы ничего на сандфорсе покупать не стал.
	Ответить | Правка | ^ к родителю #359 | Наверх | Cообщить модератору

	402. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 25-Сен-12, 23:06
	> Мсье писатель. Мсье лично писал процедуры стирания и программирования флеша. Поучите мсье > тому сколько времени они занимают, лол :) Месье что то очень часто вспоминает бурную молодость. Иногда к месту, иногда неочень. Это моразм ? > В двух словах, некоторые дуралеи не знают что на мамках в 99.9% > случаев райды чисто софтварные. Спасибо кеп. Осень да ? > Насчет "кеп" не знаю а вот вы точно не умеете. Даже детектор > нейтрино нагуглить не в состоянии. Хотя там есть все, вплоть до > описания конструкции. https://www.google.com.ua/search?client=opera&rls=ru&q=%... > Улыбают меня эти бсдшники :). "Ну и что что с голой попой, > все-равно BSD рулез!!!111" :) В лексекон настоящего линуксоида обязательно должны входить слова жопа и бсд :-)))) > Процитируйте? zdb -U /var/tmp/zpool.cache |grep ashift ashift делается через gnop а  recordsize через zfs set recordsize=4k zroot не ? > Для нормального проведения таких тестов надо уйму времени. Пусть ее фороникс забабахает. > Ну или вы. Правда вам я доверяю меньше чем форониксу, увы. Вы пишите пишите то что думаете о методике тестирования чтоб потом небыло претензий к тестам :-)) > А в btrfs можно, внезапно, отключить CoW логику для конкретных файлов, если > она совсем уж мешается. Правда забавно, да? :) Я заметил в линуксе многие вещи происходят внезапно , внезапно улетает ext4 так же внезамно в kvm виснут виртуалки :-)) > Затвердила сорока Якова одно про всякого :) А по существу ? > Мсье такой теоретик что аж сам писал процедуры стирания и записи флеша. > Ы? Это к чему ?
	Ответить | Правка | ^ к родителю #398 | Наверх | Cообщить модератору

	424. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Сен-12, 19:25
	> Месье что то очень часто вспоминает бурную молодость. Иногда к месту, иногда неочень. Думаю что в данном случае мсье припомнил это кстати. Устройство флеша в целом мало изменилось за эти годы. Техпроцессы стали тоньше, контроллеры лучше. Но общие принципы работы никуда не делись и физика процесса вся та же. Поэтому знания мсье вполне актуальны. Вон соседний мсье не поленился даже адресно макнуть в даташит, где время стирания указано. > Это моразм ? Когда слово "маразм" не получается написать без ошибок - это он самый! Я гарантирую это. > https://www.google.com.ua/search?client=opera&rls=ru&q=%... > %D1%80%D0%BE%D0%B7&sourceid=opera&ie=utf-8&oe=utf-8&channel=suggest Это бесплатный бонус к "моразму" для большей убедительности? Ну ладно, засчитано, тема "моразма" раскрыта :) > В лексекон Кроме "моразма" ничуть не менее былинно и когда слово "лексикон" не могут написать правильно. Парад деда моразма, не иначе :) > ashift делается через gnop а  recordsize через zfs set recordsize=4k zroot Я так понимаю что сие нацелено на выравнивание по страницам. Что разумно и правильно. Но изен помнился хотел выравнивание на erase block. Мне не совсем понятно как это обеспечивается при блоках переменного размера или где в этой писанине отключение данной фичи. > не ? Т.е. вы сами не уверены что оно делает. Зашибись, я должен лучше вас знать вашу ФС чтоли? > Вы пишите пишите то что думаете о методике тестирования чтоб потом небыло > претензий к тестам :-)) Я думаю что 5 дисков на 1Гб - это "моразм". Вот реалистичненький HDD и SSD и на них ФС развернуть и помучать - это уже нечто годное. Но это много возни. Получить представление о том какие более-менее реалистичные тесты есть можно у того же фороникса. Правда они бенчат не все нагрузки, но это лучше чем ничего. И да, надеюсь у вас был хотя-бы курс лабораторных работ в вузе чтобы вы понимали что такое погрешность измерений, например? Если уж вы бенчить что-то намерены. Фороникс и то в курсе и отмечают оную на графиках. >> она совсем уж мешается. Правда забавно, да? :) > Я заметил в линуксе многие вещи происходят внезапно , внезапно улетает ext4 Не знаю, у меня ничего не улетело за столько лет. Юзаю с 2.6.32 ядра. Все на месте. Хотя где-то в районе .35 редкий но меткий баг починили но его еще суметь надо огрести т.к. лезет только на очень больших файлах. > так же внезамно в kvm виснут виртуалки :-)) Странно, а у меня они просто работают. Тем паче что бзды вообще не умеют хостом для виртуалок быть и потому вообще выпадают из рассмотрения. >> Затвердила сорока Якова одно про всякого :) > А по существу ? По существу, проведение бенчей в нормальном виде - достаточно долго и требует оборудования и квалификации. Даже тот же фороникс переплюнуть по качеству бенчей - не настолько простая задача как это кажется. У них в общем то обычно есть нормальное описание конфига и какое-никакое описание методики, они в состоянии опробовать разные нагрузки и более-менее осмысленно разгрести результаты. >> Мсье такой теоретик что аж сам писал процедуры стирания и записи флеша.Ы? > Это к чему ? К наездам на то что мсье теоретик. А вот и фиг, мсье практик. Просто даже небольшая практика требует большой теории.
	Ответить | Правка | ^ к родителю #402 | Наверх | Cообщить модератору

	429. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 26-Сен-12, 21:05
	> Т.е. вы сами не уверены что оно делает. Зашибись, я должен лучше > вас знать вашу ФС чтоли? Ну чтовы :-) вы просто неправильно поняли написанное :-)) > Я думаю что 5 дисков на 1Гб - это "моразм". Вот реалистичненький > HDD и SSD и на них ФС развернуть и помучать - > это уже нечто годное. Несмотря на на все намёки в разнице быстродействия мехпнизмов реальных дисков и собственно работой логики фс месье настаивает ... это уже маразм. > И да, надеюсь у вас был хотя-бы курс лабораторных работ в вузе > чтобы вы понимали что такое погрешность измерений, например? Если уж вы > бенчить что-то намерены. Фороникс и то в курсе и отмечают оную > на графиках. Ой мессье не смог вспомнить название теории Стьюдента. > Странно, а у меня они просто работают. Тем паче что бзды вообще > не умеют хостом для виртуалок быть и потому вообще выпадают из > рассмотрения. tcpdump на виртуалке запустите :-)) > По существу, проведение бенчей в нормальном виде - достаточно долго и требует > оборудования и квалификации. Даже тот же фороникс переплюнуть по качеству бенчей > - не настолько простая задача как это кажется. У них в > общем то обычно есть нормальное описание конфига и какое-никакое описание методики, > они в состоянии опробовать разные нагрузки и более-менее осмысленно разгрести результаты. Их бенчи не воспроизводятся :-)) их невозможно переплюнуть :-)) > К наездам на то что мсье теоретик. А вот и фиг, мсье > практик. Ода мы уже заметили :-))
	Ответить | Правка | ^ к родителю #424 | Наверх | Cообщить модератору

	432. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 26-Сен-12, 21:46
	> Несмотря на на все намёки в разнице быстродействия мехпнизмов реальных дисков и > собственно работой логики фс месье настаивает ... это уже маразм. Просто инженеров интересует реальный перформанс, а не сферические кони в вакууме. Я понимаю, что это далеко от идеологии BSD'шника, но всё же.
	Ответить | Правка | ^ к родителю #429 | Наверх | Cообщить модератору

	433. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 26-Сен-12, 23:14
	> Просто инженеров интересует реальный перформанс, а не сферические кони в вакууме. Я > понимаю, что это далеко от идеологии BSD'шника, но всё же. Это вы про тех самых инженеров которые немогут bc и count на пальцах показать ?
	Ответить | Правка | ^ к родителю #432 | Наверх | Cообщить модератору

	436. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 27-Сен-12, 17:30
	> Это вы про тех самых инженеров которые немогут bc и count на > пальцах показать ? bc - это вообще программа-калькулятор такая. А вы наверное про bs.
	Ответить | Правка | ^ к родителю #433 | Наверх | Cообщить модератору

	451. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 30-Сен-12, 20:56
	> Ну чтовы :-) вы просто неправильно поняли написанное :-)) Наверное дело в том кто объясняет. Вот были бы вы супермозгом, типа резерфорда, вы бы и ядерную физику кухарке разжевали в 2 счета. А поскольку вы сами не понимаете что лопочете - отсюда и результат. Сложно объяснить окружающим свою мысль если сам не понимаешь или неправильно понимаешь что хотел сказать. > Несмотря на на все намёки в разнице быстродействия мехпнизмов реальных дисков и > собственно работой логики фс месье настаивает ... это уже маразм. Мсье настаивает на том что ZFS вообще не демонстрирует ничего сногсшибательного в бенчах. А в ряде бенчей испытывает откровенные проблемы. >> бенчить что-то намерены. Фороникс и то в курсе и отмечают оную на графиках. > Ой мессье не смог вспомнить название теории Стьюдента. О, мсье даже помнит такие названия? Ну тогда может быть еще не все потеряно. Но учтите, мы тут бдим (не путать с "бздим"). >> не умеют хостом для виртуалок быть и потому вообще выпадают из рассмотрения. > tcpdump на виртуалке запустите :-)) Запустил. И чего? Вроде ничего необычного. Tcpdump, показывает трафф на интерфейсе. Вроде относительно честно. > Их бенчи не воспроизводятся :-)) их невозможно переплюнуть :-)) А что, пробовали воспроизводить? Неужто вы нашли железо как у них? Это при том что вы 1 диск для тестов выкроить не можете? Как-то неубедительно. >> К наездам на то что мсье теоретик. А вот и фиг, мсье практик. > Ода мы уже заметили :-)) Кому ода? Ламерам? :)
	Ответить | Правка | ^ к родителю #429 | Наверх | Cообщить модератору

	245. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 20:44
	> Поэтому > вынужден очищать блоки только когда туда пытаются писать по факту. А > не заранее. И вот это является очень неоптимальным режимом работы. Учитывая что все последующие инсинуации основаны всего на одном предположении извольте предоставить доставерные тесты.
	Ответить | Правка | ^ к родителю #208 | Наверх | Cообщить модератору

	298. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 06:26
	> доставерные ДостАверные тесты - это круто, да :)
	Ответить | Правка | ^ к родителю #245 | Наверх | Cообщить модератору

	192. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от nagual (ok) on 23-Сен-12, 17:01
	> Да, кроме всего прочего, TRIM - нормальный способ выполнить очистку блока заранее, > до того, как он понадобится системе. Стирание - не ахти какая > быстрая операция, и именно поэтому производительность ZFS будет на флешке сильно > ниже традиционок - эти FS не очищают блоки, и каждая перезапись > на них будет инициировать стирание. Единственный способ этого избежать - TRIM'ать > "устаревшие" ненужные более блоки после гарантированного завершения транзакций. Делает > ли это BTRFS - не знаю. Похоже мы обсуждаем особенности какого то отдельно взятого дешового контроллера ... Что то не припомню чоб на 100% заполненом SSD диске тест записи вдруг внезапно тормозил.
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

	204. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 18:41
	> Похоже мы обсуждаем особенности какого то отдельно взятого дешового контроллера ... > Что то не припомню чоб на 100% заполненом SSD диске тест записи > вдруг внезапно тормозил. http://www.anandtech.com/show/2829/9 http://www.bit-tech.net/hardware/storage/2010/02/04/windows-... Так, в качестве ликбеза.
	Ответить | Правка | ^ к родителю #192 | Наверх | Cообщить модератору

	234. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 20:33
	>> Похоже мы обсуждаем особенности какого то отдельно взятого дешового контроллера ... >> Что то не припомню чоб на 100% заполненом SSD диске тест записи >> вдруг внезапно тормозил. > http://www.anandtech.com/show/2829/9 > http://www.bit-tech.net/hardware/storage/2010/02/04/windows-... > Так, в качестве ликбеза. Очень порадовали результаты тестов по первой ссылке: одни производители SSD дали бабла писателям PCMark Vantage и там 0% а другие не дали и там аж 23% Есть какие нибудь доставерные тесты где скорость меряется dd ?
	Ответить | Правка | ^ к родителю #204 | Наверх | Cообщить модератору

	237. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 20:36
	> Есть какие нибудь доставерные тесты где скорость меряется dd ? Есть. Самый достоверный тест - это произведенный собственными руками. Поэтому - прошу. К слову, результаты с теорией при правильном тестировании не разойдутся.
	Ответить | Правка | ^ к родителю #234 | Наверх | Cообщить модератору

	299. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 06:29
	> Похоже мы обсуждаем особенности какого то отдельно взятого дешового контроллера ... Да любого - как будто, эта логика у всех сильно отличается. Детали реализации могут отличаться, а вот общий смысл - фиг. > Что то не припомню чоб на 100% заполненом SSD диске тест записи вдруг внезапно тормозил. Возможно выехал на резервных маневровых страницах. Но это прокатит только при сравнительно небольших записях и не всегда. Ну и просто статистику по wearing'у надо смотреть. У хороших накопителей она на редкость дотошная.
	Ответить | Правка | ^ к родителю #192 | Наверх | Cообщить модератору

	313. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 24-Сен-12, 11:10
	>> Похоже мы обсуждаем особенности какого то отдельно взятого дешового контроллера ... > Да любого - как будто, эта логика у всех сильно отличается. Детали > реализации могут отличаться, а вот общий смысл - фиг. Да не любого http://habrahabr.ru/post/143659/ читать до просветвленья :-))
	Ответить | Правка | ^ к родителю #299 | Наверх | Cообщить модератору

	319. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Сен-12, 12:18
	> Да не любого http://habrahabr.ru/post/143659/ читать до просветвленья :-)) После скриншотика с гламурного макбука блеванул, и читать перестал.
	Ответить | Правка | ^ к родителю #313 | Наверх | Cообщить модератору

	201. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 17:58
	> Снова садись, снова два. Без TRIM они не то, что не друзья, > а вообще не совместимы генетически. А TRIM то там и нету. А в btrfs - опять же, есть. Ха.
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	323. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 24-Сен-12, 19:45
	>>>> В этом плане ZFS с ее COW и SSD друзья > Снова садись, снова два. Без TRIM они не то, что не друзья, > а вообще не совместимы генетически. Смотри-ка, что pjd вчера закоммитил в head: http://svnweb.freebsd.org/base?view=revision&revision=240868 //--- Author: pjd Date: Sun Sep 23 19:40:58 2012 UTC (19 hours, 57 minutes ago) Changed paths: 19 Log Message: Add TRIM support. The code builds a map of regions that were freed. On every write the code consults the map and eventually removes ranges that were freed before, but are now overwritten. Freed blocks are not TRIMed immediately. There is a tunable that defines how many txg we should wait with TRIMming freed blocks (64 by default). There is a low priority thread that TRIMs ranges when the time comes. During TRIM we keep in-flight ranges on a list to detect colliding writes - we have to delay writes that collide with in-flight TRIMs in case something will be reordered and write will reached the disk before the TRIM. We don't have to do the same for in-flight writes, as colliding writes just remove ranges to TRIM. Sponsored by:    multiplay.co.uk This work includes some important fixes and some improvements obtained from the zfsonlinux project, including TRIMming entire vdevs on pool create/add/attach and on pool import for spare and cache vdevs. Obtained from:    zfsonlinux Submitted by:    Etienne Dechamps <etienne.dechamps@ovh.net> ---// Тут мнение: http://forum.ixbt.com/topic.cgi?id=11:44215-55#1599
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	403. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Сен-12, 13:39
	А мнение iZEN и nagual о фиче теперь поменяется на противоположное? :)
	Ответить | Правка | ^ к родителю #323 | Наверх | Cообщить модератору

	404. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 26-Сен-12, 13:40
	> А мнение iZEN и nagual о фиче теперь поменяется на противоположное? :) Неизбежно.
	Ответить | Правка | ^ к родителю #403 | Наверх | Cообщить модератору

	425. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Сен-12, 19:26
	> Неизбежно. Смешно будет смотреться когда им придется обсирать свою же предыдущую точку зрения :)
	Ответить | Правка | ^ к родителю #404 | Наверх | Cообщить модератору

	491. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 02-Окт-12, 07:36
	> btrfs и SSD не совместимы ... В этом плане ZFS с > ее COW и SSD друзья а так как ZFS позицианируется под Без TRIM? Да, друзья. Примерно как волк зайцу. > Если вы не подскажете как его отключить нафиг через sysctl то будет считать что btrfs и SSD не совместимы -o ssd при монтировании
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	522. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 04-Окт-12, 10:12
	> А ничего что у всяких соляр и бздей на выбор полторы ФС, > при том одна переросточная и тормозная ынтырпрайзятина ZFS а вторая - > ископаемое с архитектурой каменноугольного периода UFS. Интересно для кого вы пишите этот бред ? Вот теореме Пифагора более 2000 лет и никто ничего нового не придумал ? Ай яй яй !!? Может быть потому что свойства трехмерного пространства с того времени не менялись ? UFS более десяти лет может быть по тому что устройства хранения данных с того времени сильно не менялись? Ну добавили soft update журнал снапшеты но в целом все по старому ... Зато в линуксе бурный рост :)) на фоне бурных глюков :)) Куча фс которые по сути одно и тоже если не считать btrfs с ее cow но linux с btrfs как то сильно отстал от freebsd с zfs ... это случайно :)) копипастеры зазевались? Очень радует разница между jsf и xfs :)) Нахрена две почти одинаковые fs ? Кто то хотел бабла срубить ? ЗЫ linux это та же избушка что и windows только повернута к лесу передом ...
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	528. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 05-Окт-12, 11:37
	> Ну добавили soft update журнал снапшеты но в целом все по > старому... Ну да - всё те же тормоза. > Зато в линуксе бурный рост :)) на фоне бурных > глюков :)) Не ошибается тот, кто ничего не делает.
	Ответить | Правка | ^ к родителю #522 | Наверх | Cообщить модератору

	65. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–2 +/–
	Сообщение от nagual (ok) on 20-Сен-12, 10:25
	>[оверквотинг удален] > финансирование, но пилят его довольно интенсивно и в майнлайне. А не > где-то сбоку под левой лицензией. За чем будущее - несложно догадаться. > Проект ФС вне майнлайна обречен быть маргинальной хренотенью нужной немногим, с > невнятными перспективами всего этого начинания. > ...просто потому что BTRFS сможет то что и ZFS. И даже больше. > И лучше. Чем будут после этого зарабатывать указанные коммерческие конторы - > вопрос интересный. И что случится с этой кодовой базой - тоже > интересно, да. Поскольку если 2 коммерческие конторы окажутся без дохода от > этого начинания и выбросят его на свалку - тогда чего? Как > с опенсолярой и ораклем, да? :) Для того чтоб хорошие проекты могли хорошо работать, плохие должны работать плохо. Используйте btrfs читайте слоника в домене ... Удачи :-))
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	77. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 20-Сен-12, 13:49
	спасибо. так и делаю. :D
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	109. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Сен-12, 06:02
	> Для того чтоб хорошие проекты могли хорошо работать, плохие должны работать плохо. > Используйте btrfs читайте слоника в домене ... Удачи :-)) А знаете, пока бсдшники злобно шипят, слоник как менеджер в общем то вполне нормально рулит. В том плане что собственно конторе от его деятельности скорее польза нежели вред. А то что поклонники сферичкских коней в вакууме недовольны - так это дело десятое и в оценку эффективности менеджера вообще не входит.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	117. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 21-Сен-12, 08:19
	>> Для того чтоб хорошие проекты могли хорошо работать, плохие должны работать плохо. >> Используйте btrfs читайте слоника в домене ... Удачи :-)) > А знаете, пока бсдшники злобно шипят, слоник как менеджер в общем то > вполне нормально рулит. В том плане что собственно конторе от его > деятельности скорее польза нежели вред. А то что поклонники сферичкских коней > в вакууме недовольны - так это дело десятое и в оценку > эффективности менеджера вообще не входит. Вы просто не в курсе событий :)) сначала он раскрутил спонов на никому ненужный переход на линь когда деплой фри уже стоял работал а деплой линя нужно было писать с нуля, а потом он сменил место работы :)) так что ждем новых статей про похождения слоника :-))
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	118. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Сен-12, 11:58
	> сменил место работы :)) У, тогда почте рамблера имхо капец. Если б не вджоб этого руководилы, оно бы так и осталось унылой древней хренью с которой все сбежали.
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	88. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 20-Сен-12, 17:07
	> ...просто потому что BTRFS сможет то что и ZFS. И даже больше. Вот когда сможет хотя бы RAID-5, тогда приходите. > И лучше. Вот когда будет годный btrfsck, тогда и приходите.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	89. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 20-Сен-12, 18:35
	>Вот когда сможет хотя бы RAID-5, тогда приходите. для моего ноута не критично. использую бтр и не жалуюсь. >Вот когда будет годный btrfsck, тогда и приходите. во-первых - уже. во-вторых - а в ZFS? :D зыж а ты придумал уже, что будешь писать, когда реализуют 5-й рэйд то? а то уже скоро обещают, а ты и не готов?
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	90. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 20-Сен-12, 19:36
	>>Вот когда сможет хотя бы RAID-5, тогда приходите. > для моего ноута не критично. А для моего десктопа критично. ;p > использую бтр и не жалуюсь. >>Вот когда будет годный btrfsck, тогда и приходите. > во-первых - уже. Вы хотите сказать: "Не так давно, хоть что-то появилось, что может что-то чинить"? http://www.linux.org.ru/forum/talks/8203698/page4?lastmod=13... > во-вторых - а в ZFS? :D zpool scrub <poolname>. Было с самого начала. > зыж > а ты придумал уже, что будешь писать, когда реализуют 5-й рэйд то? "На Btrfs можно делать несколько копий данных?" > а то уже скоро обещают, а ты и не готов? Я всегда готов. Только ты об этом узнаешь ВНЕЗАПНО.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	91. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 20-Сен-12, 20:43
	>А для моего десктопа критично. ;p наслышен, наслышен :D >http://www.linux.org.ru/forum/talks/8203698/page4?lastmod=13... Ха! http://www.lissyara.su/articles/freebsd/file_system/zfs_reco.../ :D или http://hardforum.com/archive/index.php/t-1656030.html а чудику btrfs [filesystem] balance start [options] <path> надо было сделать. раз уж сам ставил, то сам бы и разруливал. >Вы хотите сказать: "Не так давно, хоть что-то появилось, что может что-то чинить"? >> во-вторых - а в ZFS? :D >zpool scrub <poolname>. Было с самого начала. btrfs scrub start [-Bdqr] <path>|<device> было с самого начала. но (для посикс/лсб) сделали ещё и фсчк. а у вас там фсчк есть? а сбойные блоки не провирть? :D >"На Btrfs можно делать несколько копий данных?" ага :D >Я всегда готов. Только ты об этом узнаешь ВНЕЗАПНО. это тебе так кажется. :D
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	92. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 20-Сен-12, 22:32
	> Ха! http://www.lissyara.su/articles/freebsd/file_system/zfs_reco.../ :D Это уже баян, который давно порвали на кусочки. В ZFSv28 (с 6 июня 2011 года во FreeBSD) есть волшебная команда "zpool import -F <poolname>" в случае FAULTED-пула. http://www.mail-archive.com/freebsd-stable@freebsd.org/... > или http://hardforum.com/archive/index.php/t-1656030.html "12-02-2011, 12:13 AM" Давайте жить сегодняшними реалиями. > а чудику btrfs [filesystem] balance start [options] <path> надо было сделать. Так объяснил бы этому чудику. >>zpool scrub <poolname>. Было с самого начала. > btrfs scrub start [-Bdqr] <path>|<device> > было с самого начала. > но (для посикс/лсб) сделали ещё и фсчк. > а у вас там фсчк есть? а сбойные блоки не провирть? :D А зачем проверять сбойные блоки, если список повреждённых файлов и путей до них перед глазами. Зачем нам нужны сбойные блоки с мусором? >>"На Btrfs можно делать несколько копий данных?" > ага :D Каким образом? Через снапшоты? :))
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	93. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 21-Сен-12, 00:20
	>Это уже баян, угу. >"12-02-2011, 12:13 AM" >Давайте жить сегодняшними реалиями. Так кто ж спорил бы! :D >2012-05-07 >    Migration from http://btrfs.ipv5.de >Latest btrfs-progs (c. 26 Mar 2012) >    btrfsck can now repair some forms of filesystem breakage >Enterprise btrfs support (Feb 2012) >    Since February 2012 there are two vendors who support btrfs in their distributions, Oracle and SUSE. и боянист из тебя плохой - 0.19 даже уже в википедии нет.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	111. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от Аноним (??) on 21-Сен-12, 06:04
	> и боянист из тебя плохой - 0.19 даже уже в википедии нет. Да ты слушай больше этого Ыксперта, у тебя тоже диски будут работать как у него  :) [выжимая аж целых 6мб/сек на шпиндель, ололо]
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	134. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 22-Сен-12, 21:47
	>> и боянист из тебя плохой - 0.19 даже уже в википедии нет. > Да ты слушай больше этого Ыксперта, у тебя тоже диски будут работать > как у него  :) [выжимая аж целых 6мб/сек на шпиндель, > ололо] http://www.linux.org.ru/forum/talks/8255499?cid=8255518
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	144. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 09:52
	> http://www.linux.org.ru/forum/talks/8255499?cid=8255518 data=journal, drive cache=off, fsync а чтобы не извращаться - надо ставить ИБП
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	153. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 11:10
	>> http://www.linux.org.ru/forum/talks/8255499?cid=8255518 > data=journal, drive cache=off, fsync > а чтобы не извращаться - надо ставить ИБП Ну вот оказываеся ext4 без журнала гробит данные. И что же это она во всех тестах, где всех рвет - без журнала ? :-))  А с журналом что сливает ?
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	158. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 11:17
	> Ну вот оказываеся ext4 без журнала гробит данные. И что же это > она во всех тестах, где всех рвет - без журнала ? > :-))  А с журналом что сливает ? Да нет, просто журналирование ДАННЫХ (не метаданных) - удел нищебродов, неспособных позволить себе UPS на критичное приложение. А если нет критичного приложения - то и вообще не актуально.
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	160. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 11:21
	>> Ну вот оказываеся ext4 без журнала гробит данные. И что же это >> она во всех тестах, где всех рвет - без журнала ? >> :-))  А с журналом что сливает ? > Да нет, просто журналирование ДАННЫХ (не метаданных) - удел нищебродов, неспособных позволить > себе UPS на критичное приложение. А если нет критичного приложения - > то и вообще не актуально. Сие следует понимать так - нетаскать упс за ноутом удел нищебродов :-))) Ага и чемодан с батарейками в свободную руку :-))) Короче говоря для ноутов с их тормознутами но зато противоударными дисками дисками линукс с ext4 не годится, будет еще тормознутей :-)))
	Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

	164. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 11:27
	> Сие следует понимать так - нетаскать упс за ноутом удел нищебродов :-))) Сие следует понимать так: Работать с критичными данными на ноуте с разряженной батареей - моветон.
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	165. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 11:28
	>> Сие следует понимать так - нетаскать упс за ноутом удел нищебродов :-))) > Сие следует понимать так: > Работать с критичными данными на ноуте с разряженной батареей - моветон. Ну и да - если уж нельзя "оторваться от производства" по пути - только нищеброды не могут себе позволить сменную батарею.
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

	168. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 11:38
	>>> Сие следует понимать так - нетаскать упс за ноутом удел нищебродов :-))) >> Сие следует понимать так: >> Работать с критичными данными на ноуте с разряженной батареей - моветон. > Ну и да - если уж нельзя "оторваться от производства" по пути > - только нищеброды не могут себе позволить сменную батарею. А как вы смените батарею не выключая бук и не закрывая все приложения ? :-)) Гибернейшен разве у всех работает ? :-))
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	175. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 12:14
	> А как вы смените батарею не выключая бук и не закрывая все > приложения ? :-)) Гибернейшен разве у всех работает ? :-)) У кого в критичной среде оное не работает - милости прошу об стену или в окно.
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

	194. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 17:03
	> У кого в критичной среде оное не работает - милости прошу об > стену или в окно. И как помогает ? :-)))
	Ответить | Правка | ^ к родителю #175 | Наверх | Cообщить модератору

	206. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 18:43
	>> У кого в критичной среде оное не работает - милости прошу об >> стену или в окно. > И как помогает ? :-))) Не знаю. Первый раз человека с подобной проблемой увидел по приведенной выше ссылке. Очевидно, редкий вид. На собственной практике не случалось ни разу.
	Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

	405. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Сен-12, 13:40
	> И как помогает ? :-))) Проверьте. Вы же любите требовать тесты. Теперь наша очередь :)
	Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

	177. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 12:18
	>> Сие следует понимать так - нетаскать упс за ноутом удел нищебродов :-))) > Сие следует понимать так: > Работать с критичными данными на ноуте с разряженной батареей - моветон. Человек вообще не открывал те файлы, что у него обнулились, но случайно оказались в одном каталоге с запущенной программой.
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

	196. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 17:05
	>>> Сие следует понимать так - нетаскать упс за ноутом удел нищебродов :-))) >> Сие следует понимать так: >> Работать с критичными данными на ноуте с разряженной батареей - моветон. > Человек вообще не открывал те файлы, что у него обнулились, но случайно > оказались в одном каталоге с запущенной программой. Когда при запуске fsck в фоне обнуляются открытые файлы это херово но не ново, но вот когда соседние это просто ППЦ.
	Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

	207. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 18:43
	> Когда при запуске fsck в фоне обнуляются открытые файлы это херово но > не ново, но вот когда соседние это просто ППЦ. Я бы сказал, если руки из задницы - может и весь диск обнулиться. Потому, что если подумать - этого не может быть потому, что не может быть. Скорее всего (с вероятностью 99%) - камиказе с отключенным журналом метаданных.
	Ответить | Правка | ^ к родителю #196 | Наверх | Cообщить модератору

	241. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 20:40
	>> Когда при запуске fsck в фоне обнуляются открытые файлы это херово но >> не ново, но вот когда соседние это просто ППЦ. > Я бы сказал, если руки из задницы - может и весь диск > обнулиться. > Потому, что если подумать - этого не может быть потому, что не > может быть. > Скорее всего (с вероятностью 99%) - камиказе с отключенным журналом метаданных. А случай с улетевшим разделом ? Этого не может быть потому что быть не может ? Месье накурился ?
	Ответить | Правка | ^ к родителю #207 | Наверх | Cообщить модератору

	244. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 20:43
	> А случай с улетевшим разделом ? Этого не может быть потому что > быть не может ? Месье накурился ? За два года юза ext4 в продакшне не было ни одного случая отказа FS. Был случай выпадения двух дисков в пятом рейде, но тут уже любая FS ляжет. Порядка 25 серверов. На некритичных (и включенных по этой причине без UPS) происходили в т.ч. отключения питания. Никаких развалов, обнулений файлов, и прочего. Но тут потому, что софт обучен не делать ftruncate/rewrite. Только write/unlink/mv.
	Ответить | Правка | ^ к родителю #241 | Наверх | Cообщить модератору

	468. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 15:32
	> Скорее всего (с вероятностью 99%) - камиказе с отключенным журналом метаданных. Он написал про какой-то фон. Уж не пнул ли этот баклан fsck на смонтированном разделе? Ну там где fsck еще истошно орет варнингами про то что в таком режиме он может раздестроить все и вся и никаких гарантий дескать нет. Если он сделал это - ну он и получил что заслужил. Потому что сложно быть глупым, да.
	Ответить | Правка | ^ к родителю #207 | Наверх | Cообщить модератору

	479. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 02-Окт-12, 00:29
	>> Скорее всего (с вероятностью 99%) - камиказе с отключенным журналом метаданных. > Он написал про какой-то фон. Уж не пнул ли этот баклан fsck > на смонтированном разделе? Ну там где fsck еще истошно орет варнингами > про то что в таком режиме он может раздестроить все и > вся и никаких гарантий дескать нет. Если он сделал это - > ну он и получил что заслужил. Потому что сложно быть глупым, > да. Очередной высер из серии - не читал но осуждаю ... fsck запускался из хост системы без монтирования. Сложно сапортить когда системы ставят глупые люди.
	Ответить | Правка | ^ к родителю #468 | Наверх | Cообщить модератору

	516. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 02-Окт-12, 21:40
	> fsck запускался из хост системы без монтирования. А, вот оно что. А при чем тут фон? > Сложно сапортить когда системы ставят глупые люди. Самокритичненько.
	Ответить | Правка | ^ к родителю #479 | Наверх | Cообщить модератору

	406. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 26-Сен-12, 13:41
	> Человек вообще не открывал те файлы, что у него обнулились, но случайно > оказались в одном каталоге с запущенной программой. Не верю (с) либо руки
	Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

	408. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 26-Сен-12, 13:49
	>> Человек вообще не открывал те файлы, что у него обнулились, но случайно >> оказались в одном каталоге с запущенной программой. > Не верю (с) > либо руки Либо фс :-))
	Ответить | Правка | ^ к родителю #406 | Наверх | Cообщить модератору

	410. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 26-Сен-12, 14:04
	> Либо фс :-)) Многолетней практикой не подтверждено - значит руки.
	Ответить | Правка | ^ к родителю #408 | Наверх | Cообщить модератору

	480. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 02-Окт-12, 00:30
	>> Либо фс :-)) > Многолетней практикой не подтверждено - значит руки. Какая у вас интересная практика, неужели за все эти годы нельзя было научиться хотябы самому простому ? :-)))
	Ответить | Правка | ^ к родителю #410 | Наверх | Cообщить модератору

	485. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 02-Окт-12, 07:22
	> Какая у вас интересная практика, неужели за все эти годы нельзя было > научиться хотябы самому простому ? :-))) Моя практика стабильно работает годами на множестве серверов, поэтому заявления жопоруких о "либо ФС" мне как-то не интересны.
	Ответить | Правка | ^ к родителю #480 | Наверх | Cообщить модератору

	428. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Сен-12, 20:30
	> Либо фс :-)) Массовых воплей не видно при том что оно дефолтное в 100500 дистрах, стало быть дело не в бобине. Было б там все плохо - все багтрекеры бы уже легли под натиском пострадавших.
	Ответить | Правка | ^ к родителю #408 | Наверх | Cообщить модератору

	431. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от nagual (ok) on 26-Сен-12, 21:11
	>> Либо фс :-)) > Массовых воплей не видно при том что оно дефолтное в 100500 дистрах, > стало быть дело не в бобине. Было б там все плохо > - все багтрекеры бы уже легли под натиском пострадавших. Вот действительно у бсд до пследнего времени была всего одна UFS и никакой паники несмотря на грозные высеры ЛГМовцев :-))
	Ответить | Правка | ^ к родителю #428 | Наверх | Cообщить модератору

	452. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 30-Сен-12, 20:58
	> Вот действительно у бсд до пследнего времени была всего одна UFS и > никакой паники несмотря на грозные высеры ЛГМовцев :-)) Стало вместо 1 тормознутой ФС две. Вторая - тормознутая и переросточная. Ассортимент, однако :)
	Ответить | Правка | ^ к родителю #431 | Наверх | Cообщить модератору

	486. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 02-Окт-12, 07:23
	> Вот действительно у бсд до пследнего времени была всего одна UFS и > никакой паники несмотря на грозные высеры ЛГМовцев :-)) Да там так и есть "всего одна UFS", ZFS реально эксплуатабельной считать нельзя - так, для файлопомоек сгодится, но судя по Сети - реальных юзкейсов почти 0. Собственно, поэтому и никакой паники - число юзкейсов BSD не намного превышает число юзкейсов ZFS.
	Ответить | Правка | ^ к родителю #431 | Наверх | Cообщить модератору

	499. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 02-Окт-12, 13:44
	>> Вот действительно у бсд до пследнего времени была всего одна UFS и >> никакой паники несмотря на грозные высеры ЛГМовцев :-)) > Да там так и есть "всего одна UFS", ZFS реально эксплуатабельной считать > нельзя - так, для файлопомоек сгодится, но судя по Сети - > реальных юзкейсов почти 0. Собственно, поэтому и никакой паники - число > юзкейсов BSD не намного превышает число юзкейсов ZFS. Это статистика по твоей больнице что ли? :) Оно и понятно. http://forum.ixbt.com/topic.cgi?id=11:44215-77 80 человек юзают ZFS (во FreeBSD — 43 и 7 — в Solaris) 18 человек юзают Linux (Ext* или ZoL). 17 — Windows
	Ответить | Правка | ^ к родителю #486 | Наверх | Cообщить модератору

	500. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 02-Окт-12, 15:38
	88 человек - это МЕГА репрезентативная выборка, имя которой - "ни о чём". Тем более очень специфично то, что именно о NAS на x86 речь идёт. Совершенно бессмысленный и беспощадный юзкейс, хотя бы по электропитанию. Основная ЦА - самоделкины, которым в силу каких-то причин сильно лень купить нормальный сохошный NAS c линуксами внутри, стоящий гораздо меньше, чем железо, которое используется в треде. Нет, конечно, из имеющихся под рукой говна и палок можно и NAS слепить, но тогда уж надо себе сказать, что это чисто ради эксперимента. А если делать по уму - надо делать на ARM/MIPS, и нормально (как и сделано в нормальных NAS). У меня например сетевое хранилище совмещено с серваком, который и так есть. Тупо виртуалка с SMB и несколькими разделами ext4 на VMFS, который на рейде вместе со всем остальным. В отдельном NAS смысла не вижу. А юзерам, у которых сервака нет - на самоделия фиолетово, и они купят какой-нибудь SOHO NAS от WD или прочих компаний. Т.е., в итоге - имеем в треде узкий круг любителей городить огород там, где смысла в нем нет в принципе. Что показательно - в основном BSD'шники.
	Ответить | Правка | ^ к родителю #499 | Наверх | Cообщить модератору

	501. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 02-Окт-12, 15:52
	Вот гораздо более вменяемый юзкейс: http://www.dlink.ru/ru/products/120/1477.html Внутри - как бы ты думал, какая ОС? :) Куча хранилок корпоративного уровня от SYNOLOGY - тоже на нём :)
	Ответить | Правка | ^ к родителю #499 | Наверх | Cообщить модератору

	503. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 02-Окт-12, 16:04
	> Вот гораздо более вменяемый юзкейс: > http://www.dlink.ru/ru/products/120/1477.html > Внутри - как бы ты думал, какая ОС? :) > Куча хранилок корпоративного уровня от SYNOLOGY - тоже на нём :) Длинк гавно - проверено на wi-fi роутерах и адсл мопедах ...
	Ответить | Правка | ^ к родителю #501 | Наверх | Cообщить модератору

	504. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 02-Окт-12, 16:50
	> Длинк гавно - проверено на wi-fi роутерах и адсл мопедах ... Чем именно?
	Ответить | Правка | ^ к родителю #503 | Наверх | Cообщить модератору

	517. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 02-Окт-12, 21:44
	> Длинк гaвно - проверено на wi-fi роутерах и адсл мопедах ... Длинк - это тайванокитайцы. Поэтому у них есть все. От супершита до вполне нормальных девайсов. А модемы у них г, но местные тут когда-то делали для них нормальные прощивки. Был такой человек - McMcc. С его прошивками гэ вполне себе становилось конфеткой. Правда они прощелкали клювом и спец ушел делать прошивки конкурентам. FAIL, да. Упомянутый - девайс как девайс. Свою нишу имеет, народом покупается. В тиражах явно превосходящих ваши полтора^W 88 землекопов на многие порядки. А подобные по смыслу штуки есть и у synology, qnap и еще 100500 производителей. У некоторых на таком пепелаце даже LAMP отбабахан :)
	Ответить | Правка | ^ к родителю #503 | Наверх | Cообщить модератору

	518. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 03-Окт-12, 22:54
	> Вот гораздо более вменяемый юзкейс: > http://www.dlink.ru/ru/products/120/1477.html > Внутри - как бы ты думал, какая ОС? :) Тулчейн по изменению прошивки прилагается бесплатно или нужно подписывать специальное соглашение на ограничения по разработке и распространение технологических секретов? ;) > Куча хранилок корпоративного уровня от SYNOLOGY - тоже на нём :) Куча хранилок корпоративного уровня iXsystems, Inc. на FreeBSD с ZFS и что? Твоя пузомерка в чём заключается, в технологичности или в массовости/доступности (для средних умов)?
	Ответить | Правка | ^ к родителю #501 | Наверх | Cообщить модератору

	519. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 03-Окт-12, 23:02
	>> Вот гораздо более вменяемый юзкейс: >> http://www.dlink.ru/ru/products/120/1477.html >> Внутри - как бы ты думал, какая ОС? :) > Тулчейн по изменению прошивки прилагается бесплатно или нужно подписывать специальное > соглашение на ограничения по разработке и распространение технологических секретов? ;) >> Куча хранилок корпоративного уровня от SYNOLOGY - тоже на нём :) > Куча хранилок корпоративного уровня iXsystems, Inc. на FreeBSD с ZFS и что? > Твоя пузомерка в чём заключается, в технологичности или в массовости/доступности (для > средних умов)? Обновил скрипты http://actika.livejournal.com/619.html
	Ответить | Правка | ^ к родителю #518 | Наверх | Cообщить модератору

	520. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 03-Окт-12, 23:34
	> Куча хранилок корпоративного уровня iXsystems, Inc. на FreeBSD с ZFS и что? Простите, что такое iXSystems? D-Link, WD, Synology - их знает весь мир. А iXSystems? В реале не встречал ни разу, честно.
	Ответить | Правка | ^ к родителю #518 | Наверх | Cообщить модератору

	521. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 03-Окт-12, 23:34
	А, сам себе отвечу. Это чудесники, которые купили и похоронили PC-BSD...
	Ответить | Правка | ^ к родителю #520 | Наверх | Cообщить модератору

	523. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 04-Окт-12, 16:31
	> А, сам себе отвечу. Обновил тесты http://actika.livejournal.com/619.html ext4 сошел с дистанции ...
	Ответить | Правка | ^ к родителю #521 | Наверх | Cообщить модератору

	524. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 04-Окт-12, 21:44
	> Обновил тесты > http://actika.livejournal.com/619.html > ext4 сошел с дистанции ... Ржали над высером про фрагментацию на рамдиске всей командой. Потом на перекуре долго обсуждали - сколько нужно свободного места для дефрагментации. Пришли к выводу, что данный юзкейс с близким к 0 объемом свободного места и дефрагером мог придумать только клинический идиот. Заскриншотил, буду показывать образчик феерического бреда будущим коллегам и потомкам. Но вот за табличку с перформансами спасибо - сошлись во мнении, что табличка явно рассказывает, кто есть что.
	Ответить | Правка | ^ к родителю #523 | Наверх | Cообщить модератору

	525. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 04-Окт-12, 22:45
	>> Обновил тесты >> http://actika.livejournal.com/619.html >> ext4 сошел с дистанции ... > Ржали над высером про фрагментацию на рамдиске всей командой. > Потом на перекуре долго обсуждали - сколько нужно свободного места для дефрагментации. Вместе с доктором ? или опять соло ? > Пришли к выводу, что данный юзкейс с близким к 0 объемом свободного > места и дефрагером мог придумать только клинический идиот. Если дефрагментатор запускуается наверно он знает сколько ему нужно места ? Или админ с калькулятором прилагается к каждому дефрагментатору автоматически ? > Заскриншотил, буду показывать образчик феерического бреда будущим коллегам и потомкам. Тяжело спорить с клиническими идиотами, но я буду стараться ... > Но вот за табличку с перформансами спасибо - сошлись во мнении, что > табличка явно рассказывает, кто есть что. Ну да фаворит(ext4fs) выбыл по причине нестабильности ... все остальные либо дохлыей (рейзер) либо древние и заброшенные(ext3 ext2) либо впереди планеты всей (btrfs) :)))
	Ответить | Правка | ^ к родителю #524 | Наверх | Cообщить модератору

	526. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 04-Окт-12, 22:47
	> Ну да фаворит(ext4fs) выбыл по причине нестабильности ... пруф, или клиника...
	Ответить | Правка | ^ к родителю #525 | Наверх | Cообщить модератору

	527. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 04-Окт-12, 22:53
	>> Ну да фаворит(ext4fs) выбыл по причине нестабильности ... > пруф, или клиника... пруф жж если неасилили - клинака ...
	Ответить | Правка | ^ к родителю #526 | Наверх | Cообщить модератору

	529. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 05-Окт-12, 11:38
	> пруф жж если неасилили - клинака ... ваш жж - это не пруф, а набор отборного бреда за исключением таблички, которая четко показывает положение дел
	Ответить | Правка | ^ к родителю #527 | Наверх | Cообщить модератору

	530. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 05-Окт-12, 14:08
	> ваш жж - это не пруф, а набор отборного бреда > за исключением таблички, которая четко показывает положение дел Месье потрудится опровергнуть хотябы одно утверждение из жж ? а то слив не защитан ... По ссылке http://www.linux.org.ru/forum/talks/8255499?cid=8302757 разжеванный вариант специально для месье. > Ну да - всё те же тормоза. У меня тоже возникает ощущение что я спорю с тормозом. > Не ошибается тот, кто ничего не делает. Умные люди предпочитают учиться на чужих ошибках ...
	Ответить | Правка | ^ к родителю #529 | Наверх | Cообщить модератору

	531. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 05-Окт-12, 14:16
	> По ссылке http://www.linux.org.ru/forum/talks/8255499?cid=8302757 разжеванный вариант > специально для месье. Бугага, тебе и там разъяснили, что ты чушь порешь по большей мере. Удачи в жевании кактусов, бро. А твои "тесты" - полнейшая туфта. BONNIE+ я и сам взять могу.
	Ответить | Правка | ^ к родителю #530 | Наверх | Cообщить модератору

	347. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 23:41
	> Сие следует понимать так - нетаскать упс за ноутом удел нищебродов :-))) У ноута и так "ups" встроен.
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	122. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Сен-12, 12:34
	> А для моего десктопа критично. ;p Десктоп изена, тот что с голубыми кристаллами^W^W дисками выдающими 6Мб/сек :)
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	139. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 01:48
	>> А для моего десктопа критично. ;p > Десктоп изена, тот что с голубыми кристаллами^W^W дисками выдающими 6Мб/сек :) Хватит уже дурь свою показывать. Освободится место — скорость увеличится.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	149. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 09:57
	> Хватит уже дурь свою показывать. Освободится место — скорость увеличится. Не увеличится, дефраггера-то нетуть...
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	170. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 11:59
	>> Хватит уже дурь свою показывать. Освободится место — скорость увеличится. > Не увеличится, дефраггера-то нетуть... Освободил 30 ГБ — скорость возросла в разы. Что я сделал неправильно?
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	176. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 12:15
	> Освободил 30 ГБ — скорость возросла в разы. Что я сделал неправильно? Скорость чего? Перемещения руки вверх-вниз при просмотре содержимого? В какой-то соседней теме замеры уже выкладывались - всё очевидно, собственно.
	Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

	181. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 12:36
	>> Освободил 30 ГБ — скорость возросла в разы. Что я сделал неправильно? > Скорость чего? Перемещения руки вверх-вниз при просмотре содержимого? Скорость всего — чтения, записи, просмотра данных. > В какой-то соседней теме замеры уже выкладывались - всё очевидно, собственно. Вот и я говорю: спорить о скорости CoW при 97-99% заполненности данными не имеет смысла.
	Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

	301. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 06:50
	> Скорость всего — чтения, записи, просмотра данных. Чего бы это ради? Файлы которые разложились неудачно и читаются медленно - так и останутся разложенными неудачно и читающимися медленно. В принципе, им можно сделать "дефраг вручную", то-есть, освободив место скопировать файл заново, так что в лучшем случае он более линейно разложится, если стертые файлы были более линейно распиханы и свободное место линейное. А если они тоже были в состоянии макарон по всему диску - ну ты понял...
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	210. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 18:57
	> Вы хотите сказать: "Не так давно, хоть что-то появилось, что может что-то чинить"? > http://www.linux.org.ru/forum/talks/8203698/page4?lastmod=13... Гениально! На основании того что у кого-то разбился тестовый прототип самолета мы сделаем глобальный вывод: все самолеты - гэ! Defective by design! Ходите  пешком!!!1111
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	246. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 20:48
	>> Вы хотите сказать: "Не так давно, хоть что-то появилось, что может что-то чинить"? >> http://www.linux.org.ru/forum/talks/8203698/page4?lastmod=13... > Гениально! На основании того что у кого-то разбился тестовый прототип самолета мы > сделаем глобальный вывод: все самолеты - гэ! Defective by design! Ходите >  пешком!!!1111 Правильным выводом было бы приостановить эксплуатацию этой модели самолета (btrfs) и провести детальное исследование катастрофы для устанения возможных деффектов в этой модели.
	Ответить | Правка | ^ к родителю #210 | Наверх | Cообщить модератору

	302. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 06:54
	> Правильным выводом было бы приостановить эксплуатацию этой модели самолета (btrfs) и провести > детальное исследование катастрофы для устанения возможных деффектов в этой модели. Сложно "приостановить эксплуатацию" для штуки явно позиционируемой как тестовый прототип. И да, у гражданина ФС жила 2.5 года, т.е. ФС создавалась и изначально писалась куда как более древним ядром. Что оно там понаворотило и сколько багов с тех пор исправили - вопрос интересный. При том от предложения расследовать гражданин отказался и вообще шустро-быстро замел все следы, что как-то подозрительно. Ну то-есть гражданин как-то и не был заинтересован в изучении результатов. Ну так его право, тогда ему грех жаловаться. А учитывая размеры раздела "с кошкину задницу" и прочая - возникает ощущение что гражданин прямо заранее нацелился на то что у него тестовый самолет расшибется и он всем скажет какое это гэ.
	Ответить | Правка | ^ к родителю #246 | Наверх | Cообщить модератору

	128. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 21-Сен-12, 18:26
	>>Вот когда сможет хотя бы RAID-5, тогда приходите. > для моего ноута не критично. > использую бтр и не жалуюсь. >>Вот когда будет годный btrfsck, тогда и приходите. > во-первых - уже. > во-вторых - а в ZFS? :D > зыж > а ты придумал уже, что будешь писать, когда реализуют 5-й рэйд то? > а то уже скоро обещают, а ты и не готов? Ну вот каких то два дня обсуждений и выясняется что btrfs неимеет того функционала что есть в ZFS например ZFS рекомендуют ставить на диски заменяя функционал аппаратных рейдов и если btrfs с ее общесистемным кешем это отличноее решения для десктопа то ZFS с ее заменой рейда это решение для сервера ... честно говоря linux он больш для десктопа и на сервере ему делать нефиг. Была прада java которая по идейным сображениям (лицензионным вестимо) не работает на bsd но не волнуйтесь можно даже сказать не смневайтесь - оракл ёё похерит :))) судя по стремительности выпуска секурных обновлений работа в этом направлени просто кипит :)))
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	130. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 22-Сен-12, 09:12
	> Ну вот каких то два дня обсуждений и выясняется что btrfs неимеет Не с глаголами пишется раздельно :P. > того функционала что есть в ZFS Да, пока еще не абсолютно все фичи реализованы. Тем не менее, есть и фичи на которые ZFS будет нечем ответить без заметной переделки. Вон например не успели BSDшники попонтоваться насчет send/receive как он был реализован в свежих ядрах :) > например ZFS рекомендуют ставить на диски заменяя функционал аппаратных рейдов Аппаратные рэйды имеют как свои плюсы так и свои минусы. Из очевидных плюсов, у них бывает кэш с батарейкой на случай слета питания (батарейка программно, простите, не эмулируется) и оффлоад вычислений коррекции ошибок например. > и если btrfs с ее общесистемным кешем это отличноее решения для десктопа <sarcasm>Да, да, и вон та возможность ребалансинга на множество дисков - это тоже специально для десктопа сделано. Да что уж там, ноута с одним хилым винчом. Будем менеджить пул из целого 1 девайса, во! </sarcasm>. > то ZFS с ее заменой рейда это решение для сервера ... честно говоря linux он больш > для десктопа и на сервере ему делать нефиг. Ну да, конечно, вот всякие гуглы, фэйсбуки, твиттеры и прочие википедии, обслуживающие всю планету серваками с линуксом - они лохи. А вот некий nagual лучше них знает как надо. Радуют меня такие самоуверенные кексы, с умным виом несущие пургу :) > Была прада java которая по идейным сображениям (лицензионным вестимо) не работае на bsd В этом месте по сценарию iZEN делит на ноль в очередной раз :D. > но не волнуйтесь можно даже сказать не смневайтесь - оракл ёё похерит :))) Честно говоря - мне пофиг на яву. Вымрет - туда и дорога. Меньше будет быдлокодеров и тормозных бажных переростков (которых я не люблю независимо от лицензии за тот факт что они - тормозные переростки с кучей багов, в том числе ведущих к дырам в безопасности). > судя по стремительности выпуска секурных обновлений работа в этом направлени > просто кипит :))) Зато у бздельников все как обычно: паршиво поддерживается новое железо + на выбор две тормознутые ФС. Одна из которых к тому же прожорливая до RAM да еще и под кривой и странной лицензией от сан с легким копилефтным уклоном :). Зато, блин, не линукс и не гпл и "ваще типа крута, патамучта вася из 3-го подъезда так сказал".
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	132. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 22-Сен-12, 10:19
	> Да, пока еще не абсолютно все фичи реализованы. Тем не менее, есть > и фичи на которые ZFS будет нечем ответить без заметной переделки. О да как жежить под zfs и без дефрагментатора :-))) Обожаю дефрагментацию :))) > Аппаратные рэйды имеют как свои плюсы так и свои минусы. Из очевидных > плюсов, у них бывает кэш с батарейкой на случай слета питания > (батарейка программно, простите, не эмулируется) и оффлоад вычислений коррекции ошибок > например. Вы наверно не внимательно читали доку по zfs в двух словах это лучше чем контролер с батарейкой. Кстати иногда батарейки портятся и ппц подкрадывается незаметно :))) > Ну да, конечно, вот всякие гуглы, фэйсбуки, твиттеры и прочие википедии, обслуживающие > всю планету серваками с линуксом - они лохи. А вот некий > nagual лучше них знает как надо. Радуют меня такие самоуверенные кексы, > с умным виом несущие пургу :) На данный момент "всякие гуглы" не ставят сырые фс под хранилища ... > Зато у бздельников все как обычно: паршиво поддерживается новое железо + на > выбор две тормознутые ФС. Одна из которых к тому же прожорливая > до RAM да еще и под кривой и странной лицензией от > сан с легким копилефтным уклоном :). Зато, блин, не линукс и > не гпл и "ваще типа крута, патамучта вася из 3-го подъезда > так сказал". Что такое ? Месье неасилил поставить настроить bsd? Такой высокий порог вхождения? 8-0 А месье уже сделал домашние задания на понедельник ?
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	143. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 09:49
	> Что такое ? Месье неасилил поставить настроить bsd? Такой высокий порог вхождения? > 8-0 Простите, а зачем? Или ставить BSD ради поставить и настроить - это тренд такой? У нас и линуксы неплохо работают, и даже крутить 100500 тыщ ручек после установки не требуется в общем случае.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	152. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 11:08
	>> Что такое ? Месье неасилил поставить настроить bsd? Такой высокий порог вхождения? >> 8-0 > У нас и линуксы неплохо работают, и даже крутить > 100500 тыщ ручек после установки не требуется в общем случае. В одном из двух случаев "не" явно лишнее :-))
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	157. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 11:16
	> В одном из двух случаев "не" явно лишнее :-)) В случае с *BSD - вероятно, да.
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	211. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 19:12
	> О да как жежить под zfs и без дефрагментатора :-))) Не знаю как вы там "жежите". Это наверное тут оффтопик. > Обожаю дефрагментацию :))) А изен вон обожает 6Мб/сек со шпинделя. Тоже вариант :) >> (батарейка программно, простите, не эмулируется) и оффлоад вычислений коррекции ошибок например. > Вы наверно не внимательно читали доку по zfs в двух словах это лучше чем контролер > с батарейкой. Кстати иногда батарейки портятся и ппц подкрадывается незаметно :))) В доках от сана замечено много маркетингового булшита и хитрого виляния попой на неудобных вопросах. В частности, по вопросу насчет фрагментации везде технично повиляно попой. Маркетологи в санях не зря хлеб кушают, но мне то не маркетинг, а чтоб работало и хорошо. Btrfs до этого состояния допинают. Его нынче такая толпа пилит что по другому у них просто не получится. > На данный момент "всякие гуглы" не ставят сырые фс под хранилища ... А гуглу это и не надо от ФС. У них отказоустойчивость достигается иначе, путем раскидывания блоков по узлам с неким дублированием блоков, так что вылет узла вообще ничего не меняет. Вот только ставить 100500 серверов под распределенную ФС вместо десктопа или ноута мне кажется как-то слегонца оверкиллом. > Что такое ? Месье неасилил поставить настроить bsd? Мсье бодал что-то там "осиливать". Ему нужна система которая будет работать и делать свое дело. Желательно быстро, качественно и с минимальными усилиями на администрирование. А осиливать, то-есть жрать через силу кактус - это ваша прерогатива. > Такой высокий порог вхождения? Скорее, просто геморная и грабельная система. Созданная не для жизни а для сферических коней в вакууме. Осилить я могу хоть выставление состояний CPU тумблерами на шине. Только вот в общем случае могу != хочу этим постоянно заниматься на регулярной основе для повседневных задач. > А месье уже сделал домашние задания на понедельник ? Еще как. Лет ...цать назад.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	249. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 21:02
	> вместо десктопа или ноута ... Безусловно btrfs отличное решение для десктопа или ноута, правда на лоре пишут что за 2.5 года сдыхает, но ничего, починят, года этак через 2.5 :-))))) > Мсье бодал что-то там "осиливать". Ему нужна система которая будет работать и > делать свое дело. Желательно быстро, качественно и с минимальными усилиями на > администрирование. Помнится по apt-update обновление на grub2 пришло и один боевой серв после ребута не поднялся. Безусловно дебиан это система которая умеет работать и делать свое дело...быстро, качественно и с минимальными усилиями на администрирование. :-))) >> Такой высокий порог вхождения? > Скорее, просто геморная и грабельная система. Такое впечатление может возникнуть только у людей которым лень в чем то разбираться детально. >> А месье уже сделал домашние задания на понедельник ? > Еще как. Лет ...цать назад. Похоже не все.
	Ответить | Правка | ^ к родителю #211 | Наверх | Cообщить модератору

	303. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 07:03
	> Безусловно btrfs отличное решение для десктопа или ноута, правда на лоре пишут > что за 2.5 года сдыхает, Да, целый один перец, с странными параметрами и отказавшийся от расследования. Такой универсальный показатель отстойности, конечно. > но ничего, починят, года этак через 2.5 :-))))) Да может быть уже починили. Но гражданин и так и сяк отлынивает от разбора полетов. Ну раз отлынивает - значит и доверия такому гражданину нет. Если бы был разбор полетов - еще понятно, а так - "что-то сломалось, но что - не скажу, разбираться не будем, в общем гэ эта ФС". Очень конструктивный и внушающий доверие подход, конечно. > Помнится по apt-update обновление на grub2 пришло и один боевой серв после > ребута не поднялся. Простите, а у вас там что, testing или unstable был? Такие приколы только там бывали пару раз. Если вы их в боевых серверах юзаете - сами виноваты. > Безусловно дебиан это система которая умеет работать и > делать свое дело...быстро, качественно и с минимальными усилиями на > администрирование. :-))) Собственно, даже слетевший grub чинится за считанные минуты при наличии прямых рук. Но это актуально только для камикадзей которые зачем-то юзают testing или unstable. В релизной версии дебиана а так же всяких там убунтах - таких проблем не наблюдается. >> Скорее, просто геморная и грабельная система. > Такое впечатление может возникнуть только у людей которым лень в чем то > разбираться детально. Скорее, привыкать к чужой кривизне. Привыкнуть можно много к чему. Вот только нафиг нужно. >>> А месье уже сделал домашние задания на понедельник ? >> Еще как. Лет ...цать назад. > Похоже не все. Да, вот вы явно забивали и забиваете на домашние задания по русскому языку. Ай-яй-яй, нехорошо.
	Ответить | Правка | ^ к родителю #249 | Наверх | Cообщить модератору

	314. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 24-Сен-12, 11:22
	> Простите, а у вас там что, testing или unstable был? Такие приколы > только там бывали пару раз. Если вы их в боевых серверах > юзаете - сами виноваты. Всего пару раз :-))) зачет :-))) дебиан о такой дебиан :-))) > Собственно, даже слетевший grub чинится за считанные минуты при наличии прямых рук. > Но это актуально только для камикадзей которые зачем-то юзают testing или > unstable. В релизной версии дебиана а так же всяких там убунтах > - таких проблем не наблюдается. Это 100% был релиз :-))
	Ответить | Правка | ^ к родителю #303 | Наверх | Cообщить модератору

	350. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 23:45
	> Всего пару раз :-))) зачет :-))) дебиан о такой дебиан :-))) У дебиана есть свои проблемы. А у *bsd - свои. Если уж о дебиане вспомнили то чего-то debian/kfreebsd сильно сливает ... самому себе, но с пингвиньим ядром. Что недвусмысленно намекает что дебиан такой дебиан, а bsd такое bsd :) >> unstable. В релизной версии дебиана а так же всяких там убунтах - таких проблем не наблюдается. > Это 100% был релиз :-)) Ну фиг знает, мне о таких прецедентах со stable ничего не известно.
	Ответить | Правка | ^ к родителю #314 | Наверх | Cообщить модератору

	360. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 25-Сен-12, 00:13
	> Ну фиг знает, мне о таких прецедентах со stable ничего не известно. Теперь известно.
	Ответить | Правка | ^ к родителю #350 | Наверх | Cообщить модератору

	407. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Сен-12, 13:45
	> Теперь известно. Сферические прецеденты в вакууме - ну это круто, да. Извините, я когда-то имел дело с bsd а потом - с пингвинами. Результат сравнения был совсем не в пользу bsd. По поводу чего я предпочитаю пингвины. В 100500 раз меньше административного оврехеда.
	Ответить | Правка | ^ к родителю #360 | Наверх | Cообщить модератору

	140. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 01:53
	> Была прада java > которая по идейным сображениям (лицензионным вестимо) не работает на bsd но > не волнуйтесь можно даже сказать не смневайтесь - оракл ёё похерит > :))) судя по стремительности выпуска секурных обновлений работа в этом направлени > просто кипит :))) Почему я не удивляюсь твоей глупости? На, посмотри на Java в *BSD: http://www.freshports.org/search.php?query=jdk&num=500 http://www.freshports.org/search.php?query=jre&num=500 http://www.freebsd.org/ru/ports/java.html
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	151. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 11:00
	>> Была прада java >> которая по идейным сображениям (лицензионным вестимо) не работает на bsd но >> не волнуйтесь можно даже сказать не смневайтесь - оракл ёё похерит >> :))) судя по стремительности выпуска секурных обновлений работа в этом направлени >> просто кипит :))) > Почему я не удивляюсь твоей глупости? > На, посмотри на Java в *BSD: > http://www.freshports.org/search.php?query=jdk&num=500 > http://www.freshports.org/search.php?query=jre&num=500 > http://www.freebsd.org/ru/ports/java.html Я знаю что java отлично работает под bsd как и многое другое. Но сановская java не сертифицирована под bsd ибо бесплатные конкуренты нахер не нужны. Потому люди которые используют java ни в жизнь не поставят сее bsd ...
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	172. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 12:11
	>[оверквотинг удален] >>> просто кипит :))) >> Почему я не удивляюсь твоей глупости? >> На, посмотри на Java в *BSD: >> http://www.freshports.org/search.php?query=jdk&num=500 >> http://www.freshports.org/search.php?query=jre&num=500 >> http://www.freebsd.org/ru/ports/java.html > Я знаю что java отлично работает под bsd как и многое другое. > Но сановская java не сертифицирована под bsd ибо бесплатные конкуренты нахер > не нужны. Потому люди которые используют java ни в жизнь не > поставят сее bsd ... Картина маслом "Опять двойка". Сановская Java 5.0 и 6.0 была ещё сертифицирована под FreeBSD 6.x и 7.x. Технология Java™ получила право распространения в бинарном порте под именем Diablo-JDK/JRE для платформ [i386] и [amd64]. http://www.freebsdfoundation.org/downloads/java16.shtml //-- The FreeBSD Foundation has a license with Sun Microsystems to distribute FreeBSD binaries for the Java Runtime Environment (JRE) and Java Development Kit (JDK). These implementations have been made possible through the hard work of the FreeBSD Java team as well as through donations to the FreeBSD Foundation that supported hardware, developer costs, and legal fees. The official JRE and JDK binaries based on Sun's latest partner sources provide end-users and developers alike with confidence that they can use and create Java applications on FreeBSD with the same degree of portability, robustness and stability that they have come to expect from other supported operating systems. These binaries have been fully tested under Sun's compatibility test suite. --// Diablo JDK/JRE до сих пор поддерживается в текущих версиях FreeBSD через слой совместимости Compat7x. Периодически выходят критические исправления. Сейчас Oracle JDK доступен в виде порта java/jdk16. OpenJDK 6 и 7 доступны с последними исправлениями. Плагин для поддержки апплетов в браузере (icedtea-web-1.3) успешно работает в firefox-15.0.1 на платформе OpenJDK6 (openjdk6-b25_2).
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	190. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 16:49
	>> Я знаю что java отлично работает под bsd как и многое другое. >> Но сановская java не сертифицирована под bsd ибо бесплатные конкуренты нахер >> не нужны. Потому люди которые используют java ни в жизнь не >> поставят сее bsd ... > Картина маслом "Опять двойка". Месье не использует java но знает лучше людей использующий java ... Это уже диагноз.
	Ответить | Правка | ^ к родителю #172 | Наверх | Cообщить модератору

	195. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 17:04
	>>> Я знаю что java отлично работает под bsd как и многое другое. >>> Но сановская java не сертифицирована под bsd ибо бесплатные конкуренты нахер >>> не нужны. Потому люди которые используют java ни в жизнь не >>> поставят сее bsd ... >> Картина маслом "Опять двойка". > Месье не использует java но знает лучше людей использующий java ... Это > уже диагноз. Опять ты облажался, двоешник. % pkg_info -R openjdk6-b25_2 Information for openjdk6-b25_2: Required by: icedtea-web-1.3_1 rssowl-1.2.3_8 swt-3.5.2_2 eclipse-3.7.1_3 eclipse-emf-2.7.2 eclipse-gef-3.7.2 eclipse-datatools-1.9.2 eclipse-webtools-3.3.2 % uname -a FreeBSD roxy.fire 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Wed Sep 19 19:03:52 VOLT 2012     root@roxy.fire:/usr/obj/usr/src/sys/ROXY  amd64
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

	213. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 19:13
	Писец, вы умудрились обламерить даже друг друга.
	Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

	141. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 09:40
	> Ну вот каких то два дня обсуждений и выясняется что btrfs неимеет > того функционала что есть в ZFS например ZFS рекомендуют ставить на > диски заменяя функционал аппаратных рейдов За такие рекомендации надо отрывать руки. Я бы посмотрел, как любимая некоторыми извращенцами ZFS расковыривает "на лету" RAID6 (RSC) с одним отказавшим диском на "хиленьком" CPU общего назначения, просто не предназначенном для блочных вычислений, но там оного просто нет. И не будет, имхо. > рейда это решение для сервера ... честно говоря linux он больш > для десктопа и на сервере ему делать нефиг. Была прада java Садись, два.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	150. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 10:57
	> За такие рекомендации надо отрывать руки. Я бы посмотрел, как любимая некоторыми > извращенцами ZFS расковыривает "на лету" RAID6 (RSC) с одним отказавшим диском > на "хиленьком" CPU общего назначения, просто не предназначенном для блочных вычислений, > но там оного просто нет. И не будет, имхо. Дорогой контроллер рейда куча дисков и сервр на сдачу ? Месье стал жертвой маркетологов? Ему впихнули всерв все что завалялось на складе или вернулось по гарантии ? При таком уровне компетенции дальше можно не читать.
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	156. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 11:14
	> Дорогой контроллер рейда куча дисков и сервр на сдачу? Дорогой контроллер рейда? С разморозкой, дорогой друг. А тем временем даже дома уже контроллер с RAID6 стоит. Не софтовый. Intel RS2BL080.
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	159. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 11:18
	>> Дорогой контроллер рейда куча дисков и сервр на сдачу? > Дорогой контроллер рейда? С разморозкой, дорогой друг. > А тем временем даже дома уже контроллер с RAID6 стоит. Не софтовый. > Intel RS2BL080. Месье таки стал жертвой рекламы интела, 20к собаке в сраку :-)) а жена в курсе ? Месье откройте для себя FreeNAS.
	Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

	163. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 11:25
	> Месье таки стал жертвой рекламы интела, 20к собаке в сраку :-)) а > жена в курсе ? Месье откройте для себя FreeNAS. Зачем оно мне? У меня есть своя специфика - виртуалки, dev/test среда. Поэтому всякие поделия для домашних файлопомоек неприменимы. Увы. Я еще пока не настолько чокнулся, чтобы собирать на ФС на FreeNAS'е ядрышко или софт.
	Ответить | Правка | ^ к родителю #159 | Наверх | Cообщить модератору

	167. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 11:35
	>> Месье таки стал жертвой рекламы интела, 20к собаке в сраку :-)) а >> жена в курсе ? Месье откройте для себя FreeNAS. > Зачем оно мне? У меня есть своя специфика - виртуалки, dev/test среда. > Поэтому всякие поделия для домашних файлопомоек неприменимы. Увы. Я еще пока > не настолько чокнулся, чтобы собирать на ФС на FreeNAS'е ядрышко или > софт. Совершенно с вами сгласен связка lvm+ext4 явно не для сервера ...
	Ответить | Правка | ^ к родителю #163 | Наверх | Cообщить модератору

	174. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 12:13
	> Совершенно с вами сгласен связка lvm+ext4 явно не для сервера ... Только UFS, только хардкор.
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

	193. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от nagual (ok) on 23-Сен-12, 17:02
	>> Совершенно с вами сгласен связка lvm+ext4 явно не для сервера ... > Только UFS, только хардкор. Если бы месье вылез из криокамеры он бы написал UFS+J или хотябы UFS+S на вскидку отставание лет на 10-12 :-)))
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	205. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 18:42
	> Если бы месье вылез из криокамеры он бы написал UFS+J или хотябы > UFS+S на вскидку отставание лет на 10-12 :-))) Все равно до уровня ext4 этим ископаемым прилично далеко.
	Ответить | Правка | ^ к родителю #193 | Наверх | Cообщить модератору

	216. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 19:27
	>> Если бы месье вылез из криокамеры он бы написал UFS+J или хотябы >> UFS+S на вскидку отставание лет на 10-12 :-))) > Все равно до уровня ext4 этим ископаемым прилично далеко. "Ископаемое" UFS2 в 2006 имело возможность работы со снапшотами, ACL, квотами, фрагментами блоков и верифицироваться fsck в фоне. А "ультрасовременное" Ext* до этого ещё не эволюционировало. Такие дела в Linux-королевстве творятся, что дальше собственного носа подданные этого королевства ничего не видят. :))
	Ответить | Правка | ^ к родителю #205 | Наверх | Cообщить модератору

	219. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 19:40
	> "Ископаемое" UFS2 в 2006 имело возможность работы со снапшотами, ACL, квотами, Квотирование было еще в бородатом ext2 - http://www.linux.org.ru/books/HOWTO/Quota.html 1997 год мануалу, случилось же оно еще раньше. > фрагментами блоков А экстенты там уже есть, или все еще тупой блочный аллокатор имени FAT'ов? Снапшоты - в принципе не задача FS, хотя последнее время есть тенденции. LVM снапшоты делал еще в бородатом 2004. http://arstechnica.com/information-technology/2004/10/linux-.../ А вот fsck во время выполнения - это уже к божественным ветрам (kami kaze)
	Ответить | Правка | ^ к родителю #216 | Наверх | Cообщить модератору

	256. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 21:33
	> А вот fsck во время выполнения - это уже к божественным ветрам > (kami kaze) После сбоя питания в дц виртуалка грузится в ридонли и них...а не работает. Выключаем и запускаем fsck прямо с хоста ... вылечило так что востанавливать уже нех...р. ext4 такая современная ос, нужно дописать в документацию что после ребута fsck запускать ненужно, только время терять, нужно искать бакапы.
	Ответить | Правка | ^ к родителю #219 | Наверх | Cообщить модератору

	269. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 23:15
	> После сбоя питания в дц виртуалка грузится в ридонли и них...а не > работает. Выключаем и запускаем fsck прямо с хоста ... вылечило так Расскажи, как тебе это удаётся? Открою тебе маленький секрет: какое-то время на моем домашнем сервачке стоял рейд-контроллер без BBU, но со включенным кешем (тьфу-тьфу, сейчас BBU купил). Да, вопиющее просто нарушение всех канонов надежности системы, но благо бэкапы всегда под рукой... Так вот - отключения питания БЫЛИ. 4 активные площадки с ext4, журналировались только метаданные. И - ничего. Даже файлы в нули не вылетали. fsck находил мелкую хренотень при старте, типа несоответствия числа свободных блоков, и орфановых инодов (иноды, которые создались, но файлами стать не успели), и усё.
	Ответить | Правка | ^ к родителю #256 | Наверх | Cообщить модератору

	278. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 23:36
	- Как тебе это удаётся? Баримор - Хецнер сер. :)))))
	Ответить | Правка | ^ к родителю #269 | Наверх | Cообщить модератору

	426. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Сен-12, 19:31
	> - Хецнер сер. Видимо, ярый бсдшник не смог найти хостера где хостом был бы бсд и предлагали бы бсдшные системы :) Могу подсказать, есть firstvds. Правда работает все это так, что его можно советовать только в качестве жестокой шутки. Но вам - можно. Подумаешь, глюк на глюке и падает постоянно. Зато уютная бсдшечка :)
	Ответить | Правка | ^ к родителю #278 | Наверх | Cообщить модератору

	290. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 24-Сен-12, 00:25
	>> После сбоя питания в дц виртуалка грузится в ридонли и них...а не >> работает. Выключаем и запускаем fsck прямо с хоста ... вылечило так > Расскажи, как тебе это удаётся? > Открою тебе маленький секрет: какое-то время на моем домашнем сервачке стоял рейд-контроллер > без BBU, но со включенным кешем (тьфу-тьфу, сейчас BBU купил). Да, > вопиющее просто нарушение всех канонов надежности системы, но благо бэкапы всегда > под рукой... Так вот - отключения питания БЫЛИ. 4 активные площадки > с ext4, журналировались только метаданные. И - ничего. Даже файлы в > нули не вылетали. Интересно подтверждение целостности файлов: раз всё работает и не улетело, значит всё нормально. :)) Вы хоть сравните файлы с архивными копиями по CRC, а то мало ли что после такого сбоя питания... ;) > fsck находил мелкую хренотень при старте, типа несоответствия > числа свободных блоков, и орфановых инодов (иноды, которые создались, но файлами > стать не успели), и усё. Ну-ну. ;) С архивными копиями сравнить не помешало бы.
	Ответить | Правка | ^ к родителю #269 | Наверх | Cообщить модератору

	291. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 24-Сен-12, 00:30
	> Ну-ну. ;) С архивными копиями сравнить не помешало бы. А вот для этого очень могут пригодиться снапшеты :-))
	Ответить | Правка | ^ к родителю #290 | Наверх | Cообщить модератору

	292. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Сен-12, 00:30
	> Ну-ну. ;) С архивными копиями сравнить не помешало бы. Сравнивалось один раз. Непонятно, правда, зачем. Все, кроме СУБД - выживает. БД естественно оба раза разворачивал из бэкапов, и чистил все активные кеши, потому что реордеринг записи приводит к интересным последствиям. К слову, с ZFS будет совсем ни капельки не лучше, потому что гарантии выполнения записи в строго заданной "непротиворечивой" последовательности в этих страшных условиях (аппаратный RAID с активированным кешем, но без BBU) - никакой.
	Ответить | Правка | ^ к родителю #290 | Наверх | Cообщить модератору

	293. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Сен-12, 00:34
	Опять же - упрежу тонну треша про "непротиворечивость ZFS": "Непротиворечивость" как ZFS, так и BTRFS/ext4 базируется на механизме write barriers. В случае активации кеша контроллера WB снимается уже после записи в кеш, а на диск данные поступают, как попало - считается, что кеш удержится батарейкой, если что. Если батарейки нет - весь этот механизм не работает, и данные на диске порой оказываются в странных состояниях. ext'ам тут несколько проще даже - объем метаданных не так велик, так что шанс либо поступить целиком, либо не поступить вообще - более высок. Сразу говорю - не стоит в здравом уме делать то, что сделал я - включать кеш контроллера без BBU. Это путь камикадзе - и в своем случае я прекрасно понимал, для чего мне это надо, и где риски. С планом восстановления на любой случай. А в повседневной практике - лучше не повторять. Серьёзно.
	Ответить | Правка | ^ к родителю #292 | Наверх | Cообщить модератору

	295. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 24-Сен-12, 01:42
	> Опять же - упрежу тонну треша про "непротиворечивость ZFS": > "Непротиворечивость" как ZFS, так и BTRFS/ext4 базируется на механизме write barriers. До сих пор думал, что у ZFS непротиворечивость записи базируется на логике CoW (новые данные не перезаписывают предыдущие), ZIL (динамический журнал намерений системных вызовов дисковых транзакций, пока транзакционная группа DMU не будет сохранена в стабильный пул) и атомарном обновлении uber-блока после записи контрольных сумм. > В случае активации кеша контроллера WB снимается уже после записи в > кеш, а на диск данные поступают, как попало - считается, что > кеш удержится батарейкой, если что. Если батарейки нет - весь этот > механизм не работает, и данные на диске порой оказываются в странных > состояниях. Когда ZFS замечает, что с носителем творится что-то неладное, она перестаёт с ним работать и останавливается, чтобы не угробить записанные данные. > ext'ам тут несколько проще даже - объем метаданных не так велик, так > что шанс либо поступить целиком, либо не поступить вообще - более > высок. У вас, я смотрю, на уровне вероятности всё работает. :)) > Сразу говорю - не стоит в здравом уме делать то, что сделал > я - включать кеш контроллера без BBU. Это путь камикадзе - > и в своем случае я прекрасно понимал, для чего мне это > надо, и где риски. С планом восстановления на любой случай. А > в повседневной практике - лучше не повторять. Серьёзно. Попробуй повторить это с ZFS. Уверен, что эта ФС вовремя заметит неполадки в дисковой подсистеме и просто перестанет работать до устранения этих неполадок. Можешь даже задействовать команду "zpool import -F <poolname>" на убитом, как тебе покажется, пуле. ;)
	Ответить | Правка | ^ к родителю #293 | Наверх | Cообщить модератору

	307. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Сен-12, 07:22
	> До сих пор думал, что у ZFS непротиворечивость записи базируется на логике > CoW (новые данные не перезаписывают предыдущие), ZIL (динамический журнал намерений системных вызовов дисковых транзакций, пока транзакционная группа DMU не будет сохранена в стабильный пул) и атомарном обновлении uber-блока после записи контрольных сумм. Угу. Вот только без write barrier порядка записи никто не гарантирует, и любой блок может записаться на диск в любом порядке - а не так, как хотела FS. И не факт, что атомарно. В случае контроллеров с огромными кешами может быть еще и так, что добрая сотня транзакций запишется в произвольном порядке. > Когда ZFS замечает, что с носителем творится что-то неладное, она перестаёт с > ним работать и останавливается, чтобы не угробить записанные данные. Угу. Это будет также ровно на этапе монтирования. > У вас, я смотрю, на уровне вероятности всё работает. :)) Скорее - на уровне теории, подтверждаемой практикой. > Попробуй повторить это с ZFS. Уверен, что эта ФС вовремя заметит неполадки > в дисковой подсистеме и просто перестанет работать до устранения этих неполадок. Фокус знаешь в чем? Ровно до момента отключения питания нет никаких неполадок. А после отключения InnoDB хоть как будет разрушен - потому что часть данных запишется, а часть - нет. Причем заранее неизвестно, в каких "версиях" будут конкретные блоки - например блоки с порядковыми номерами 100498 и 100500 могут оказаться записаны, вместе с "правильным" суперблоком и CRC, а блок с номером 100499 - нет, не успел. Но если честно - заинтриговал. Наверное, возьму спецом ZFS-FUSE, отдельный диск, и попробую воспроизвести - найду еще одну тачку с LSI, сниму BBU, выключу кеш на всём, кроме тестового диска, и устрою потерю питания. Быстро не обещаю, но протестирую.
	Ответить | Правка | ^ к родителю #295 | Наверх | Cообщить модератору

	325. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 24-Сен-12, 20:13
	>> До сих пор думал, что у ZFS непротиворечивость записи базируется на логике >> CoW (новые данные не перезаписывают предыдущие), ZIL (динамический журнал намерений системных вызовов дисковых транзакций, пока транзакционная группа DMU не будет сохранена в стабильный пул) и атомарном обновлении uber-блока после записи контрольных сумм. > Угу. Вот только без write barrier порядка записи никто не гарантирует, и > любой блок может записаться на диск в любом порядке - а > не так, как хотела FS. И не факт, что атомарно. В > случае контроллеров с огромными кешами может быть еще и так, что > добрая сотня транзакций запишется в произвольном порядке. Так запишется или нет? Если запишется, то, очевидно, вся транзакционная группа DMU. А уж порядок внутри неё не имеет никакого значения. Если не запишется (питание вырубилось, батарейки нет), то ZFS останется в том состоянии, в котором была до записи транзакционной группы DMU, и ничего восстанавливать не надо — ZFS в непротиворечивом состоянии.   >> Когда ZFS замечает, что с носителем творится что-то неладное, она перестаёт с >> ним работать и останавливается, чтобы не угробить записанные данные. > Угу. Это будет также ровно на этапе монтирования. Если носитель "протёртый до дыр", то с ним никакая ФС не будет нормально работать. >> Попробуй повторить это с ZFS. Уверен, что эта ФС вовремя заметит неполадки >> в дисковой подсистеме и просто перестанет работать до устранения этих неполадок. > Фокус знаешь в чем? Ровно до момента отключения питания нет никаких неполадок. > А после отключения InnoDB хоть как будет разрушен - потому что > часть данных запишется, а часть - нет. Не бывает такого, чтобы на ZFS файл не до конца модифицировался и остался в "промежуточном" состоянии модификации, если только такой случай прямо не поддерживается в программном обеспечении, которое использует данный файл. СУБД относятся к такому ПО, и у них (у нормальных СУБД) есть собственная подсистема журналирования транзакций с возможностью отмены незавершённых транзакций (rollback). В этом случае ZFS уж точно оставляет файлы в том состоянии, когда они были нормальными, а не забивает их нулями, как некоторые классические ФС при аварийном отказе питания. > Причем заранее неизвестно, в каких "версиях" будут конкретные блоки - например блоки > с порядковыми номерами 100498 и 100500 могут оказаться записаны, вместе с > "правильным" суперблоком и CRC, а блок с номером 100499 - нет, > не успел. Ты описал типичную ситуацию проблемы "Write hole" для аппаратного RAID-5. Вкратце: http://phpsuxx.blogspot.com/2010/08/raid-z.html > Но если честно - заинтриговал. Наверное, возьму спецом ZFS-FUSE, отдельный диск, и > попробую воспроизвести - найду еще одну тачку с LSI, сниму BBU, > выключу кеш на всём, кроме тестового диска, и устрою потерю питания. > Быстро не обещаю, но протестирую. А чего ж не ядерный модуль ZFSonLinux? С FUSE намучаешься.
	Ответить | Правка | ^ к родителю #307 | Наверх | Cообщить модератору

	330. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Сен-12, 20:53
	> Так запишется или нет? Может быть запишется, а может быть нет. А может быть и не всё. > Если запишется, то, очевидно, вся транзакционная группа DMU. Не факт. Реордеринг записи имеет место быть - поэтому и не выживают СУБД без BBU. > Если не запишется (питание вырубилось, батарейки нет), то ZFS останется в том состоянии, в котором была до записи транзакционной группы DMU Транзакционность обеспечивается write barrier'ом. Когда оно не работает, а данные записываются в порядке 100500 - 999 - 1 - 768 - 993 - 998 - ... - ни о какой непротиворечивости и речи быть не может. Поэтому батарейка для кеша обязательна. > Если носитель "протёртый до дыр", то с ним никакая ФС не будет > нормально работать. А при чём тут протёртый до дыр носитель? > Не бывает такого, чтобы на ZFS файл не до конца модифицировался и Это в штатных условиях. А в нештатных - см. выше. > к такому ПО, и у них (у нормальных СУБД) есть собственная > подсистема журналирования транзакций с возможностью отмены незавершённых транзакций Которая также расчитана на транзакционность железа. Совершенно нештатный режим (контроллер с активным writeback кешем, но без BBU) - убивает эту логику полностью. > Ты описал типичную ситуацию проблемы "Write hole" для аппаратного RAID-5. > Вкратце: http://phpsuxx.blogspot.com/2010/08/raid-z.html Это не write hole, это ХУЖЕ. Тут объем - не страница R5, а совершенно произвольный. Может даже так случиться, что последние поступившие 400-500 Мб запишутся, а первые 2-3 - нет. > А чего ж не ядерный модуль ZFSonLinux? С FUSE намучаешься. Лениво мучать ядрышко. С FUSE проще.
	Ответить | Правка | ^ к родителю #325 | Наверх | Cообщить модератору

	294. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 24-Сен-12, 00:42
	>> Ну-ну. ;) С архивными копиями сравнить не помешало бы. > Все, кроме СУБД - выживает. Умеете вы людей обрадовать ...
	Ответить | Правка | ^ к родителю #292 | Наверх | Cообщить модератору

	308. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Сен-12, 07:24
	>>> Ну-ну. ;) С архивными копиями сравнить не помешало бы. >> Все, кроме СУБД - выживает. > Умеете вы людей обрадовать ... Ну я же спецом написал: "Сразу говорю - не стоит в здравом уме делать то, что сделал я - включать кеш контроллера без BBU." Она не выживает не из-за FS, а из-за того, что запись идёт в совершенно отличном от того, что ожидает движок, порядке, и write barriers не работают.
	Ответить | Правка | ^ к родителю #294 | Наверх | Cообщить модератору

	458. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 01-Окт-12, 00:24
	Наброски в продолжение темы: http://actika.livejournal.com/619.html
	Ответить | Правка | ^ к родителю #290 | Наверх | Cообщить модератору

	460. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 01-Окт-12, 09:31
	> Наброски в продолжение темы: > http://actika.livejournal.com/619.html Ещё проверь ZFS с checksum=off.
	Ответить | Правка | ^ к родителю #458 | Наверх | Cообщить модератору

	463. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 01-Окт-12, 14:42
	> Наброски в продолжение темы: > http://actika.livejournal.com/619.html Несмотря на то, что тест - сферический и в вакууме (ну идиотизм тестировать FS на рамдиске), но из-за того, что основная нагрузка теста ложится на пропускную способность памяти - он ярко показывает архитектурные различия ядер. Судя по таблице - UFS непригодна для эксплуатации вообще: явно отсутствует zero-copy, и совсем всё плохо с алгоритмами работы. ZFS спасает то, что там есть кеш 2 уровня, логика которого, видимо, работает достаточно шустро. И еще то, что она игнорирует встроенную логику файловых систем *BSD, являясь независимой надстройкой над ней. С Linux же всё в таблице куда лучше. Вся инфраструктура одинаково умеет zero-copy, поэтому производительность любой из опробованных FS на рамдиске - весьма и весьма на высоте. seek-тест на рамдиске - это фееричненько, но убожество реализации дисковой подсистемы в BSD хорошо видно и там. Итого уже даже без всех данных видно, что имеем то, что имеем - вся дисковая подсистема в FreeBSD жутко грузит CPU и шину памяти. Что, в общем, и не удивительно - между академичностью и технологичностью огромная пропасть.
	Ответить | Правка | ^ к родителю #458 | Наверх | Cообщить модератору

	464. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 01-Окт-12, 14:51
	> Судя по таблице - UFS непригодна для эксплуатации вообще: явно отсутствует zero-copy, > и совсем всё плохо с алгоритмами работы. Бедненькие бздунишки — мучаются со всеми этими допотопными FS и горя не знают. Лёша их жалеет. :)) > ZFS спасает то, что там есть кеш 2 уровня, логика которого, видимо, > работает достаточно шустро. И еще то, что она игнорирует встроенную логику > файловых систем *BSD, являясь независимой надстройкой над ней. Кэш второго уровня включается вручную, вообще-то, если есть скоростные носители. Обычно он: "L2ARC is disabled". > С Linux же всё в таблице куда лучше. Вся инфраструктура одинаково умеет > zero-copy, поэтому производительность любой из опробованных FS на рамдиске - весьма > и весьма на высоте. Так как в Linux создать полноценный RAM-диск? Кроме tmpfs вроде ничего нету. А файловая система в файле не интересна — включается двойное кэширование и буферизация данных.
	Ответить | Правка | ^ к родителю #463 | Наверх | Cообщить модератору

	469. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 01-Окт-12, 15:45
	> Бедненькие бздунишки — мучаются со всеми этими допотопными FS и горя не > знают. Лёша их жалеет. :)) А чего еще остается? Только пожалеть людей, желающих добровольно грызть кактусы. А "бед не знают" - может быть потому, что BSD реально уже используется только "энтузиастами". > Кэш второго уровня включается вручную, вообще-то, если есть скоростные носители. Обычно > он: "L2ARC is disabled". Значит только то, что он не использует основную часть логики FS ядра BSD... > Так как в Linux создать полноценный RAM-диск? Кроме tmpfs вроде ничего нету. > А файловая система в файле не интересна — включается двойное кэширование > и буферизация данных. И даже с "двойным кешированием и буферизацией" оно оказывается быстрее BSD'шной логики без кеширований и буферизаций.
	Ответить | Правка | ^ к родителю #464 | Наверх | Cообщить модератору

	470. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 01-Окт-12, 16:23
	>> А файловая система в файле не интересна — включается двойное кэширование >> и буферизация данных. Если уж быть совсем честным - в Linux ничего, кстати, не включается. Потому, что страницы tmpfs и так считаются кэшем. Поскольку на протяжении всей цепочки от FS до юзерспейса используется zero-copy - ни о какой буферизации вообще речи нет. Отсюда и разница в производительности по сравнению с BSD.
	Ответить | Правка | ^ к родителю #469 | Наверх | Cообщить модератору

	495. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 02-Окт-12, 11:50
	>>> А файловая система в файле не интересна — включается двойное кэширование >>> и буферизация данных. > Если уж быть совсем честным - в Linux ничего, кстати, не включается. > Потому, что страницы tmpfs и так считаются кэшем. Поскольку на протяжении > всей цепочки от FS до юзерспейса используется zero-copy - ни о > какой буферизации вообще речи нет. Отсюда и разница в производительности по > сравнению с BSD. Что, уже и тесты есть для сравнения производительности фришных md(4)-девайсов и линуксовой tmpfs? А когда tmpfs перелезет в SWAP из-за нехватки места в ОЗУ, то всё равно быстрее RAM-диска md будет? Волшебно. Ж)
	Ответить | Правка | ^ к родителю #470 | Наверх | Cообщить модератору

	496. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 02-Окт-12, 11:52
	>>>> А файловая система в файле не интересна — включается двойное кэширование >>>> и буферизация данных. >> Если уж быть совсем честным - в Linux ничего, кстати, не включается. >> Потому, что страницы tmpfs и так считаются кэшем. Поскольку на протяжении >> всей цепочки от FS до юзерспейса используется zero-copy - ни о >> какой буферизации вообще речи нет. Отсюда и разница в производительности по >> сравнению с BSD. > Что, уже и тесты есть для сравнения производительности фришных md(4)-девайсов и линуксовой > tmpfs? А когда tmpfs перелезет в SWAP из-за нехватки места в > ОЗУ, то всё равно быстрее RAM-диска md будет? Волшебно. Ж) http://www.linuxforums.org/forum/installation/11239-what-doe... Наверно и под фрей имеет смысл сделать рам диск при загрузке.
	Ответить | Правка | ^ к родителю #495 | Наверх | Cообщить модератору

	498. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 02-Окт-12, 12:48
	> Что, уже и тесты есть для сравнения производительности фришных md(4)-девайсов и линуксовой tmpfs? А когда tmpfs перелезет в SWAP из-за нехватки места в > ОЗУ, то всё равно быстрее RAM-диска md будет? Волшебно. Ж) 1. А что, мы сравниваем FS при перелезании в свап, или, может быть, просто FS на рамдисках? 2. Если рамдиск в BSD такое убожество, что убивает производительность - это проблема BSD. 3. Я уже говорил, что это сферический тест в вакууме, без реальной подоплеки - т.е. идиотизм. Но тем не менее, кое-что он показал явно - нагрузка на ПСП при работе FS на рамдисках в BSD в разы выше, нежели в Linux.
	Ответить | Правка | ^ к родителю #495 | Наверх | Cообщить модератору

	502. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 02-Окт-12, 15:56
	>>>> А файловая система в файле не интересна — включается двойное кэширование >>>> и буферизация данных. >> Если уж быть совсем честным - в Linux ничего, кстати, не включается. >> Потому, что страницы tmpfs и так считаются кэшем. Поскольку на протяжении >> всей цепочки от FS до юзерспейса используется zero-copy - ни о >> какой буферизации вообще речи нет. Отсюда и разница в производительности по >> сравнению с BSD. > Что, уже и тесты есть для сравнения производительности фришных md(4)-девайсов и линуксовой > tmpfs? А когда tmpfs перелезет в SWAP из-за нехватки места в > ОЗУ, то всё равно быстрее RAM-диска md будет? Волшебно. Ж) Обновил тесты в жж.
	Ответить | Правка | ^ к родителю #495 | Наверх | Cообщить модератору

	505. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 02-Окт-12, 16:57
	> Обновил тесты в жж. В общем-то, ничего не изменилось :) BSD все так же сливает по загрузке системы при работе с FS по всем показателям. Кроме того - появилось дополнительное подтверждение тому, что это из-за архитектурной особенности: отсутствия zero-copy механизмов. Тест "zfs" - это тест zfsOL, правильно? В ZFS под Linux де-факто отсутствует zero-copy. Результаты тестирования нагрузки на шину памяти (а ничем иным тест с фс на рамдиске не является) от zfs под Linux тоже не радостные.
	Ответить | Правка | ^ к родителю #502 | Наверх | Cообщить модератору

	506. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 02-Окт-12, 17:10
	>> Обновил тесты в жж. > В общем-то, ничего не изменилось :) BSD все так же сливает по > загрузке системы при работе с FS по всем показателям. Месье вообще куда смотрит ? Эксклюзивные галюцинации ? > Кроме того - появилось дополнительное подтверждение тому, что это из-за архитектурной особенности: > отсутствия zero-copy механизмов. Тест "zfs" - это тест zfsOL, правильно? В > ZFS под Linux де-факто отсутствует zero-copy. Результаты тестирования нагрузки на шину > памяти (а ничем иным тест с фс на рамдиске не является) > от zfs под Linux тоже не радостные. В данном тесте zfs единственная журналируемая фс, так как ext4 это псевдо журналируемая. Тесты с рейзером добавлю. Но и так видно что реализация zfs под linux не супер. Ах да btr опять улетел в кувет, ну что за непруха...
	Ответить | Правка | ^ к родителю #505 | Наверх | Cообщить модератору

	471. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 16:42
	> Наброски в продолжение темы: Набросы. Унылые при том. > http://actika.livejournal.com/619.html Не в обиду тому кто делал бенчи, 1) Я не вижу тестов btrfs в этой таблице. Совсем. Вякнуть что-то про то что он "как ufs" - самое эпичное ламерство всех времен и народов. До такого даже на форониксе не додумываются. Просто потому что совершенно разные по устройству ФС с разными свойствами. 2) Даже всеми обсираемый фороникс все-таки в состоянии нормально оформить результаты. А данный автор настолько ж@порук что даже таблицу читабельно сделать не может. У меня глаза сломались при попытке хоть как-то сравнить по такой таблице что получилось.
	Ответить | Правка | ^ к родителю #458 | Наверх | Cообщить модератору

	473. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 01-Окт-12, 16:58
	> Набросы. Унылые при том. Нечитал но осуждаю ? > Не в обиду тому кто делал бенчи, > 1) Я не вижу тестов btrfs в этой таблице. Совсем. Вякнуть что-то > про то что он "как ufs" - самое эпичное ламерство всех > времен и народов. До такого даже на форониксе не додумываются. Просто > потому что совершенно разные по устройству ФС с разными свойствами. Месье ниасилил пояснения к тестам ? Итак на диске с btrfs в 6 гиг тест bonnie++ валится при попытке записи 5300 мег при этом dd легко пишет 5400 ... Rewriting...Can't write block.: No space left on device Bonnie: drastic I/O error (re write(2)): No space left on device Такая точно херня с геом журналом, но последний хотябы рекомендуют делать отдельным слайсом. Можно разбить 6 гиг на 5 и 1 и проверить ... > 2) Даже всеми обсираемый фороникс все-таки в состоянии нормально оформить результаты. Раскажите это создателям жж с их афуенно жопоруким редактором. > А данный автор настолько ж@порук что даже таблицу читабельно сделать не может. Еще раз таблица генерится bon_csv2html из пакета bonnie++ а вот как ее покажет жж это не к тестеровщику вопрос.
	Ответить | Правка | ^ к родителю #471 | Наверх | Cообщить модератору

	484. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 02-Окт-12, 07:19
	> Еще раз таблица генерится bon_csv2html из пакета bonnie++ а вот как ее > покажет жж это не к тестеровщику вопрос. "Мотоцикл не мой, я только разместил объяву"?
	Ответить | Правка | ^ к родителю #473 | Наверх | Cообщить модератору

	220. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 19:41
	posix ACL тоже были в ext2 как минимум в 2003 так что, увы, археологи археологами и останутся
	Ответить | Правка | ^ к родителю #216 | Наверх | Cообщить модератору

	236. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 20:35
	>> Если бы месье вылез из криокамеры он бы написал UFS+J или хотябы >> UFS+S на вскидку отставание лет на 10-12 :-))) > Все равно до уровня ext4 этим ископаемым прилично далеко. ДА было дело при запущенном fsck в фоне открытый на запись файл обнуляло в UFS+S но до такова уровня как в lvm+ext4 чтоб похерить весь раздел до невозможности востановления через fsck таки да небыло ниразу ...
	Ответить | Правка | ^ к родителю #205 | Наверх | Cообщить модератору

	240. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 20:39
	> ДА было дело при запущенном fsck в фоне открытый на запись файл > обнуляло в UFS+S но до такова уровня как в lvm+ext4 чтоб > похерить весь раздел до невозможности востановления через fsck таки да небыло > ниразу ... Дык. Тут нужен специальный угол рук и необычное местоположение их начала.
	Ответить | Правка | ^ к родителю #236 | Наверх | Cообщить модератору

	409. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Сен-12, 14:02
	> Дык. Тут нужен специальный угол рук и необычное местоположение их начала. Достаточно быть осьминогом. Когда руки, голова и задница совмещены в одном месте.
	Ответить | Правка | ^ к родителю #240 | Наверх | Cообщить модератору

	214. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 19:21
	> Если бы месье вылез из криокамеры он бы написал UFS+J или хотябы > UFS+S на вскидку отставание лет на 10-12 :-))) А какая разница? КрЮтые разработчики BSD заявили что на капитальную переделку этого - ресурсов нет. Так что к запору примотали "скамейку" проволокой, кой-как привинтили колеса от мерса и наклеили наклейки SPARCO. Типа, заапгрейдили. Правда, аэродинамика лучше не стала, да и двигатель - тоже. Поэтому быстрее ездить и меньше тарахтеть оно не стало. Вот UFS-хоть-там-плюс-что отличается редкостной тормознутостью. Достаточно любой бенч на одинаковом оборудовании запустить. И да, EXT4 порвет этот античный хлам как тузик грелку. По крайней мере, в нем доперли сделать экстенты наконец. А в UFS - их нет.
	Ответить | Правка | ^ к родителю #193 | Наверх | Cообщить модератору

	217. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 19:31
	>> Если бы месье вылез из криокамеры он бы написал UFS+J или хотябы >> UFS+S на вскидку отставание лет на 10-12 :-))) > Вот UFS-хоть-там-плюс-что отличается редкостной > тормознутостью. Достаточно любой бенч на одинаковом оборудовании запустить. И да, EXT4 > порвет этот античный хлам как тузик грелку. Может и пруфлинки на тестирование Ext4 и UFS2+SJ предоставите? Не стесняйтесь. Обсудим. > По крайней мере, в нем доперли сделать экстенты наконец. А в UFS - их нет. UFS2 работает на уровне фрагментов блоков. А в Ext* такого нет, а значит теряется свободное пространство на мелких файлах — блоки заполнены не до конца, а распределить незаполненные "хвосты" эта ФС не в силах. :p
	Ответить | Правка | ^ к родителю #214 | Наверх | Cообщить модератору

	221. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 19:48
	> Может и пруфлинки на тестирование Ext4 и UFS2+SJ предоставите? Не стесняйтесь. Обсудим. http://www.phoronix.com/scan.php?page=article&item=zfs_ext4_... Похороникс, конечно, но тесты вполне реальны. Особенно весел тест на TPS. Ставить ТАКОЕ (UFS) на боевые серверы - лучше сразу застрелиться.
	Ответить | Правка | ^ к родителю #217 | Наверх | Cообщить модератору

	226. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 20:24
	>> Может и пруфлинки на тестирование Ext4 и UFS2+SJ предоставите? Не стесняйтесь. Обсудим. > http://www.phoronix.com/scan.php?page=article&item=zfs_ext4_... > Похороникс, конечно, но тесты вполне реальны. > Особенно весел тест на TPS. Ставить ТАКОЕ (UFS) на боевые серверы - > лучше сразу застрелиться. Пруфлинк не годен. Там UFS+J (журнал на уровне GEOM) и UFS+S (это просто Soft-updates). Я просил сравнение современных технологий файловых систем (прежде всего UFS2+SUJ, где журнал располагается на уровне файловой системы и одновременно поддерживается Soft-updates), а ты подсунул какую-то тухлятину 2010 года. К тому же, в пяти тестах из одиннадцати ZFS очень хорошо так нагнула традиционную ФС — Ext4, а это, знаешь ли, показательно. Что там делала Btrfs, не вполне ясно — она в то время ничего не умела, кроме как терять данные на ровном месте.
	Ответить | Правка | ^ к родителю #221 | Наверх | Cообщить модератору

	231. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 20:30
	Тестов UFS2 практически нет, что означает только одно: Неуловимый Джо. > К тому же, в пяти тестах из одиннадцати ZFS очень хорошо так > нагнула традиционную ФС — Ext4 Если приглядеться - это конкретная группа тестов: на запись, причем на запись небольшую и многопоточную. Логично, что ZFS и BTRFS тут слегка "на коне", поскольку превратили рандомную запись в линейную - это "плюшка" CoW. Но вот как только объём многопоточной записи в той же группе тестов стал достаточно большим - ZFS слилась полностью... причём скорее всего именно из-за архаичного блочного аллокатора, который был вынужден лопатить горы метаданных. А у BTRFS... ничего не произошло - как выигрывала за счёт превращения произвольной записи (треды) в линейную, так и выиграла. Аллокация экстента на пустом диске - задача не ахти какая сложная.
	Ответить | Правка | ^ к родителю #226 | Наверх | Cообщить модератору

	420. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Сен-12, 17:15
	> Тестов UFS2 практически нет, что означает только одно: Неуловимый Джо. На форониксе бывали, но увидев непотребный результат бздуны как обычно орут что фороникс аццтой. Разумеется переделывать бенчи для доказательства тезиса всем лень. Орать то намного проще.
	Ответить | Правка | ^ к родителю #231 | Наверх | Cообщить модератору

	434. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от Аноним (??) on 27-Сен-12, 15:29
	> а ты подсунул какую-то тухлятину 2010 года. Так с тех пор никто не переделывал основные дисковые структуры ФС. А тормоза именно из-за них, никакой +SUJ там не поможет особо. Выглядит все это безобразие как-то так: http://i077.radikal.ru/1102/50/794f2fb9e84e.jpg
	Ответить | Правка | ^ к родителю #226 | Наверх | Cообщить модератору

	437. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 28-Сен-12, 12:28
	>> а ты подсунул какую-то тухлятину 2010 года. > Так с тех пор никто не переделывал основные дисковые структуры ФС. А > тормоза именно из-за них, никакой +SUJ там не поможет особо. Правда что ли? Тебе надо покопаться в истории изменений UFS/FFS за последний год что ли, чтобы увидеть обратное. > Выглядит все это безобразие как-то так: http://i077.radikal.ru/1102/50/794f2fb9e84e.jpg Ну да, Ext4 так и выглядит. Только бампер подновлён. :))
	Ответить | Правка | ^ к родителю #434 | Наверх | Cообщить модератору

	440. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 28-Сен-12, 15:20
	> Ну да, Ext4 так и выглядит. Только бампер подновлён. :)) Ну вот неправда же там все переделали на спичках :-))
	Ответить | Правка | ^ к родителю #437 | Наверх | Cообщить модератору

	441. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 28-Сен-12, 15:21
	> Ну да, Ext4 так и выглядит. Только бампер подновлён. :)) А еще загладывая в будущее разработчики ext4 прицепили инвалидную каляску вместо подушек безопасности. Ну просто провидцы :-)))
	Ответить | Правка | ^ к родителю #437 | Наверх | Cообщить модератору

	442. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 30-Сен-12, 19:09
	>>> а ты подсунул какую-то тухлятину 2010 года. >> Так с тех пор никто не переделывал основные дисковые структуры ФС. А >> тормоза именно из-за них, никакой +SUJ там не поможет особо. > Правда что ли? Тебе надо покопаться в истории изменений UFS/FFS за последний > год что ли, чтобы увидеть обратное. >> Выглядит все это безобразие как-то так: http://i077.radikal.ru/1102/50/794f2fb9e84e.jpg > Ну да, Ext4 так и выглядит. Только бампер подновлён. :)) Хотел потестить ext4 и оказалось что в линуксе диск в памяти нельзя отформатировать во что то вообще :-)) там только tmpfs ...
	Ответить | Правка | ^ к родителю #437 | Наверх | Cообщить модератору

	443. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 30-Сен-12, 19:12
	> Хотел потестить ext4 и оказалось что в линуксе диск в памяти нельзя > отформатировать во что то вообще :-)) там только tmpfs ... Сферический тест в вакууме без реальной составляющей? Ну давай, успехов...
	Ответить | Правка | ^ к родителю #442 | Наверх | Cообщить модератору

	449. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 30-Сен-12, 20:00
	>> Хотел потестить ext4 и оказалось что в линуксе диск в памяти нельзя >> отформатировать во что то вообще :-)) там только tmpfs ... > Сферический тест в вакууме без реальной составляющей? Ну давай, успехов... У разработчиков фс в линуксе даже нет возможности потестить свою фс на быстром мемдиске. Неудивительно что разработка btrfs идет просто стремительно, а ext4 до сих пор теряет файлы после ребута ... ЗЫ В винде это было еще во времена Колчака ... :-)))
	Ответить | Правка | ^ к родителю #443 | Наверх | Cообщить модератору

	444. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 30-Сен-12, 19:16
	Ну и да - способ создать ext4 на рамдиске прост, как бревно (таким же способом можно создать ext4, и не только, в любом файле, и монтировать через loopback): mkdir /ramdisk mkdir /ramext4 mount -t tmpfs ramdisk /ramdisk dd if=/dev/zero of=/ramdisk/ext4 bs=по вкусу count=по вкусу mkfs.ext4 /ramdisk/ext4 (отвечаем y на предупреждение) mount -o loop /ramdisk/ext4 /ramext4 Усё.
	Ответить | Правка | ^ к родителю #442 | Наверх | Cообщить модератору

	450. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 30-Сен-12, 20:13
	>[оверквотинг удален] > (таким же способом можно создать ext4, и не только, в любом > файле, и монтировать через loopback): > mkdir /ramdisk > mkdir /ramext4 > mount -t tmpfs ramdisk /ramdisk > dd if=/dev/zero of=/ramdisk/ext4 bs=по вкусу count=по вкусу > mkfs.ext4 /ramdisk/ext4 > (отвечаем y на предупреждение) > mount -o loop /ramdisk/ext4 /ramext4 > Усё. Фс на файл лежащий на фс в памяти :-)) какой тонкий юмор :-)) лан щас заценим :-))
	Ответить | Правка | ^ к родителю #444 | Наверх | Cообщить модератору

	453. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 30-Сен-12, 21:06
	>[оверквотинг удален] > (таким же способом можно создать ext4, и не только, в любом > файле, и монтировать через loopback): > mkdir /ramdisk > mkdir /ramext4 > mount -t tmpfs ramdisk /ramdisk > dd if=/dev/zero of=/ramdisk/ext4 bs=по вкусу count=по вкусу > mkfs.ext4 /ramdisk/ext4 > (отвечаем y на предупреждение) > mount -o loop /ramdisk/ext4 /ramext4 > Усё. mount -t ramfs -omasxsize=4G ramdisk /ramdisk dd if=/dev/zero of=/ramdisk/ext4 bs=1M count=8000 Вся прелесь линуксового рам диска в том что он может легко офнуть сервер :-))
	Ответить | Правка | ^ к родителю #444 | Наверх | Cообщить модератору

	455. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 30-Сен-12, 22:00
	> Вся прелесь линуксового рам диска в том что он может легко офнуть > сервер :-)) Еще один высер, подобный тому, что выше о том, что "в Linux ext4 на рамдиске не создать". Данный высер четко и ясно означивает вашу квалификацию в целом. Таки объясните уже широкой общественности, каким образом при правильном задании предельного размера он может "офнуть сервер"?
	Ответить | Правка | ^ к родителю #453 | Наверх | Cообщить модератору

	456. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 30-Сен-12, 22:24
	> Таки объясните уже широкой общественности, Кто бы мог подумать что в линуксе фс через файл :)) > каким образом при правильном задании предельного > размера он может "офнуть сервер"? Ну и как его так задать чтоб не офнуть ? ЗЫ Уже 3 раза перегружался :-)) ЗЫЗЫ Очень радует надпись WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using При этом ZFS так не пишет :-)))))
	Ответить | Правка | ^ к родителю #455 | Наверх | Cообщить модератору

	459. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 01-Окт-12, 07:23
	> ЗЫЗЫ Очень радует надпись > WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL > WARNING! - see http://btrfs.wiki.kernel.org before using > При этом ZFS так не пишет :-))))) Есть две электрощитовых: на одной написано "опасность поражения током", на другой - нет. Суть от этого, тем не менее, не меняется.
	Ответить | Правка | ^ к родителю #456 | Наверх | Cообщить модератору

	461. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 01-Окт-12, 10:43
	> Есть две электрощитовых: на одной написано "опасность поражения током", на другой - > нет. Суть от этого, тем не менее, не меняется. Месье работает електриком в жеке? Судя по квалификации и лексикону очень может быть :-)))
	Ответить | Правка | ^ к родителю #459 | Наверх | Cообщить модератору

	462. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok) on 01-Окт-12, 13:50
	> Месье работает електриком в жеке? Судя по квалификации и лексикону очень может > быть :-))) Месье работает в операторе связи, так что и тут мимо тазика. Вообще плохо у вас все - что ни заявление, то феерический бред. Нельзя так.
	Ответить | Правка | ^ к родителю #461 | Наверх | Cообщить модератору

	457. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 30-Сен-12, 22:33
	Помнится кто то жаловался на точность df да уж /dev/loop0      6,5G   58k  5,8G   1% /mnt/fs Starting test bonnie  -s 5300m:128k -r 1800m -m btrfs Вск Сен 30 21:29:44 EEST 2012 Using uid:0, gid:0. Writing a byte at a time...done Writing intelligently...done Rewriting...Can't write block.: No space left on device Bonnie: drastic I/O error (re write(2)): No space left on device Что то этот btrfs своим поведением напоминает геом журнал ...
	Ответить | Правка | ^ к родителю #455 | Наверх | Cообщить модератору

	472. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 16:48
	> Хотел потестить ext4 и оказалось что в линуксе диск в памяти нельзя > отформатировать во что то вообще :-)) там только tmpfs ... А в чем пойнт такого тестирвоания? У вас много рамдисков в реальном использовании? Или что и кому докажет этот бенч? Вы прямо специалист по разведению сферических коней в вакууме.
	Ответить | Правка | ^ к родителю #442 | Наверх | Cообщить модератору

	474. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 01-Окт-12, 17:10
	> А в чем пойнт такого тестирвоания? У вас много рамдисков в реальном > использовании? Или что и кому докажет этот бенч? Вы прямо специалист > по разведению сферических коней в вакууме. Понт - отладка скриптов для тестирования. Несмотря на то чо электрики из жека большие специалисты по разведению сферических коней в среде вакуума что то мне подсказывает что тестирование на реальном диске со скоростью вращения шпинделя 7200 об/мин даст очень предсказуцемые результаты. И эти результаты будут легко повторимы любым другим пользователем имеющим диск со скоростью вращения шпинделя 7200 об/мин. И "фсякие форониксы" с их хитрой жопой, простите техникой для тестов которой ниукого нет, а значит повторить тесты никто не сможет, пойдут лесом стройной колонной. Месье ничего не хочет сказать про ext4? может быть в ней нужно чета включить? Чета что из каробки не включается? Потому что из коробки эта фс ведет себя как и UFS без журнала - обнуляет файлы после ресета, а значит позиционировать ее как журналируемую было бы преждевременно. Кстати о дефрагментации нужно сделать отдельный тест и запускать дефрагментатор паралельно тесту :-)) ЗЫ Слоник в домене настаивал что в убунте "фсе работает из коробки" поэтому я сомневаюсь что нужно делать тесты ext4 с какими то фичами ...
	Ответить | Правка | ^ к родителю #472 | Наверх | Cообщить модератору

	475. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok) on 01-Окт-12, 17:38
	Выше написан настолько эпический бред, что мой мозг отказывается нормально это воспринимать. ext4 на рамдиске обнуляет файлы после резета? Да-а, незадача...
	Ответить | Правка | ^ к родителю #474 | Наверх | Cообщить модератору

	476. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от nagual (ok) on 01-Окт-12, 17:41
	> Выше написан настолько эпический бред, что мой мозг отказывается нормально это воспринимать. Понимаю ... для электрика из жека это трудно. > ext4 на рамдиске обнуляет файлы после резета? Да-а, незадача... Месье не читает лора ? Какой эпический провал в образовании ...
	Ответить | Правка | ^ к родителю #475 | Наверх | Cообщить модератору

	454. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 30-Сен-12, 21:31
	> Правда что ли? Тебе надо покопаться в истории изменений UFS/FFS за последний > год что ли, чтобы увидеть обратное. Я не нанимался в древнем булшите копаться. >> Выглядит все это безобразие как-то так: http://i077.radikal.ru/1102/50/794f2fb9e84e.jpg > Ну да, Ext4 так и выглядит. Только бампер подновлён. :)) Не, это UFS всякие. Марафет вроде как-то навести попытались а основа - допотопный хлам. Тогда как в ext4 хотя-бы экстенты приделали наконец.
	Ответить | Правка | ^ к родителю #437 | Наверх | Cообщить модератору

	257. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 21:34
	>> Может и пруфлинки на тестирование Ext4 и UFS2+SJ предоставите? Не стесняйтесь. Обсудим. > http://www.phoronix.com/scan.php?page=article&item=zfs_ext4_... > Похороникс, конечно, но тесты вполне реальны. > Особенно весел тест на TPS. Ставить ТАКОЕ (UFS) на боевые серверы - > лучше сразу застрелиться. А номальные тесты есть ? фороникс нафигс.
	Ответить | Правка | ^ к родителю #221 | Наверх | Cообщить модератору

	270. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 23:18
	> А номальные тесты есть ? фороникс нафигс. Делай сам, публикуй, а мы на методику посмотрим, и оценим.
	Ответить | Правка | ^ к родителю #257 | Наверх | Cообщить модератору

	351. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 23:49
	> А номальные тесты есть ? фороникс нафигс. Сделайте лучше, если кишка не тонка. А мы будем рассуждать о том кого нафигс. p.s. а я еще 100500 постов назад сказал что они будут вопить насчет фороникса. Приятно чувствовать себя провидцем :)
	Ответить | Правка | ^ к родителю #257 | Наверх | Cообщить модератору

	427. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Сен-12, 19:33
	> Особенно весел тест на TPS. Ставить ТАКОЕ (UFS) на боевые серверы - лучше сразу застрелиться. Так потому и не ставят... :). Ну, все кроме совсем уж ушибленных фанатов.
	Ответить | Правка | ^ к родителю #221 | Наверх | Cообщить модератору

	430. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 26-Сен-12, 21:08
	>> Особенно весел тест на TPS. Ставить ТАКОЕ (UFS) на боевые серверы - лучше сразу застрелиться. > Так потому и не ставят... :). Ну, все кроме совсем уж ушибленных > фанатов. Тихо сам с собою ... левою рукою ... :-)))
	Ответить | Правка | ^ к родителю #427 | Наверх | Cообщить модератору

	255. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 21:26
	> Может и пруфлинки на тестирование Ext4 и UFS2+SJ предоставите? Не стесняйтесь. Обсудим. Надо бы потестировать, только сначала стоит обсудить методику: например диск в памяти на 1 гигабайт подойдет ?
	Ответить | Правка | ^ к родителю #217 | Наверх | Cообщить модератору

	260. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 21:51
	>> Может и пруфлинки на тестирование Ext4 и UFS2+SJ предоставите? Не стесняйтесь. Обсудим. > Надо бы потестировать, только сначала стоит обсудить методику: например диск в памяти > на 1 гигабайт подойдет ? Вполне.
	Ответить | Правка | ^ к родителю #255 | Наверх | Cообщить модератору

	267. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 22:59
	>>> Может и пруфлинки на тестирование Ext4 и UFS2+SJ предоставите? Не стесняйтесь. Обсудим. >> Надо бы потестировать, только сначала стоит обсудить методику: например диск в памяти >> на 1 гигабайт подойдет ? > Вполне. Что то мне подсказывает что не все так просто. Если в системе 2-4 гига оперы под кеш zfs то тестироватьдиск на 1 гиг ... его закеширует полностью. И сколько оперы выделить под кеш zfs и чтоб работало и чтоб не закешировало ? Или до скольки увеличить диск в памяти ?
	Ответить | Правка | ^ к родителю #260 | Наверх | Cообщить модератору

	282. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 23:41
	> Что то мне подсказывает что не все так просто. Если в системе > 2-4 гига оперы под кеш zfs то тестироватьдиск на 1 гиг > ... его закеширует полностью. И сколько оперы выделить под кеш zfs > и чтоб работало и чтоб не закешировало ? Или до скольки > увеличить диск в памяти ? Вы собрались кэшировать рамдиск? Прелестно xD
	Ответить | Правка | ^ к родителю #267 | Наверх | Cообщить модератору

	285. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 24-Сен-12, 00:04
	>> Что то мне подсказывает что не все так просто. Если в системе >> 2-4 гига оперы под кеш zfs то тестироватьдиск на 1 гиг >> ... его закеширует полностью. И сколько оперы выделить под кеш zfs >> и чтоб работало и чтоб не закешировало ? Или до скольки >> увеличить диск в памяти ? > Вы собрались кэшировать рамдиск? Прелестно xD Машина виртуалка под варей, диск в памяти обычный виртуальный диск на диске хоста, но у хоста памяти много и он закешипуется. Не ?
	Ответить | Правка | ^ к родителю #282 | Наверх | Cообщить модератору

	287. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Сен-12, 00:10
	> Машина виртуалка под варей, диск в памяти обычный виртуальный диск на диске > хоста, но у хоста памяти много и он закешипуется. Не ? Стоп-стоп-стоп. О какой варе речь? ESXi? Она не кеширует. Надо чтобы объем диска хотя бы в 8-10 раз превышал объём кеша контроллера + гостевой FS. Если у хоста есть кеш - значит еще и его учесть.
	Ответить | Правка | ^ к родителю #285 | Наверх | Cообщить модератору

	288. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 24-Сен-12, 00:14
	>> Машина виртуалка под варей, диск в памяти обычный виртуальный диск на диске >> хоста, но у хоста памяти много и он закешипуется. Не ? > Стоп-стоп-стоп. О какой варе речь? ESXi? Она не кеширует. Надо чтобы объем > диска хотя бы в 8-10 раз превышал объём кеша контроллера + > гостевой FS. Если у хоста есть кеш - значит еще и > его учесть. Это Workstation 9 под вин. Что то мне подсказывает что дисковые операции кешируются всей свободной памятью. Не ?
	Ответить | Правка | ^ к родителю #287 | Наверх | Cообщить модератору

	352. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 23:50
	> Вы собрались кэшировать рамдиск? Прелестно xD Вау, это самый сферический конь в наиболее чистом вакууме из того что я видел :)
	Ответить | Правка | ^ к родителю #282 | Наверх | Cообщить модератору

	421. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Сен-12, 17:16
	> Вполне. ... в случае если вы - iZEN.
	Ответить | Правка | ^ к родителю #260 | Наверх | Cообщить модератору

	271. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 23:19
	>> Может и пруфлинки на тестирование Ext4 и UFS2+SJ предоставите? Не стесняйтесь. Обсудим. > Надо бы потестировать, только сначала стоит обсудить методику: например диск в памяти > на 1 гигабайт подойдет ? Предлагаю обычный SATA HDD, раздел гигов на 50-60, объем памяти на тестовой машине - не более 1 Гб.
	Ответить | Правка | ^ к родителю #255 | Наверх | Cообщить модератору

	280. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 23:38
	>>> Может и пруфлинки на тестирование Ext4 и UFS2+SJ предоставите? Не стесняйтесь. Обсудим. >> Надо бы потестировать, только сначала стоит обсудить методику: например диск в памяти >> на 1 гигабайт подойдет ? > Предлагаю обычный SATA HDD, раздел гигов на 50-60, объем памяти на тестовой > машине - не более 1 Гб. Это будут тесты диска а не фс и расхождения между фс уложатся в погрешность.
	Ответить | Правка | ^ к родителю #271 | Наверх | Cообщить модератору

	281. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 23:40
	> Это будут тесты диска а не фс и расхождения между фс уложатся > в погрешность. Да нет - это как раз и будет реальный тест, а не сферические кони в вакууме. Задача ФС - корректно разложить метаданные и данные по серьёзно физически лимитированному носителю (скорость, время доступа, время поиска). То, как она с этим справляется - как раз и показатель.
	Ответить | Правка | ^ к родителю #280 | Наверх | Cообщить модератору

	296. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Elhana (ok) on 24-Сен-12, 03:07
	И чем все ваши тесты на рамдиске будут лучше фороникса, которые ZFS сравнивают с ext4 на одном единственном диске?
	Ответить | Правка | ^ к родителю #281 | Наверх | Cообщить модератору

	311. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 24-Сен-12, 10:21
	> И чем все ваши тесты на рамдиске будут лучше фороникса, которые ZFS > сравнивают с ext4 на одном единственном диске? Мы же обсуждаем методику тестирования или нет ? 5 дисков по 1 гигу хватит ?
	Ответить | Правка | ^ к родителю #296 | Наверх | Cообщить модератору

	353. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 23:51
	> 5 дисков по 1 гигу хватит ? Фороникс и то более реалистичные конфигурации берет. Вот скажите, сколько у вас серверов с диском на гиг? :)
	Ответить | Правка | ^ к родителю #311 | Наверх | Cообщить модератору

	361. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 25-Сен-12, 00:16
	>> 5 дисков по 1 гигу хватит ? > Фороникс и то более реалистичные конфигурации берет. Вот скажите, сколько у вас > серверов с диском на гиг? :) К сожелению нету дисков для проверки хотябы raidz есть 2 по 320.
	Ответить | Правка | ^ к родителю #353 | Наверх | Cообщить модератору

	411. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Сен-12, 14:21
	> Это будут тесты диска а не фс и расхождения между фс уложатся > в погрешность. Это будет реальный тест реальной ФС на реальном диске. В погрешность не уложатся при разных ворклоадах. Фороникс кстати наглядно демонстрирует. Хоть его и ругают, но в целом у них тесты как тесты. Не все из них реалистичные. Подсказываю: ФС не будут равноценны при: 1) Создании множества файлов/каталогов. 2) Множественном параллельном доступе. 3) Чтение-запись блоками разного размера. 4) Синхронные или асинхронные операции. 5) Операции с СУБД с собственным журналом могут работать круто по разному в зависимости от реализации журнальной логики ФС. ...
	Ответить | Правка | ^ к родителю #280 | Наверх | Cообщить модератору

	412. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 26-Сен-12, 15:24
	>[оверквотинг удален] > ругают, но в целом у них тесты как тесты. Не все > из них реалистичные. > Подсказываю: ФС не будут равноценны при: > 1) Создании множества файлов/каталогов. > 2) Множественном параллельном доступе. > 3) Чтение-запись блоками разного размера. > 4) Синхронные или асинхронные операции. > 5) Операции с СУБД с собственным журналом могут работать круто по разному > в зависимости от реализации журнальной логики ФС. > ... Если разница тестирования дисковых операций с двумя различными фс будет отличаться по времени на 1-2% то это уложится в погрешность измерений. Следовательно для тестирования больше подходят быстрые SSD диски нежели HDD. Что касается диска в памяти, то очень спорно. Кроме того средства тестирования должны присутствовать во всех тестируемых ос. Например многие "пРоФФэсоры" высказываются неодобрительно о том же dd, зато он есть почти везде. Итак если мы говорим о dd какие bc и count будут оптимальны для тестирования ?
	Ответить | Правка | ^ к родителю #411 | Наверх | Cообщить модератору

	417. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Сен-12, 17:04
	> Если разница тестирования дисковых операций с двумя различными фс будет отличаться по > времени на 1-2% то это уложится в погрешность измерений. А она будет местами отличаться не на 1-2% а в пару раз. А то и поболее. Просто потому что в силу разного дизайна ФС, разным дизайнам удобны разные наборы операций. > Следовательно для тестирования больше подходят быстрые SSD диски нежели HDD. Неверно. ФС претендующая на универсальность должна уметь работать и с теми и с другими. Хотя это не значит что там не может быть специальных оптимизаций для тех или иных носителей. На практике современный подход как раз сигналить ФС о том что это у нас SSD и тогда она юзает иной набор оптимизаций + TRIM. Вроде бы логично все. Разным по свойствам носителям - разные оптимизации и твики. > во всех тестируемых ос. Например многие "пРоФФэсоры" высказываются неодобрительно о том > же dd, зато он есть почти везде. Итак если мы говорим > о dd какие bc и count будут оптимальны для тестирования ? В моем понимании, если мы хотим потестировать ФС а не крутизну кеша - размер данных должен быть заведомо много больше кэша, чтобы посмотреть что может ФС. Что может кэш я и так себе представляю. Вот только в него вся ФС не влезет (иначе это уже RAM-диск) и потому интересно и поведение ФС самой по себе. Как бы bs и count будут варьироваться в зависимости от доступной под кэш памяти. Более того, bs в принципе может влиять на производительность дисковой подсистемы. Обычно крупные блоки отрабатываются лучше чем мелкие (до некоторого предела). Способность работать с неудобными сценариями когда программы читают/пишут мелкими блоками - тоже параметр ФС. А кто сказал что программы всегда оперируют большими блоками? Например логи дописываются мелкими порциями. Но это только 1 из тестов. Самый простой и дубовый - на линейные операции в 1 поток. А как насчет интенсивной работы с метаданными? Время создания разлапистой структуры каталогов и файлов - это тоже интересный параметр. Когда распаковываается нечто типа тарбола с ядром производительность ФС в таких случаях сыграет не последнюю роль. А как насчет многопоточного доступа? Современные ОС многозадачные и доступ сразу кучи программ к диску ничему не противоречит. Насколько ОС, ее кеш и ФС смогут облегчить участь диска, особенно механического? Некоторые программы могут запросить небуферизованный "прямой доступ". В этом случае кэш не имеет права подыгрывать. Скорость работы ФС в таком режиме - тоже интересна. Просто потому что некая программа может лучше чем ОС и системный кэш знать что и как кешировать. Есть тесты нагружающие логику журналирования - синхронизируемая запись. Т.е. записи файлов сдабриваемые вызовами типа fsync(). Актуально для БД и прочих. Реализация оного может влиять на скорость работы БД. Кстати если кто хочет подъ... btrfs - вот тут это может получиться.
	Ответить | Правка | ^ к родителю #412 | Наверх | Cообщить модератору

	422. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 26-Сен-12, 17:18
	> А она будет местами отличаться не на 1-2% а в пару раз. Медицина бессильна, клиент недоступен. > Неверно. ФС претендующая на универсальность должна уметь работать и с теми и > с другими. Месье потрудится назвать такую фс которая неработает с одним из ... ? >[оверквотинг удален] > программ к диску ничему не противоречит. Насколько ОС, ее кеш и > ФС смогут облегчить участь диска, особенно механического? > Некоторые программы могут запросить небуферизованный "прямой доступ". В этом случае кэш > не имеет права подыгрывать. Скорость работы ФС в таком режиме - > тоже интересна. Просто потому что некая программа может лучше чем ОС > и системный кэш знать что и как кешировать. > Есть тесты нагружающие логику журналирования - синхронизируемая запись. Т.е. записи файлов > сдабриваемые вызовами типа fsync(). Актуально для БД и прочих. Реализация оного > может влиять на скорость работы БД. Кстати если кто хочет подъ... > btrfs - вот тут это может получиться. Если месье затрудняется написать оптимальные для теста bs и count пусть хоть на пальцах покажет :-))))))
	Ответить | Правка | ^ к родителю #417 | Наверх | Cообщить модератору

	435. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 27-Сен-12, 15:54
	> Медицина бессильна, клиент недоступен. Я в этом не виноват. Да, файловые системы не очень простая штука, мозг может вынести слегка. > Месье потрудится назвать такую фс которая неработает с одним из ... ? 1) Не с глаголами пишется раздельно. 2) Где тут граммар-наци, когда они так нужны? 3) Работать можно по разному. Запорожец тоже автомобиль и тоже ездит. Но довольно медленно. И громко тарахтит. И комфорт в салоне так себе. И нормы евро-4 по выхлопам не осилит. За что-то такое ими почти не пользуются уже. Вот эти ващи UFS - такие же древности в плане технологий файловых систем. И никакие твики и тюнинги по мелочи древний в целом дизайн не вытянут на достойный современный уровень быстродействия. > Если месье затрудняется написать оптимальные для теста bs и count пусть хоть > на пальцах покажет :-)))))) Мсье не затрудняется, мсье не совсем понимает что хочется протестировать. Максимально линейную запись большого файла на чистую ФС и потом его чтение? Тогда bs побольше (если нет цели потестировать как ФС переваривает работу с мелкими запросами) и count такой чтобы объем был много больще чем объем кэша в оперативке. Правда при этом в основном протестируется производительность диска если он не забит.  Например, bs=1M и count=100500 явно удовлетворит этому условию. Правда ждать долговато придется (около 100Гб все-таки) и вообще тест сильно нишевой. С другой стороны, работа с большими линейными файлами имеет право на жизнь и вполне встречается. Например, видеомонтаж. Тут всех натянет XFS если ему многодисковую конфигу дать - он как раз на такое оптимизирован.
	Ответить | Правка | ^ к родителю #422 | Наверх | Cообщить модератору

	438. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 28-Сен-12, 12:35
	> Вот эти ващи UFS - такие же > древности в плане технологий файловых систем. И никакие твики и тюнинги > по мелочи древний в целом дизайн не вытянут на достойный современный > уровень быстродействия. Зачем пустопорожние разговоры вести — возьми и затести. У UFS2 новый "твик" появился: максимальный размер блока ФС увеличен до 64k. > Тут > всех натянет XFS если ему многодисковую конфигу дать - он как > раз на такое оптимизирован. Опять пустопорожние ничем необоснованные предположения. А вот если бы у ZFS задать размер блока до 1M, да отключить нафик чексуммирование (zfs set checksum=off poolname/fsname — ну это чтобы она работала наравне с классическими ФС без проверки на лету файлов), то что будет?! Представить трашшшшно, как сольют ей новомодные Ext4 и Btrfs, не говоря уж о старушенции XFS. Ж)
	Ответить | Правка | ^ к родителю #435 | Наверх | Cообщить модератору

	439. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 28-Сен-12, 13:06
	> Опять пустопорожние ничем необоснованные предположения. А вот если бы у ZFS задать > размер блока до 1M, да отключить нафик чексуммирование (zfs set checksum=off > poolname/fsname — ну это чтобы она работала наравне с классическими ФС > без проверки на лету файлов), то что будет?! Представить трашшшшно, как > сольют ей новомодные Ext4 и Btrfs, не говоря уж о старушенции > XFS. Ж) На рандомной записи сольют - CoW линеаризует запись. Но зато читать потом будет страшновато.
	Ответить | Правка | ^ к родителю #438 | Наверх | Cообщить модератору

	304. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 07:09
	> Может и пруфлинки на тестирование Ext4 и UFS2+SJ предоставите? Не стесняйтесь. Обсудим. Да вон какой-нибудь фороникс регулярно делают. А бздунишки регулярно вопят что все не так, подстроено врагами и вообще фороникс - аццтой!!!111 >> По крайней мере, в нем доперли сделать экстенты наконец. А в UFS - их нет. > UFS2 работает на уровне фрагментов блоков. А в Ext* такого нет, а > значит теряется свободное пространство на мелких файлах — блоки заполнены не > до конца, а распределить незаполненные "хвосты" эта ФС не в силах. :p Ишь как красиво стрелки перевел. Ему про то что блочный аллокатор тормоз, а он втирает про экономию места. Вот только при чем тут она? Несомненно, запорожец занимает меньше места на парковке чем самосвал, только вот что из этого следует? :)
	Ответить | Правка | ^ к родителю #217 | Наверх | Cообщить модератору

	253. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от nagual (ok) on 23-Сен-12, 21:20
	>> Если бы месье вылез из криокамеры он бы написал UFS+J или хотябы >> UFS+S на вскидку отставание лет на 10-12 :-))) > А какая разница? КрЮтые разработчики BSD заявили что на капитальную переделку этого > - ресурсов нет. Так что к запору примотали "скамейку" проволокой, кой-как > привинтили колеса от мерса и наклеили наклейки SPARCO. Типа, заапгрейдили. Правда, > аэродинамика лучше не стала, да и двигатель - тоже. Поэтому быстрее > ездить и меньше тарахтеть оно не стало. Вот UFS-хоть-там-плюс-что отличается редкостной > тормознутостью. Достаточно любой бенч на одинаковом оборудовании запустить. И да, EXT4 > порвет этот античный хлам как тузик грелку. По крайней мере, в > нем доперли сделать экстенты наконец. А в UFS - их нет. А давайте сначала исключим из тестирования фс которые приводят к эпик фейлам - например ext4 :-)) потому как лучше чуть медленне ехать чем развалиться на ходу, не ?
	Ответить | Правка | ^ к родителю #214 | Наверх | Cообщить модератору

	266. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 22:59
	> А давайте сначала исключим из тестирования фс которые приводят к эпик фейлам > - например ext4 :-)) потому как лучше чуть медленне ехать чем > развалиться на ходу, не ? У кого, простите, приводят? У криворучек? Два года боевой эксплуатации БЕЗ каких-либо твиков, никаких граблей не замечено.
	Ответить | Правка | ^ к родителю #253 | Наверх | Cообщить модератору

	305. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от Аноним (??) on 24-Сен-12, 07:11
	> А давайте сначала исключим из тестирования фс которые приводят к эпик фейлам Давайте лучше исключим из тестов ж@поруких экспериментаторов. А то юзаю EXT4 со времен 2.6.32 и проблем с ней - ноль. Питание слетало, etc. А виртуалки кстати не показатель. Там могли для скорости сделать фэйковый sync, который не сливает реально данные на диск. При слете питания файловая система с журналом при таком подходе крупно обломается, понадеявшись на валидность журнала и то что синхронные операции реально синхронные. Но это следствие обмана с синхронными операциями, а не кривости ФС.
	Ответить | Правка | ^ к родителю #253 | Наверх | Cообщить модератору

	310. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Сен-12, 07:51
	> А виртуалки кстати не показатель. Там могли для скорости сделать фэйковый sync, > который не сливает реально данные на диск. При слете питания файловая > система с журналом при таком подходе крупно обломается, понадеявшись на валидность > журнала и то что синхронные операции реально синхронные. Но это следствие > обмана с синхронными операциями, а не кривости ФС. Да, легко. В ESXi с этим порядок, тьфу-тьфу, и write barrier работает, как надо.
	Ответить | Правка | ^ к родителю #305 | Наверх | Cообщить модератору

	317. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 24-Сен-12, 11:29
	>> А виртуалки кстати не показатель. Там могли для скорости сделать фэйковый sync, >> который не сливает реально данные на диск. При слете питания файловая >> система с журналом при таком подходе крупно обломается, понадеявшись на валидность >> журнала и то что синхронные операции реально синхронные. Но это следствие >> обмана с синхронными операциями, а не кривости ФС. > Да, легко. > В ESXi с этим порядок, тьфу-тьфу, и write barrier работает, как надо. То был KVM.
	Ответить | Правка | ^ к родителю #310 | Наверх | Cообщить модератору

	418. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Сен-12, 17:07
	> Да, легко. Ну так я потому и уточняю что не уверен что квалификация оппонента позволяет отловить такой случай и осознать кому именно приписать былинный отказ. Хостер вполне мог пожертвовать надежностью в пользу скорости, дабы оверселлить побольше, etc.
	Ответить | Правка | ^ к родителю #310 | Наверх | Cообщить модератору

	315. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 24-Сен-12, 11:24
	>> А давайте сначала исключим из тестирования фс которые приводят к эпик фейлам > Давайте лучше исключим из тестов ж@поруких экспериментаторов. Так вы поэтому тесты не делаете ?
	Ответить | Правка | ^ к родителю #305 | Наверх | Cообщить модератору

	414. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Сен-12, 16:38
	> Так вы поэтому тесты не делаете ? Скорее, потому что 1) Дико лень копаться с *bsd в связи с бессмысленностью этого занятия. 2) Реалистичные тесты требуют неиллюзорных затрат времени и специально выделенное для этого оборудование. В форониксе например его создатель работает над своим сайтом в режиме полного дня.
	Ответить | Правка | ^ к родителю #315 | Наверх | Cообщить модератору

	419. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 26-Сен-12, 17:09
	> 1) Дико лень копаться с *bsd в связи с бессмысленностью этого занятия. Сделайте хотябы для своего горяче любимого linux-а > 2) Реалистичные тесты требуют неиллюзорных затрат времени и специально выделенное для этого > оборудование. Найдем уж как нибудь. :-))
	Ответить | Правка | ^ к родителю #414 | Наверх | Cообщить модератору

	413. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 26-Сен-12, 15:34
	>> А давайте сначала исключим из тестирования фс которые приводят к эпик фейлам > Давайте лучше исключим из тестов ж@поруких экспериментаторов. Судя по тому как вы нехотите ничего тестироваь себя вы вычеркнули первым ... :)))
	Ответить | Правка | ^ к родителю #305 | Наверх | Cообщить модератору

	416. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Сен-12, 16:41
	Эк вас ж@порукость то зацепила, аж 2 раза откоментили. Вы уж извините но на основе ваших постов мне уже многое ясно о вашей квалификации. Поэтому я могу понять почему вас так зацепило.
	Ответить | Правка | ^ к родителю #413 | Наверх | Cообщить модератору

	110. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Сен-12, 06:02
	> Вот когда будет годный btrfsck, тогда и приходите. Он уже есть. Не полный, но - есть. А в zfs его попросту нет как класса. И не надо на scrub кивать, оно в btrfs фиг знает сколько есть, только fsck - немного о другом.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	135. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 22-Сен-12, 22:01
	>> Вот когда будет годный btrfsck, тогда и приходите. > Он уже есть. Не полный, но - есть. А в zfs его > попросту нет как класса. И не надо на scrub кивать, оно > в btrfs фиг знает сколько есть, только fsck - немного о > другом. Не понимаю, чем так убог zpool scrub (при работающей отмотке пула zpool import -F, конечно же) и хуже "немного другого" fsck? + zpool scrub лечит восстановимые метаданные и данные в пуле, насколько это возможно. Ни при каких обстоятельствах не уничтожает данные, подтвердившие свою целостность; + zpool scrub выводит полный список невосстановимых файлов в пуле. - fsck лечит все ошибки ФС на уровне блоков, приводя её в рабочее состояние. ФС после обработки fsck вполне может быть девственно-чистой, без находящихся на ней файлов; - fsck "лечит" файлы, собирая найденные цепочки блоков и создавая новые файлы из них в каталоге /.lost+found с незначащими именами из идентификаторов — разбирайтесь сами, КАКИЕ_ИМЕННО файлы потеряны. "Огрызки" предоставлены. :))
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	136. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 22-Сен-12, 23:28
	> - fsck "лечит" файлы, собирая найденные цепочки блоков и создавая новые файлы > из них в каталоге /.lost+found с незначащими именами из идентификаторов — > разбирайтесь сами, КАКИЕ_ИМЕННО файлы потеряны. "Огрызки" предоставлены. :)) В связи с этим нулячие диски перед форматированием имеет смысл забить нулями :-)) Будет легче с огрызками.
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	138. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 23-Сен-12, 01:46
	>> - fsck "лечит" файлы, собирая найденные цепочки блоков и создавая новые файлы >> из них в каталоге /.lost+found с незначащими именами из идентификаторов — >> разбирайтесь сами, КАКИЕ_ИМЕННО файлы потеряны. "Огрызки" предоставлены. :)) > В связи с этим нулячие диски перед форматированием имеет смысл забить нулями > :-)) Будет легче с огрызками. Удалённые нормальным образом файлы сводят на нет предварительное забитие нулями пространства ФС. Ах, да, ещё fsck сканирует весь объём ФС независимо от того, какой суммарный размер полезной информации; требуется демонтировать проверяемую ФС для исправлений найденных ошибок (исключение — XFS и UFS2). zpool scrub проверяет только занятое пространство и работает фоновым процессом.
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	148. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 09:56
	>>> zpool scrub проверяет только занятое пространство и работает фоновым процессом. И вот это - хуже всего. Непредсказуемые фоновые процессы на, допустим, database workload - за них опять же надо руки отрывать.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	146. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 09:54
	> В связи с этим нулячие диски перед форматированием имеет смысл забить нулями > :-)) Будет легче с огрызками. На коровах бесполезно.
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	145. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 09:53
	> + zpool scrub лечит восстановимые метаданные и данные в пуле, насколько это > + zpool scrub выводит полный список невосстановимых файлов в пуле. --- если том не смонтировался или упал в корку при монтировании - про "лечит" и "выводит" можно забывать. а це бывает. хотя сие только для сердитых ноутоводов, на серверах проще поднять бэкап
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	154. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 11:11
	>> + zpool scrub лечит восстановимые метаданные и данные в пуле, насколько это >> + zpool scrub выводит полный список невосстановимых файлов в пуле. > --- если том не смонтировался или упал в корку при монтировании - > про "лечит" и "выводит" можно забывать. а це бывает. хотя сие > только для сердитых ноутоводов, на серверах проще поднять бэкап Потрудитесь ссылку.
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	215. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Сен-12, 19:23
	> Потрудитесь ссылку. Ссылку на что? На здравый смысл? Это пять! :)
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	254. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 21:21
	>> Потрудитесь ссылку. > Ссылку на что? На здравый смысл? Это пять! :) Сыылку на корку.
	Ответить | Правка | ^ к родителю #215 | Наверх | Cообщить модератору

	268. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 23:11
	> Сыылку на корку. В гугле забанили? http://forums.freenas.org/showthread.php?7684-ZFS-Kernel-Panic - трупик http://forums.freenas.org/showthread.php?5645-Trying-to-moun... - трупик https://www.illumos.org/issues/2233 - висяк с ребутами https://forums.oracle.com/forums/thread.jspa?messageID=10258853 - тот же баг, что и выше, но у другого человека http://forums.freebsd.org/showthread.php?t=31858 - опенсолярка как-то разрулила косяк, но тем не менее - грабли эпичны http://onlyfriends.name/2011/05/zharennyiy-zfs/ - ацки надежная FS, падающая в корку при чтении файлов с поврежденного тома http://comments.gmane.org/gmane.os.freebsd.devel.file-system... - падающий scrub http://markmail.org/thread/aqf24ykbp2h7ct4n - то же самое, отсутствие fsck доставляет Надо сказать, за отсутствием fsck - шансов кроме как ковырять диск руками - никаких.
	Ответить | Правка | ^ к родителю #254 | Наверх | Cообщить модератору

	274. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 23:33
	>[оверквотинг удален] > и выше, но у другого человека > http://forums.freebsd.org/showthread.php?t=31858 - опенсолярка как-то разрулила косяк, > но тем не менее - грабли эпичны > http://onlyfriends.name/2011/05/zharennyiy-zfs/ - ацки надежная FS, падающая в корку > при чтении файлов с поврежденного тома > http://comments.gmane.org/gmane.os.freebsd.devel.file-system... - падающий > scrub > http://markmail.org/thread/aqf24ykbp2h7ct4n - то же самое, отсутствие fsck доставляет > Надо сказать, за отсутствием fsck - шансов кроме как ковырять диск руками > - никаких. Ссылки старые, в большинстве случаев не  v28 ... в одном случае битое железо ... собаки лают, караван идет.
	Ответить | Правка | ^ к родителю #268 | Наверх | Cообщить модератору

	275. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 23:34
	> Ссылки старые, в большинстве случаев не  v28 ... в одном случае > битое железо ... собаки лают, караван идет. Да, пусть идёт. Мне-то чего? Я это в продакшне не юзаю, и не планирую.
	Ответить | Правка | ^ к родителю #274 | Наверх | Cообщить модератору

	276. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 23-Сен-12, 23:34
	> Надо сказать, за отсутствием fsck - шансов кроме как ковырять диск руками > - никаких. Что то мне присутсвие fsck в ext4 не сильно помогло.
	Ответить | Правка | ^ к родителю #268 | Наверх | Cообщить модератору

	277. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Сен-12, 23:35
	>> Надо сказать, за отсутствием fsck - шансов кроме как ковырять диск руками >> - никаких. > Что то мне присутсвие fsck в ext4 не сильно помогло. Руки, уважаемый, руки. У меня даже в fsck необходимость возникала всего пару раз - после авралов с питанием там, где нет нормального контроллера и UPS'а. В остальных случаях штатный откат журнала - всё, что требовалось.
	Ответить | Правка | ^ к родителю #276 | Наверх | Cообщить модератору

	306. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 07:14
	> Руки, уважаемый, руки. Судя по упоминанию виртуалок - там могла быть читерская реализация синхронной записи на виртуальный диск, например. Хотя маловато сведений, так, один из вариантов.
	Ответить | Правка | ^ к родителю #277 | Наверх | Cообщить модератору

	355. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 23:53
	> Что то мне присутсвие fsck в ext4 не сильно помогло. Зато помогло мне, когда я отколупал с битого диска (реально осыпающегося, с бэдами).
	Ответить | Правка | ^ к родителю #276 | Наверх | Cообщить модератору

	289. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 24-Сен-12, 00:21
	>> Сыылку на корку. > В гугле забанили? > http://forums.freenas.org/showthread.php?7684-ZFS-Kernel-Panic - трупик "zpool import -f HubZ2" — насильное импортирование пула. Узнай сам, чем это отличается от "zpool import -F". > http://forums.freenas.org/showthread.php?5645-Trying-to-moun... > - трупик Аналогично. > https://www.illumos.org/issues/2233 - висяк с ребутами > https://forums.oracle.com/forums/thread.jspa?messageID=10258853 - тот же баг, что > и выше, но у другого человека Тут да, косяк, но не смертельный. Висяк — не смертяк. У меня rm на заполненном пуле полчаса может удалять каталог с файлами суммарным размером 5ГБ. Вроде работает, а место свободное не так быстро появляется... > http://forums.freebsd.org/showthread.php?t=31858 - опенсолярка как-то разрулила косяк, > но тем не менее - грабли эпичны Грабли на FreeBSD 8.1, довольно устаревшей системе. С тех пор много патчей для ZFS принято в дерево системы. > http://onlyfriends.name/2011/05/zharennyiy-zfs/ - ацки надежная FS, падающая в корку > при чтении файлов с поврежденного тома "в итоге абсолютно все необходимые данные были успешно спасены" — УСПЕХ. > http://comments.gmane.org/gmane.os.freebsd.devel.file-system... - падающий > scrub "9.1-BETA1 FreeBSD 9.1-BETA1 #34: Thu Jul 12 05:57:44 EDT 2012 amd64 4GB of ram, 4gb of swap. panic: integer divide fault GNU gdb 6.1.1 [FreeBSD]" — почему я не удивляюсь? > http://markmail.org/thread/aqf24ykbp2h7ct4n - то же самое, отсутствие fsck доставляет Тогда и не было команды отмотки пула "zpool import -F", поэтому и доставляло. > Надо сказать, за отсутствием fsck - шансов кроме как ковырять диск руками - никаких. Открой для себя новые возможности ZFSv28 ("zpool import -F") и перестань ныть, что нет fsck.
	Ответить | Правка | ^ к родителю #268 | Наверх | Cообщить модератору

	356. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Сен-12, 23:54
	> rm на заполненном пуле полчаса может удалять каталог с файлами суммарным > размером 5ГБ. Вроде работает, а место свободное не так быстро появляется... Ага, так и запишем: +1 признак п-ца с фрагментацией.
	Ответить | Правка | ^ к родителю #289 | Наверх | Cообщить модератору

	358. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 25-Сен-12, 00:02
	>> rm на заполненном пуле полчаса может удалять каталог с файлами суммарным >> размером 5ГБ. Вроде работает, а место свободное не так быстро появляется... > Ага, так и запишем: +1 признак п-ца с фрагментацией. Для пущей эротичности предлагается сразу после такого rm чего-нибудь на диск пописать :)
	Ответить | Правка | ^ к родителю #356 | Наверх | Cообщить модератору

	415. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Сен-12, 16:39
	> Сыылку на корку. В список рассылки nginx суньтесь - там этого есть.
	Ответить | Правка | ^ к родителю #254 | Наверх | Cообщить модератору

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

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