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

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

"FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
Сообщение от opennews on 26-Сен-11, 21:38
Организация FreeBSD Foundation объявила (http://freebsdfoundation.blogspot.com/) о выделении денежных грантов на развитие двух (http://freebsdfoundation.blogspot.com/2011/09/diffuse-for-fr...) проектов (http://freebsdfoundation.blogspot.com/2011/09/implementing-x...): -  В октябре планируется (http://freebsdfoundation.blogspot.com/2011/09/diffuse-for-fr...) довести до готовности к интеграции с деревом исходных текстов FreeBSD проекта DIFFUSE (http://caia.swin.edu.au/urp/diffuse/) (DIstributed Firewall and Flow-shaper Using Statistical Evidence), добавляющего в пакетный фильтр IPFW функции классификации трафика на основании статистических параметров потоков данных, отслеживаемых в режиме реального времени на одном или нескольких узлах.  Иными словами, для классификации трафика DIFFUSE оперирует не параметрами в заголовках пакетов и не анализом содержимого передаваемых в пакетах данных, а статистическими характеристиками потока, свойственными определенным... URL: http://freebsdfoundation.blogspot.com/2011/09/diffuse-for-fr... Новость: http://www.opennet.dev/opennews/art.shtml?num=31857
Ответить | Правка | Cообщить модератору

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

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

1. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+17 +/–
Сообщение от Зловред on 26-Сен-11, 21:38
> Переход на новый C++ стек ожидается во FreeBSD 10. Реквестую название FreeBSD X =)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+6 +/–
	Сообщение от Аноним (??) on 26-Сен-11, 22:08
	> Реквестую название FreeBSD X =) FreeBSD OS X (c) 1993-2011 Apple Inc :)
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	14. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	–3 +/–
	Сообщение от Аноним (??) on 26-Сен-11, 23:19
	> Реквестую название FreeBSD X =) Патентные иски от эппла - в нагрузку?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	20. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 26-Сен-11, 23:58
	> Патентные иски от эппла - в нагрузку? Зачем им рубить сук, на котором они сидят? "Правильно, Леня, мы - партнеры!" (с) АО МММ
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	42. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от kombat (ok) on 27-Сен-11, 05:06
	"Леня, ты халявщик!" такое тоже было)))
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	53. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	–1 +/–
	Сообщение от СуперАноним on 27-Сен-11, 08:04
	Apple активный партнёр, FreeBSD пассивный.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	48. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Ян Злобин (ok) on 27-Сен-11, 07:44
	> Патентные иски от эппла - в нагрузку? Ага, патенты на цифры.  Глупости-то уж не надо. :-)
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	52. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	–1 +/–
	Сообщение от Аноним (??) on 27-Сен-11, 08:00
	Все еще впереди. Уже существуют запрещенные числа, за публикацию которых копирасты преследуют. Одно из таких чисел представляет собой Perl-код программы для взлома защиты DVD (decss)
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	62. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+1 +/–
	Сообщение от anonymous (??) on 27-Сен-11, 12:06
	не "перл-код", а ключ, невежда.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	76. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+1 +/–
	Сообщение от Александр (??) on 27-Сен-11, 16:57
	Пусть подадут в суд на Mitsubishi - во смеху-то будет...
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	78. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 17:06
	> Пусть подадут в суд на Mitsubishi - во смеху-то будет... На Тошибу :). Чтобы окончательно сорвать себе поставки DRAM и NAND.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	91. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 18:17
	Чувак вообще не в теме, лол
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

2. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+1 +/–
Сообщение от Аноним (??) on 26-Сен-11, 21:39
Такими темпами FreeBSD станет карманным проектом Эппла.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+1 +/–
	Сообщение от VKraft on 26-Сен-11, 21:45
	а оно и было таковым
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	15. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 26-Сен-11, 23:23
	> а оно и было таковым Одного угробленного дарвина им мало?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	46. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от анонимус (??) on 27-Сен-11, 06:39
	угробленного?:D
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	69. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 12:56
	> угробленного?:D Да, открытый вариант оного практически сдох - комьюнити разработчиков нету.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	119. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Клыкастый (ok) on 27-Сен-11, 23:02
	обоснуйте
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	4. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 26-Сен-11, 21:51
	Насчет DIFFUSE - похоже, все-таки торчат уши Жунипера, яблоку эта тематика не особо интересна.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	92. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 18:22
	По ссылке ходить пробовали? :) This project began in June 2010 and has been made possible in part by a grant from the Cisco University Research Program Fund at Community Foundation Silicon Valley for a project titled "Exploring the efficacy of distributed statistical traffic classification using modified open source packet filters".
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	5. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+2 +/–
	Сообщение от Аноним (??) on 26-Сен-11, 22:01
	>Такими темпами FreeBSD станет карманным проектом Эппла. Некоторые компании используют двойную систему распространения своего ПО: открытая бесплатная community-версия, и закрытая платная enterprise-версия, отличающаяся добавлением вкусных фич. Очевидно, что BSD-like лицензия для такой задачи более удобна, чем копилефт (достаточно взглянуть, как мучается оракл с мускулом). Возможно, основной шанс на выживание FreeBSD в будущем - вступление в подобный симбиоз с Mac OS X. В конечном счете, уже сейчас этими проектами рулят одни и те же люди.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	12. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+3 +/–
	Сообщение от predator (ok) on 26-Сен-11, 22:44
	> уже сейчас этими проектами рулят одни и те же люди кто например?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	17. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 26-Сен-11, 23:25
	> Очевидно, что BSD-like лицензия для такой задачи более удобна, чем > копилефт (достаточно взглянуть, как мучается оракл с мускулом). Удобна? Смотря для кого. Уж явно не для тех кто внедрит а потом ему и скажут - опаньки, товарищ, а все вкусные плюшки теперь будут только в энтерпрайз версии - готовь кошелек.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	19. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 26-Сен-11, 23:57
	На мой взгляд, вполне справедливый метод заработка. За роскошь надо платить.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	40. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+2 +/–
	Сообщение от runoverheads (ok) on 27-Сен-11, 02:48
	За свою роскошь менеджеры корпорация платят из вашего кармана, а программерам копейки.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	63. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от anonymous (??) on 27-Сен-11, 12:10
	> На мой взгляд, вполне справедливый метод заработка. За роскошь надо платить. конечно. «пилите, Шура, пилите — они золотые». при такой модели надо как минимум каждому, чей код был принят в основную ветку, давать пожизненную неограниченую лицензию на коммерческие версии. все, в том числе и будущие. или не брать чужих коммитов вообще — и не называть проект открытым. ну, и получить в итоге форк, если проект востребован.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	79. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 17:08
	> На мой взгляд, вполне справедливый метод заработка. За роскошь надо платить. А потом эти господа еще и удивояются кога яндексы и рамблеры выдают характерные новости.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	83. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 17:22
	> На мой взгляд, вполне справедливый метод заработка. За роскошь надо платить. Ага, а вся команда ядерщиков на всю толпу кой-как наскребает 200к в год, едва сводя концы с концами. Социальная справедливость по мнению манагеров, чо.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	21. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от iZEN (ok) on 27-Сен-11, 00:15
	>> Очевидно, что BSD-like лицензия для такой задачи более удобна, чем >> копилефт (достаточно взглянуть, как мучается оракл с мускулом). > Удобна? Смотря для кого. Уж явно не для тех кто внедрит а > потом ему и скажут - опаньки, товарищ, а все вкусные плюшки > теперь будут только в энтерпрайз версии - готовь кошелек. Что-то я не понял из высказывания, вы за модель развития по сценарию MySQL и Java, где все ништяки за отдельную денежку, или предпочтёте пользоваться свободными продуктами с моделью обмена ништяков по сценарию: IBM <-> eclipse.org, IBM <-> apache.org?
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	22. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+1 +/–
	Сообщение от Аноним (??) on 27-Сен-11, 00:20
	>предпочтёте пользоваться свободными продуктами с моделью обмена ништяков Я бы предпочел, только где их взять? (приведенные тандемы в обмене ништяками замечены не были)
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	23. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 00:30
	>предпочтёте пользоваться свободными продуктами с моделью обмена ништяков по сценарию: IBM <->... Эх, мечтатели. Apple - вовсе не IBM.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	55. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от VoDA (ok) on 27-Сен-11, 08:45
	> Что-то я не понял из высказывания, вы за модель развития по сценарию > Java, где все ништяки за отдельную денежку написано так, как будто базовая Java не несет бОльшую часть реально нужных фич ;) платная версия Java были и при Sun и ничего - все живы )))
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

6. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
Сообщение от freename (ok) on 26-Сен-11, 22:06
DIFFUSE интересная вещь ждем...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от artemrts (ok) on 26-Сен-11, 23:03
	Мне вот интересно, а кто ее пробовал в реальной практике? Насколько "точное" обучение? Бывают-ли ложные срабатывания? Если это так кульно как пишут, то я наверное перейду на ipfw :-)
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	16. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Andrew Kolchoogin on 26-Сен-11, 23:24
	Мне кажется, что отрабатывать бинарной логикой (allow/deny) на статистические сведения не вполне правильно. Вместо IPFW я бы посоветовал Dummynet. Ну, если какой-то трафик начинает доставать -- шейпить его. Чем больше достаёт -- тем больше шейпить.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	24. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+1 +/–
	Сообщение от Аноним (??) on 27-Сен-11, 00:36
	Идея DIFFUSE настолько оторвана от привычных сетевых задач, что ее возникновение можно объяснить только двумя путями: 1. Университетские профессоры баловались матаном, не задумываясь о практическом смысле своих построений. 2. Бал заказан Juniperом (или каким-нибудь другим из великих), так как их очень сложным интегрированным комплексным решениям не хватало одной детальки, для разработки которой нужно хорошее знание матана, и поэтому проще оказалось подкинуть денежек профессорам.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	25. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Ищавин on 27-Сен-11, 00:50
	Скорее всего Juniper'ом. Вообще не понимаю причем тут Эппл в комментариях выше упоминают. Хорошо, что они не знают, что launchd собираются во Фряху портировать :)
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	28. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от fidaj (ok) on 27-Сен-11, 01:27
	> Хорошо, что они не знают, что launchd собираются во Фряху > портировать :) а вот тут хотелось бы поподробнее... насколько я знаю оно уже в не таком далеком 2008 успело загнуться... http://wiki.freebsd.org/launchd либо я где-то что-то пропустил...
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	70. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Ищавин on 27-Сен-11, 13:18
	В начале 2009. Им стало влом потом писать plist'ы для тонны софта и они не знали что делать LaunchAgents. Но время идет и нужно всем показывать, что система развивается, так что я недавно от кого-то из местных разрабов слышал, что они не прочь к 9.2 или может 10 подтянуть launchd.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	71. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от fidaj (ok) on 27-Сен-11, 13:29
	> В начале 2009. Им стало влом потом писать plist'ы для тонны софта > и они не знали что делать LaunchAgents. Но время идет и > нужно всем показывать, что система развивается, так что я недавно от > кого-то из местных разрабов слышал, что они не прочь к 9.2 > или может 10 подтянуть launchd. я посмотрел по git-ам svn-ам - последние движения были датированы 2009-ым... то что есть в наличии даже не собирается на той же 9-ке... https://github.com/rtyler/launchd-for-freebsd где есть рабочий вариант, что бы можно было пощупать и подключиться к проекту? или где почитать об информации - что собрались продолжить проект? в рассылке ничего не видел за последние пол года...
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	32. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 02:23
	>Хорошо, что они не знают, что launchd собираются во Фряху портировать Собирались, если быть точным. Мечтателей там дофига, а разработчиков полтора человека. Они еще и KVM собирались портировать, между прочим. И где это все теперь?
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	84. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 17:26
	> Они еще и KVM собирались портировать, между прочим. И где это все теперь? А еще был с помпой представлен порт на AVR32. А еще был сделан порт на DIR320. И еще кучу железок. Только мечтатели умеющие держать в своих лапках компилер что-то закончились и все это как было так и осталось в неюзабельном состоянии.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	29. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от iZEN (ok) on 27-Сен-11, 01:36
	> Идея DIFFUSE настолько оторвана от привычных сетевых задач Привычная такая сетевая задача "классифицировать трафик по его поведению" — как раз для Ростелекома, сейчас носящегося с идеей DPI (Deep Packet Inspection), чтобы стричь бабки с потребителей определённого таким образом трафика, предоставляя те или иные услуги по его приоритезации и регулированию. :)) http://www.nag.ru/articles/article/20710/rostelekom-2-0-pere... Этакая дубинка в руках монополиста. Думаете Ростелеком спонсирует становление технологии DIFFUSE?
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	30. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Добрый Дохтур on 27-Сен-11, 01:55
	>> Идея DIFFUSE настолько оторвана от привычных сетевых задач > Привычная такая сетевая задача "классифицировать трафик по его поведению" — как раз > для Ростелекома, сейчас носящегося с идеей DPI (Deep Packet Inspection), чтобы > стричь бабки с потребителей определённого таким образом трафика, предоставляя те или > иные услуги по его приоритезации и регулированию. :)) > http://www.nag.ru/articles/article/20710/rostelekom-2-0-pere... для этого достаточно cisco sce / cisco csg. > Этакая дубинка в руках монополиста. Думаете Ростелеком спонсирует становление технологии > DIFFUSE? iZEN, ты глупости бы не говорил, а? идее DPI сто лет в обед и DIFFUSE тут где-то далеко сбоку. (а freebsd - вообще очень далеко). Потому что для нормального DPI надо уметь ходить внутрь пакетиков и из этого собирать полноценный data flow(а из него вытягивать протоколы прикладного уровня, которые уже и анализировать).
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	31. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от iZEN (ok) on 27-Сен-11, 02:23
	>> Этакая дубинка в руках монополиста. Думаете Ростелеком спонсирует становление технологии DIFFUSE? > iZEN, ты глупости бы не говорил, а? идее DPI сто лет в > обед и DIFFUSE тут где-то далеко сбоку. Вот я и говорю, что Ростелекому не по плечу оказалась DPI — надо придумать альтернативу. DIFFUSE как раз и есть та самая реальная альтернатива DPI: классификация трафика не по внутреннему содержимому пакетов (что, очевидно, затратно, хотя и в большинстве случаев точно), а по внешнему поведению.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	35. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 02:33
	> Вот я и говорю, что Ростелекому не по плечу оказалась DPI — > надо придумать альтернативу. DIFFUSE как раз и есть та самая реальная > альтернатива Ой, да вы, оказывается, инсайдер из Ростелекома! Извините, не признали сразу. Конечно, это все меняет.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	49. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от www2 (??) on 27-Сен-11, 07:50
	Кому что, а лысому - расчёска. Только неуёмное помешательство на FreeBSD и параноидальная озабоченность коварным Ростелекомом могут привести к таким мыслям. Ты поосторожнее свои мысли высказывай, а то медбратья не дремлют - могут тебе и рукава за спиной завязать.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	87. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 17:42
	> Идея DIFFUSE настолько оторвана от привычных сетевых задач, что ее возникновение можно > объяснить только двумя путями: > 1. Университетские профессоры баловались матаном, не задумываясь о практическом смысле > своих построений. Походу многих смущает термин "классификации трафика на основании статистических параметров потоков данных". А в принципе банальная задача ограничение коннектов с IP во времени (к примеру не более 1000 коннектов в секунду) вроде как не решаемая в ныне существующем ipfw. Это простой пример "статистических параметров". А блин бывает надо... (По крайней мере не придумал способа выставить ограничение на максимальное количество коннектов за 1 секунду с IP в локалке. А то легко получить сквид лог размером в несколько гигов за день.) Так что жду.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	125. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 28-Сен-11, 00:25
	> потоков данных". А в принципе банальная задача ограничение коннектов с IP > во времени (к примеру не более 1000 коннектов в секунду) вроде > как не решаемая в ныне существующем ipfw. 1) А зачем вообще это ограничивать? 2) Неужто ipfw настолько топор что число syn пакетов в единицу времени посчитать не в состоянии?
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	143. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 28-Сен-11, 13:11
	>> потоков данных". А в принципе банальная задача ограничение коннектов с IP >> во времени (к примеру не более 1000 коннектов в секунду) вроде >> как не решаемая в ныне существующем ipfw. > 1) А зачем вообще это ограничивать? > 2) Неужто ipfw настолько топор что число syn пакетов в единицу времени Вроде в 8ке только общее количество коннектов. А никак не во времени :( > посчитать не в состоянии? Да была такая проблема. На выходе в офисе стоит сквид, POST и в принципе закачка наружу по http зарезана. Логи в том числе денаи вести обязательно надо (хозяева параноят, но в принципе понятно), тоесть не отрубить. В локалке разрабам поставили Virtual Box на комп, Этой бредовой проге для того чтобы закачать апдейты почему то потребовалось обязательно слать запрос с POST. В итоге имею за пару тройку дней 27 гиговый лог файл. По времени отлупов вижу, что эта машинка с разницей в миллисекунду долбилась получала отлуп и опять долбилась. Может я конечно не так курил ман по сквиду и там можно повторяющиеся логи как то объединять. Пришлось разрешить доступ виртбоксу к его аплоадам на всякий пожарный ну и отключение их в настройках. Но как файт от такого случайного доса из локалки с одного IP очень бы помогло packets per second ограничение. Diffuse как я понимаю должен предоставить и такую возможность.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	158. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 28-Сен-11, 15:49
	>> 1) А зачем вообще это ограничивать? >> 2) Неужто ipfw настолько топор что число syn пакетов в единицу времени > Вроде в 8ке только общее количество коннектов. А никак не во времени :( Ппц, а в лине можно например отмаркировать "все syn-пакеты" иптаблезом как "некий поток номер эн" и утолкать сие шейперу, так флуд оными будет лимитирован до вполне конкретных величин как любой иной вид траффика, но приоритет и доступный бандвиз можно задать персонально этому "типу траффика". При этом юзверг не сможет послать более энного числа пакетов в секунду по вполне очевидным причинам (нарвется на лимит траффика потока SYN пакетов). Хотя наверное и иные варианты есть (модуль recent и счет, например). > с разницей в миллисекунду долбилась получала отлуп и опять долбилась. Ого. Как злой воркэраунд - ну воткнуть рулез файру до сквида - если src такой а dst сякой - DROP. Тут и флудить будет сложно (таймаут connect() обычно около 60 секунд) и сквиду срач не достанется. > очень бы помогло packets per second ограничение. Вот уж не подумал бы что в бсде с этим какие-то проблемы. В линухе на раз делается. > Diffuse как я понимаю должен предоставить и такую возможность. Он для этих целей - как из пушки по воробьям.
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

26. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	–1 +/–
Сообщение от AHAHAC (ok) on 27-Сен-11, 00:56
> а статистическими характеристиками потока, > свойственными определенным видам трафика. Ура, циска раздаёт куски IOS !!!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

27. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	–5 +/–
Сообщение от Vernat (ok) on 27-Сен-11, 01:19
зачем уходить с гнутого стека? Ради возможности не показывать свой код?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	33. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	–7 +/–
	Сообщение от Аноним (??) on 27-Сен-11, 02:28
	> зачем уходить с гнутого стека? Ради возможности не показывать свой код? Разумеется. В технологическом плане BSD-системы вот уже несколько лет пытаются догнать пингвина, но получается все хуже и хуже. Но технологическое отставание компенсируется серьезными бонусами - прирученным сообществом (можно мягко и ненавязчиво задавать направления развития) и возможностью спокойно использовать его труд в проприетарной продукции.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	34. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+2 +/–
	Сообщение от iZEN (ok) on 27-Сен-11, 02:32
	>> зачем уходить с гнутого стека? Ради возможности не показывать свой код? > Разумеется. В технологическом плане BSD-системы вот уже несколько лет пытаются догнать > пингвина, но получается все хуже и хуже. Но технологическое отставание компенсируется > серьезными бонусами - прирученным сообществом (можно мягко и ненавязчиво задавать направления развития) и возможностью спокойно использовать его труд в проприетарной продукции. Я что-то пропустил, Red Hat, Oracle, CISCO отказываются от пингвина в пользу BSD?
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	36. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 02:35
	> Я что-то пропустил, Red Hat, Oracle, CISCO отказываются от пингвина в пользу BSD? Насчет пропустили - не знаю, но трава у вас хорошая. Отсыплете?
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	80. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 17:11
	> Насчет пропустили - не знаю, но трава у вас хорошая. Отсыплете? Это же изен. Он доставляет. Лулзы в основном.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	37. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	–1 +/–
	Сообщение от Аноним (??) on 27-Сен-11, 02:39
	> Я что-то пропустил, Red Hat, Oracle, CISCO отказываются от пингвина в пользу BSD? Редхату и Ораклу проще открывать код, чем пытаться дотянуть *BSD до пингвиньего уровня. Насчет цисок не знаю, у них же вроде своя песочница со своими куличиками?
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	89. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Diden05 (ok) on 27-Сен-11, 17:58
	В больших цисках типа ASR грузится Линух, и поверх запускается IOS который уже и рулит трафиком, насколько я знаю.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	38. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+3 +/–
	Сообщение от Andrew Kolchoogin on 27-Сен-11, 02:40
	> В технологическом плане BSD-системы вот уже несколько лет пытаются догнать пингвина, > но получается все хуже и хуже. BtrFS допилите, тогда и поговорим. А то сколько было словесного грохота: "Не нужна нам ZFS, не нужна нам ZFS!" Поорали, да спортировали.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	39. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	–4 +/–
	Сообщение от Аноним (??) on 27-Сен-11, 02:47
	> BtrFS допилите, тогда и поговорим. До уровня ZFS? (недо-рейд, не умеющий добавлять диски в пятый и шестой уровень, недо-менеджер томов, не умеющий выводить тома из групп, недо-ФС, медленно работающая и жрущая кучу памяти) Зачем им это? Использовать такое чудо вместо RAID+LVM+XFS/nilfs2/ext4 - серьезный шаг назад в плане технологического развития. Btrfs пилится ораклом под его сугубо ораклиные нужды. А ZFS вообще спортировали какие-то американские ученые для гибридизации с люстрой и захвата мира :)
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	41. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	–5 +/–
	Сообщение от Аноним (??) on 27-Сен-11, 02:56
	>Использовать такое чудо вместо RAID+LVM+XFS/nilfs2/ext4 - серьезный шаг назад в плане технологического развития. Вообще это такой посттравматический синдром: долгие годы во фре не было нормальных ФС, нормального менеджера томов и нормального рейда. Вместо этого были UFS и vinum. И тут им неожиданно подарили что-то более менее рабочее (заметим, сами написать не смогли). Гордость и счастье просто распирают. И не могут они понять спокойствия и равнодушия тех людей, которые уже давно имели нормальный рейд и менеджер томов.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	44. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от kshetragia (ok) on 27-Сен-11, 05:43
	>>Использовать такое чудо вместо RAID+LVM+XFS/nilfs2/ext4 - серьезный шаг назад в плане технологического развития. > Вообще это такой посттравматический синдром: долгие годы во фре не было нормальных > ФС, нормального менеджера томов и нормального рейда. Вместо этого были UFS > и vinum. И тут им неожиданно подарили что-то более менее рабочее > (заметим, сами написать не смогли). Гордость и счастье просто распирают. И > не могут они понять спокойствия и равнодушия тех людей, которые уже > давно имели нормальный рейд и менеджер томов. (снимая лапшу с ушей)Вы когда-нибудь Фрюшу живую видели?
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	50. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от www2 (??) on 27-Сен-11, 07:57
	> (снимая лапшу с ушей)Вы когда-нибудь Фрюшу живую видели? А что не так? Если отбросить подаренный FreeBSD ZFS и совсем недавно появившееся в UFS журналирование, то сможете ли вы назвать в FreeBSD менеджер томов сравнимый по возможностям с LVM и какую-нибудь файловую систему с журналированием? Остаётся голый GEOM - безусловно вещь хорошая, но способная предоставить далеко не все необходимые возможности.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	58. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от user295 on 27-Сен-11, 09:45
	>> (снимая лапшу с ушей)Вы когда-нибудь Фрюшу живую видели? > А что не так? Если отбросить подаренный FreeBSD ZFS и совсем недавно > появившееся в UFS журналирование, то сможете ли вы назвать в FreeBSD > менеджер томов сравнимый по возможностям с LVM и какую-нибудь файловую систему > с журналированием? Остаётся голый GEOM - безусловно вещь хорошая, но способная > предоставить далеко не все необходимые возможности. а в "голой" ufs есть снепшоты, без вашего этого lvm где они есть/работают ли они?;-) надеюсь, не нужно расказывать для чего нужны снепшоты?
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	64. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от anonymous (??) on 27-Сен-11, 12:19
	> без вашего этого lvm где они есть/работают ли они? прикинь, а без ядра вообще никакой софт не работает! а без tar и gzip tgz-тарболы не развернуть. и так далее. ну, или для альтернативно развитых: конечно, можно игнорировать наличие удобного инструмента, не привязаного к конкретной фс, и заявлять, что «снапшотов нет!» а можно умыться соплями, мечтая о том светлом дне, когда в любимой ОС появится инструмент с такой же функциональностью.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	74. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+3 +/–
	Сообщение от Школьник (ok) on 27-Сен-11, 16:33
	Красноглазым уже тысячи раз объясняли, чем плохи снэпшоты на уровне LVM, но они так и до сих пор не поняли этого. Оно и понятно - они слишком заняты накладыванием патча на патч к патчу, чтобы думать головой.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	85. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	–3 +/–
	Сообщение от Аноним (??) on 27-Сен-11, 17:30
	> Красноглазым уже тысячи раз объясняли, чем плохи снэпшоты на уровне LVM, но > они так и до сих пор не поняли этого. А школьники так и не догнали что UFS с своими снапшотами - не сильно лучше. Нормальные снапшоты - это CoW на уровне файловой системы и ее стрктур. Тогда это более-менее работает. Но UFS это не светит - на уровне структур это окаменелый выпердыш мамонта, эпохи каменноугольного^W расцвта первых-вторых экстов примерно.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	88. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+2 +/–
	Сообщение от Школьник (ok) on 27-Сен-11, 17:54
	Конкретные недостатки работы snapshots в UFS2 - в студию. Тезисы об "окаменелых выпердышах", столь любимые User294, который почему-то теперь стесняется логиниться, можешь засунуть в /dev/null - UFS2 ввели в строй в начале 2003 года вместе с FreeBSD 5.0, да и не прекращается ее развитие до сих пор. С таким же успехом я могу сказать, что ext4 "окаменела" потому, что корни ее уходят в ext1, который вообще из 90ых пришел. Кстати, в ext4 со снапшотами пока что все плохо - есть июньский патч (не от RedHat), вот только много ли найдется смелых, готовых поставить это в продакшн?
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	94. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 18:50
	> Конкретные недостатки работы snapshots в UFS2 - в студию. Лучше поставить вопрос иначе: придумайте хоть одно достоинство этого костыля. Сам по себе UFS - древнее тормозное барахло с архаичным устройством кишков, эпохи ранних EXTов едва ли. И таковым и останется, что с снапшотами, хоть без. Даже есди вы привинтили к вашему жигуленку пару колес от мерса - мерсом он от этого не стал. Странно, правда? > Тезисы об "окаменелых выпердышах", столь любимые User294, который почему-то > теперь стесняется логиниться, можешьзасунуть в /dev/null - UFS2 ввели в строй > в начале 2003 года вместе с FreeBSD 5.0, Так я и говорю - окаменелость. Дисковые структуры остались из эпохи царя гороха. То что к этим окаменелостям снапшоты прикрутили - ну да, можно жигуленка и на колеса от мерса поставить. А смысл? Ездовые качества улучшатся не сильно. Разве что понты кидать? Как раз в вашем стиле. > да и не прекращается ее развитие до сих пор. Развивающим не хватило пороха выбросить тот античный шит который там был и сделать заново, используя опыт и знания появившиеся за столько лет. Даже до создателей EXTов дотумкало уже что экстенты - штука хорошая. А до бздельников как до жирафов, что в ufs что в zfs. Развития с учетом удачных новых технологий - нет. > С таким же успехом я могу сказать, что ext4 "окаменела" потому, что корни > ее уходят в ext1, который вообще из 90ых пришел. В чем-то это будет даже верно. Но заметьте: даже они доперли наконец выбросить антикварный блочный аллокатор с битмапами и поюзать экстенты (потеряв обратную совместимость). Т.е. этому жигуленку сменили двигло, кузов и прочая. От жигуленка осталось только название. А в остальном - довольно современный агрегат, с очень непозорными скоростными характеристиками. Про UFS это не скажешь, а ZFSу в силу энтерпрайзности его тормоза кой-как затыкают набивая десятки гиг оперативы. > Кстати, в ext4 со снапшотами пока что все плохо - есть июньский патч > (не от RedHat), вот только много ли найдется смелых, готовых поставить это в продакшн? А что, снапшоты через LVM уже отменили? Не, если у кого зад просит приключений с свежаком и патчами - это вариант, но можно же и без острых ощущений, а?
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	112. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от iZEN (ok) on 27-Сен-11, 20:48
	>> Конкретные недостатки работы snapshots в UFS2 - в студию. > Лучше поставить вопрос иначе: придумайте хоть одно достоинство этого костыля. Сам по > себе UFS - древнее тормозное барахло с архаичным устройством кишков, эпохи > ранних EXTов едва ли. Если почитать умную книжку разработчиков FreeBSD на момент выхода FreeBSD 5.2, то можно узнать, что от прежней UFS осталось только 10% кода. > И таковым и останется, что с снапшотами, > хоть без. Даже есди вы привинтили к вашему жигуленку пару колес > от мерса - мерсом он от этого не стал. Странно, правда? Странно то, что линуксоиды до сих пор не могут взять в толк, что смена поколений UFS не делает их совместимыми сверху вниз. UFS2 отличается от UFS1 даже больше, чем Ext4 отличется от Ext2. >> Тезисы об "окаменелых выпердышах", столь любимые User294, который почему-то >> теперь стесняется логиниться, можешьзасунуть в /dev/null - UFS2 ввели в строй >> в начале 2003 года вместе с FreeBSD 5.0, > Так я и говорю - окаменелость. UFS2 стала готовой к промышленному использованию только в FreeBSD 6.0. А это — ноябрь 2005 года (примерно через два года, когда стала рабочей и довольно надёжной Ext3 в Linux). Так кто там "окаменелость"? UFS2, которая появилась на два года позже Ext3? > Дисковые структуры остались из эпохи царя > гороха. То что к этим окаменелостям снапшоты прикрутили - ну да, > можно жигуленка и на колеса от мерса поставить. А смысл? Ездовые > качества улучшатся не сильно. Разве что понты кидать? Как раз в > вашем стиле. Новая архитектура UFS2 позволяет значительно оттюнить производительность I/O не прибегая к отдельным патчам и костылям (в случае использования менеджера томов). Например, в UFS2 улушен механизм хэширования каталогов, убраны ненужные глобальные блокировки, повышена надёжность хранения данных за счёт нового механизма транзакций на уровне драйвера SATA-II/SAS. >> да и не прекращается ее развитие до сих пор. > Развивающим не хватило пороха выбросить тот античный шит который там был и > сделать заново, используя опыт и знания появившиеся за столько лет. Даже > до создателей EXTов дотумкало уже что экстенты - штука хорошая. А > до бздельников как до жирафов, что в ufs что в zfs. В UFS2 размещение данных в последовательностях осуществляется по возможности в пределах одной группы цилиндров (даже для метаинформации этих данных, чего нет в Ext*) и используется пространство фрагментов блоков данных — в экстентах надобности нет, фрагментация минимальна. В ZFS переменный размер блоков от 128 килобайт, в экстентах нужды нет. > Развития с учетом удачных новых технологий - нет. >> С таким же успехом я могу сказать, что ext4 "окаменела" потому, что корни >> ее уходят в ext1, который вообще из 90ых пришел. > В чем-то это будет даже верно. Это не в чём-то верно, это верно де-факто и де-юре. > а ZFSу в силу энтерпрайзности его тормоза кой-как затыкают набивая десятки гиг оперативы. В ZFS оперативка используется для кэширования. Если оперативная память на боевом сервере не занята, а процессор нагружен постоянно на 20% и меньше, то это плохое вложение средств в вычислительный комплекс и инфраструктуру. И это далеко не то же самое, что "давайте постоянно считать Super PI" и "искать корни систем уравнений с n-неизвестными, чтобы загрузить процессор и ОЗУ на 120%". Здесь дело в определении узких мест и своевременном реагировании на их появление — ZFS справляется с этим превосходно: освобождает кэш в ОЗУ для ресурсоёмких операций, а потом опять забирает — оперативная память используется ВСЯ. Чего не скажешь от традиционных решениях. Наверно поэтому для них придумана вся эта шумиха вокруг виртуализации и гибкого распределения ресурсов, чтобы загрузить процессор и память на 100%, запуская несколько виртуальных машин на одном процессоре/в одном пространстве памяти несмотря на то, что организация самой витуализации потребляет 10-20% вычислительных ресурсов. >> Кстати, в ext4 со снапшотами пока что все плохо - есть июньский патч >> (не от RedHat), вот только много ли найдется смелых, готовых поставить это в продакшн? > А что, снапшоты через LVM уже отменили? А что, снапшоты с LVM уже можно накатить на свежу ФС? dump/restore на LVM-снапшоте делаются? Или это не снапшоты вовсе, а просто образ файловой системы в определённый момент времени, который годен лишь, чтобы на него посмотреть и выбросить, чтобы не тормозить I/O всей дисковой подсистемы? Ась? > Не, если у кого зад просит приключений с свежаком и патчами - это вариант, но можно > же и без острых ощущений, а? Можно. Без острых ощущений — просто используете современные технологии и ффсё.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	118. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	–2 +/–
	Сообщение от ананим on 27-Сен-11, 22:55
	Когда тут с месяц назад интервью с разрабами бзд было и тот, что лояльный к бзд, назвал код уфс явно сырым, то айзен помалкивал. хрена ли, это не фс писать. тут и потролячить можно.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	128. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	–1 +/–
	Сообщение от 1 (??) on 28-Сен-11, 09:42
	LVM снапшоты так-то до сих пор на уровне dd остались, юзабельными назвать язык не поворачивается.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	139. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от ананим on 28-Сен-11, 11:56
	Вот по это хавтухе http://wiki.samba.org/index.php/Script работает файловый сервер и ~170 пользователей в конторе с хранилищем в 6Тб с lvm и xfs. Юзается интенсивно. Вопросов нет. Правда эти снапшоты прикрутил уже от нечего делать. Хоть и полезно, но не критично. ps: думаю вы лвм никогда не видели вообще.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	140. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Школьник (ok) on 28-Сен-11, 12:24
	А ты попробуй сделать снапшот ФС с файлами базы данных. Например, MySQL ISAM (хотя и с InnoDB теоретически тоже есть шанс прийти к "успеху"). И без блокировки таблиц на запись (пользователи устанут ждать). И посмотри потом, в каком состоянии будет твоя база.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	142. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от ананим on 28-Сен-11, 12:49
	Без блокировки и в уфс нельзя. И в зфс нельзя. Прикинь новость?:D И если уж мне действительно серьёзные вещи нужны, то юзаю я к примеру оракловый асм >Read-write Oracle ACFS snapshots This feature supports read-write snapshots on Oracle ACFS file systems. For information about Oracle ACFS snapshots, refer to"About Oracle ACFS Snapshots" . The acfsutil snap commands support read-write snapshots. For information about these commands, refer to "Oracle ACFS Command-Line Utilities for Multiple Environments" . http://download.oracle.com/docs/cd/E11882_01/server.112/e189... А не занимаюсь хернёй. Зыж Кстати, такого решения оракл (владелец) на зфс почему-то не предлагает. Вот интереснно почему?
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	152. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Школьник (ok) on 28-Сен-11, 14:51
	> Без блокировки и в уфс нельзя. И в зфс нельзя. > Прикинь новость?:D Да, тут я действительно сморозил глупость. > Кстати, такого решения оракл (владелец) на зфс почему-то не предлагает. Вот интереснно > почему? Наверное, потому, что в ZFS записываемые снапшоты называются клоны, и они там есть с самого момента создания ZFS?
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	154. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от ананим on 28-Сен-11, 15:29
	поверьте, снэпшоты в оракловом решении - 100500 место по важности.:D почитайте по ссылке. там много интересного.
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	177. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Школьник (ok) on 28-Сен-11, 18:11
	Прочитал. А какой смысл сравнивать специализированное решение для хранения файлов БД Oracle и файловую систему общего назначения? ZFS (или UFS+GEOM) нужно сравнивать с ext4+LVM, а не с Oracle ASM. Она, пойди, еще и денег отдельных стоит.
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	183. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от ананим on 28-Сен-11, 19:42
	да хоть с чем угодно сравнивайте. Один "ой" вы уже сказали, второй "ой" ocfs2 в ванильном ведре, 3-е "ой" - для субд (с вашим примером с заморозкой) пусть даже за бабки, но есть таки продуктивное решение, а в бсд - нет.
	Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

	199. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 30-Сен-11, 05:56
	> за бабки, но есть таки продуктивное решение, а в бсд - нет. Оракл вообще бсд как платформу для своих БД не рассматривает...
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	198. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 30-Сен-11, 05:55
	> Наверное, потому, что в ZFS записываемые снапшоты называются клоны, и они там > есть с самого момента создания ZFS? В btrfs есть и записываемые снапшоты и клоны файлов, когда файл расщепляется на 2 и копии живут своими жизнями (при необходимости CoW компенсирует отличия файлов от оригинала). Нормальненько? Кстати если бухтеть про продакшн - пока-что я не видел камикадзей которые бы в реально крупных инсталляциях в mission critical задачах рискнули бы BSD'шный ZFS заюзать. В основном всякие iZENы попадаются, с их супер-райдами аж из 3 ноутбучных дисков, хе-хе. В такой конфигурации пожалуй и btrfs уже погонять реально.
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	203. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Школьник (ok) on 30-Сен-11, 10:36
	> В btrfs есть и записываемые снапшоты и клоны файлов, когда файл расщепляется > на 2 и копии живут своими жизнями (при необходимости CoW компенсирует > отличия файлов от оригинала). 1. Я рад за btrfs. Только мне по-прежнему не видно его особых преимуществ перед ZFS. А вот недостаток - то, что он не готов к продакшну - виден ну очень хорошо. 2. Не совсем понял, зачем это "расщепление". Это ты пытаешься мне сказать, что btrfs умеет аналог data deduplication, который также давно есть в ZFS? >Кстати если бухтеть про продакшн - > пока-что я не видел камикадзей которые бы в реально крупных инсталляциях > в mission critical задачах рискнули бы BSD'шный ZFS заюзать. В основном > всякие iZENы попадаются, с их супер-райдами аж из 3 ноутбучных дисков, > хе-хе. В такой конфигурации пожалуй и btrfs уже погонять реально. Я вообще сторонник того, чтобы на каждую задачу был соответствующий инструмент. FreeBSD вовсе не для всех задач пригодна. У меня, например, хранилище файлов, за которое боязно больше всего, уже 4 года как крутится под Solaris 10+ZFS. Другие хранилища, за которое менее страшно, - на FreeBSD 8.x+ZFS. Почти 2 года - и никаких проблем пока не заметил.
	Ответить | Правка | ^ к родителю #198 | Наверх | Cообщить модератору

	189. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от iZEN (ok) on 28-Сен-11, 23:50
	> Вот по это хавтухе http://wiki.samba.org/index.php/Script работает файловый сервер и > ~170 пользователей в конторе с хранилищем в 6Тб с lvm и > xfs. Юзается интенсивно. > Вопросов нет. > Правда эти снапшоты прикрутил уже от нечего делать. Хоть и полезно, но > не критично. > ps: > думаю вы лвм никогда не видели вообще. У XFS отдельно доставляются утилиты поддержки инкрементных снапшотов xfsdump/xfsrestore (аналог dump/restore на UFS2). Использовать LVM для снапшотов XFS не нужно. http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6...
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	200. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от айзинка on 30-Сен-11, 07:18
	ещё раз - прочитайте что вот это http://wiki.samba.org/index.php/Scrip делает, зачем и как. и прочтите внимательно это: http://en.wikipedia.org/wiki/Xfs#Native_backup.2Frestore_uti... The xfsdump utility backs up an XFS filesystem in inode order, and in contrast to traditional UNIX file systems which must be unmounted before dumping to guarantee a consistent dump image, XFS file systems can be dumped while the file system is in use. This is not the same as a snapshot since files are not frozen during the dump. хотя безусловно если мне нужны постоянные (включая инкрементальные) бэкапы, то это не плохое решение.
	Ответить | Правка | ^ к родителю #189 | Наверх | Cообщить модератору

	160. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 28-Сен-11, 15:50
	> LVM снапшоты так-то до сих пор на уровне dd остались, Это как? И при чем тут dd вообще? > юзабельными назвать язык не поворачивается. Сколько вам за чмыреж пингвина платят? Мне, право, интересно.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	176. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Школьник (ok) on 28-Сен-11, 17:59
	> Сколько вам за чмыреж пингвина платят? Мне, право, интересно. Никто не чмырит пингвина лучше его community с зашкаливающим количеством красноглазых внутри. С такими "друзьями" и врагов не надо.
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	191. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 30-Сен-11, 00:32
	> С такими "друзьями" и врагов не надо. Это видимо про Школьник и FreeBSD было? Ник удивительно соответствует содержанию, и сразу дает понять кто есть кто. Спасибо за честность! :)
	Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

	206. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Школьник (ok) on 30-Сен-11, 11:33
	Когда аргументов не остается, тогда начинают переходить к никам, вспоминают про фашизм и Гитлера и т.д. Коронного аргумента красноглазых - про гомосексуальность mckusick - почему-то еще не было в этом треде. А, ну и тема про UTF-8 в консоли слабо раскрыта.
	Ответить | Правка | ^ к родителю #191 | Наверх | Cообщить модератору

	133. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 28-Сен-11, 10:49
	> Если почитать умную книжку разработчиков FreeBSD на момент выхода FreeBSD 5.2, то > можно узнать, что от прежней UFS осталось только 10% кода. А если почитать и другие ресурсы, можно узнать что в UFS не стали переделывать базовое устройство ФС потому что это было некому делать. Поэтому господа некрофилы решили делать что получится из того что есть. В результате получился какой-то изврат: разработчики на то чтобы ставить костыли нашлись, а на то чтобы дисковые структуры менее архаично сделать - почему-то нет. Глупо, но факт. >> от мерса - мерсом он от этого не стал. Странно, правда? > Странно то, что линуксоиды до сих пор не могут взять в толк, что смена > поколений UFS не делает их совместимыми сверху вниз. UFS2 отличается >от UFS1 даже больше, чем Ext4 отличется от Ext2. Да хрен там - основные дисковые структуры оставили более-менее те же самые. Как раз потому что переделывать весь дизайн капитально всем было влом. >> Так я и говорю - окаменелость. > UFS2 стала готовой к промышленному использованию только в FreeBSD 6.0. А это > — ноябрь 2005 года (примерно через два года, когда стала рабочей > и довольно надёжной Ext3 в Linux). Так кто там "окаменелость"? UFS2, > которая появилась на два года позже Ext3? Понимаешь, жигуленок в гараже - можно и в 2011 году собрать. От того что у него дата выпуска 2011 год - жигуленком он быть не перестанет. Он жигуленок по _технологичности_ а не по дате выпуска. Вот по уровню технологий примененных в дисковых структурах - это каменный век. Просто заметь что все остальные дружно не юзают блочные аллокаторы уже много лет. Примерно с начала 2000х годов тенденция отказа от них пошла. Ну как диски стали становиться реально большими, так они и стали неэффективны по сравнению с экстентами. > Новая архитектура UFS2 позволяет значительно оттюнить производительность I/O не > прибегая к отдельным патчам и костылям Логика додика, быдлотюнящего жигуленок без базового понимания процессов в ДВС. Сколько его ни тюнь, а ничего приличного на выходе не получится. Потому что на уровне базовых деталей - не фонтан. > (в случае использования менеджера томов). Например, в UFS2 улушен механизм > хэширования каталогов, Вай-вай. Надо же. А ничего что в 2011 году не хеширует каталоги ну разве что FAT какой-нибудь? (И то - в принципе можно в памяти хеш на лету строить, хоть это и криво). > убраны ненужные глобальные блокировки, повышена надёжность хранения данных > за счёт нового механизма транзакций на уровне драйвера SATA-II/SAS. Даже если жигуленку прикрутить магнитолу и сигналку - он от этого жигуленком быть почему-то не перестанет. >> до создателей EXTов дотумкало уже что экстенты - штука хорошая. А >> до бздельников как до жирафов, что в ufs что в zfs. > В UFS2 размещение данных в последовательностях осуществляется по возможности в пределах > одной группы цилиндров Фич экстентов не в том что там последовательно распихиваются данные. Это может (и должна) делать почти любая ФС. Соль экстентов в том что на адресацию большого непрерывного блока записывается мелкий объем метаданных, описывающий экстент. А традиционные блочные аллокаторы метят как занятый _каждый_ блок. Поскольку блоков может быть много - пометка занятости может занять дохрена времени. В UFS это не было сделано, поэтому и каменный век. Результаты многих бенчей - недвусмысленно намекают о том кто есть кто. > (даже для метаинформации этих данных, чего нет в Ext*) и используется > пространство фрагментов блоков данных — в экстентах надобности > нет, фрагментация минимальна. Экстенты рулят не потому что они как-то лучше борятся с фрагментацией. А потому что позволяют адресовать большие непрерывные блоки компактнее и быстрее, не метя каждый адресуемый блок как занятый. Борьба с фрагментацией идет в ином месте. А этот уровень всего лишь описывает размещение данных. Заметь, одно и то же размещение без проблем записывается как экстентом так и лобовой пометкой блоков как занятые. Просто второй вариант займет больше времени в случае больших непрерывных блоков (к которым и должна стремиться ФС, по соображениям борьбы с фрагментацией и минимального оверхеда). > В ZFS переменный размер блоков от 128 килобайт, в экстентах нужды нет. А ZFS это вообще пепелац. 1) С фрагментацией эти лютые перцы вообще кажется не считают нужным бороться. Это при том что CoW к фрагментации более склонен, как раз из-за "copy в сторонку" (по определению будет фрагмент). Как я понимаю - сани просто технично забили на проблему болт и при сборке мусора от снапшотов вообще не парятся особо какой-то там дефрагментацией и пересбором того что осталось в непрерывные блоки. Как я понимаю, просто оставляется та вермишель которая вышла. Это конечно упрощает слегка логику удаления снапшотов, но файловая система то неизбежно придет в состояние вермишели постепенно. CoW этому поможет. И да, в btrfs до тех кто ее делал очень вовремя дошло, что подгребая мусор можно и дефрагнуть все эти макароны до кучи, раз уж полезли это переколупывать. 2) А блоки переменной длины - за экстенты не очень то и считаются. Как раз по причине соотношения объема метаданных и данных при записи длинных непрерывных блоков данных. Это всего лишь блочный аллокатор, слегка на стероидах, но общие мерзостные свойства оного от этого никуда не деваются. Учтя когда ZFS проектировался - простительно, но с тех пор инженерная мысля слегка ушла вперед, а экстенты зарулили блочные аллокаторы. >> В чем-то это будет даже верно. > Это не в чём-то верно, это верно де-факто и де-юре. Это не полностью верно по причине того что сделали экстенты, основательно перекроив устройство ФС на довольно базовом уровне, с потерей обратной совместимости. Зато вся эта хирургия привела старпера в чувство и он стал довольно резво бегать теперь. Ради чего все это и затевалось. В кои-то веки EXT больше не считается тормозом. >> а ZFSу в силу энтерпрайзности его тормоза кой-как затыкают набивая десятки гиг оперативы. > В ZFS оперативка используется для кэширования. Если оперативная память на боевом сервере > не занята, а процессор нагружен постоянно на 20% и меньше, то > это плохое вложение средств в вычислительный комплекс и инфраструктуру. Понимаешь ли, изен, только клоуны покупают сервера для обслуживания нужд файловой системы, потому что это слегонца маразм :))). Файловая система - техническая сущность. Нужная для работы сервера как неизбежное зло. Примерно как трубы нужны для того чтобы унитаз работал. Идеальная файловая система в вакууме - не занимает место на диске под себя, не грузит проц на свою обработку и всегда работает со скоростью RAW доступа к диску. Реальная ФС - попытка как-то приблизиться к идеалу, с теми или иными компромиссами. >  И это далеко не то же самое, что "давайте постоянно считать Super PI" > и "искать корни систем уравнений с n-неизвестными, чтобы загрузить процессор и > ОЗУ на 120%". Здесь дело в определении узких мест и своевременном > реагировании на их появление Чаще всего узким местом является I/O. И ZFS'у тут совершенно нечего показать. Он быстр только если все уместилось в кеш (хаха, как и любая другая ФС). С таким подходом можно вообще все в рамдиске хранить. Проблема лишь в том что HDD используют в основном потому что данные имеют противное свойство: они в оперативу целиком ну никак не умещаются, сколько ее ни воткни. Объемы оперативы почему-то сильно меньше объема HDD. > — ZFS справляется с этим превосходно: освобождает кэш в ОЗУ для ресурсоёмких > операций, а потом опять забирает — Кэп намекает что так работает любой вменяемый менеджер дискового кеша, и почему-то такое поведение можно пронаблюдать как минимум в линуксе и без ZFS :))) > оперативная память используется ВСЯ. Чего не скажешь от традиционных решениях. Нюню? Это где это такой поганый менеджер кеша что он не в состоянии использовать свободную оперативку под кеширование при ее наличии? Как миниум в линуксе такого кретинизма не замечено - там кеш ведет себя именно так как ты и описал выше. Лол. > Наверно поэтому для них придумана вся эта шумиха вокруг виртуализации и гибкого > распределения ресурсов, Эй, мы не договаривались что ты будешь жрать вещества в процессе написания коментов?! Виртуализация обычно используется потому что современный сервак с сотнями оперативы и гроздями процов - зачастую сильно мощнее чем требует один сетевой демон. Поэтому пилят на кучу отдельных виртуальных серверов. Ну как бы культурные люди не валят все сетевые сервисы в одну помойку - по соображениям минимизации последствий от взломов/факапов/сноса у софта крыши/административных ошибок. Т.е. лимитирование и полисовка потребления ресурсов + мощная изоляция сервисов друг от друга, почти как выносом на отдельные железки. И просто по удобству администрирования. Админить и мониторить несколько простых как топор и хорошо подконтрольных систем - проще чем одного переростка, в котором проблематично контролировать текущие процессы и чем он там сейчас занят вообще. > чтобы загрузить процессор и память на 100%, запуская несколько > виртуальных машин на одном процессоре/в одном пространстве памяти несмотря на то, > что организация самой витуализации потребляет 10-20% вычислительных ресурсов. Капитан намекает что если некий сервак загружен на 80-90%, виртуализовывать его оставляя на той же железке и правда как-то тупо (а зачем?) и чревато (действительно можно тормознуть почем зря). Зато если сервак загружен на 20%, пусть он в той же позе станет загружен на 22 или даже 24% (учтем 10-20% оверхеда, ок). Но остальные то 70 с гаком процентов будут свободны для использования иными сервисами, как "якобы отдельная машина". Ну то-есть думать надо головой, а не другими частями тела. Ну ничего, парни из Яндекса вам кажется доступно все объяснили - как-то вот так: http://habrahabr.ru/blogs/os/124563 [...] > на LVM-снапшоте делаются? Или это не снапшоты вовсе, а просто образ > файловой системы в определённый момент времени, Капитан сообщает что под снапшотом и понимается состояние чего либо на некий момент времени. Для ФС - состояние ФС на этот момент времени. Чего не так то? И зачем вообще сдался dump/restore? > который годен лишь, чтобы на него посмотреть и выбросить, чтобы не тормозить > I/O всей дисковой подсистемы? Ась? Снапшоты нужны в основном 1) Чтобы снять бэкап без изменения состояния файловой системы в этом процессе (если файл будет меняться прямо при его чтении бэкапной программой - в бэкап попадет черт знает что, смесь старой и новой версий, которая вообще работать не обязана) 2) Как средство отката в случае тех или иных факапов. С таким даже LVM справится. Хотя я и не стал бы орать что его реализация снапшотов такой уж супер-пупер. BtrFS будет лучше, что не удивительно - оно вообще сплошной набор снапшотов по сути :) >> Не, если у кого зад просит приключений с свежаком и патчами - это вариант, но можно >> же и без острых ощущений, а? > Можно. Без острых ощущений — просто используете современные технологии и ффсё. Позволю себе отметить что UFS современной технологией ни разу не является. Почему я так считаю - изложено выше.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	187. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от iZEN (ok) on 28-Сен-11, 23:34
	> Снапшоты нужны в основном > 1) Чтобы снять бэкап без изменения состояния файловой системы в этом процессе > (если файл будет меняться прямо при его чтении бэкапной программой - > в бэкап попадет черт знает что, смесь старой и новой версий, > которая вообще работать не обязана) > 2) Как средство отката в случае тех или иных факапов. > С таким даже LVM справится. Немедленно в студию аналог команды "zfs rollback" на LVM2. P.S. User294, хватит финтить, твои уши из-под Аноним'а торчат. Перелогинься под своими ником уже.
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	174. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Школьник (ok) on 28-Сен-11, 17:51
	> Лучше поставить вопрос иначе: придумайте хоть одно достоинство этого костыля. Нет, дорогой наш User294. Тезис о том, что... > Сам по > себе UFS - древнее тормозное барахло с архаичным устройством кишков, эпохи > ранних EXTов едва ли. ... этот тезис - твой, так что тебе и доказывать "окаменелость". Пока что технических аргументов я не услышал, одни голословные обвинения. > И таковым и останется, что с снапшотами, > хоть без. Даже есди вы привинтили к вашему жигуленку пару колес > от мерса - мерсом он от этого не стал. Странно, правда? Пустобрёхство. > Так я и говорю - окаменелость. Дисковые структуры остались из эпохи царя > гороха. То что к этим окаменелостям снапшоты прикрутили - ну да, > можно жигуленка и на колеса от мерса поставить. А смысл? Ездовые > качества улучшатся не сильно. Разве что понты кидать? Как раз в > вашем стиле. Пустобрёхство. >> Кстати, в ext4 со снапшотами пока что все плохо - есть июньский патч >> (не от RedHat), вот только много ли найдется смелых, готовых поставить это в продакшн? > А что, снапшоты через LVM уже отменили? Не, если у кого зад > просит приключений с свежаком и патчами - это вариант, но можно > же и без острых ощущений, а? ext3 и ext4 только в 2.6.29 научили перед снапшотом замораживаться так, чтобы снапшот был в непротиворечивом состоянии. UFS это умела делать с самого момента появления возможности снапшотов - где-то за 5 лет до 2.6.29. Так кто у нас "окаменевший выпердыш мамонта", а, объективный ты наш? :-)
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	201. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от айзинка on 30-Сен-11, 07:36
	>> Сам по >> себе UFS - древнее тормозное барахло с архаичным устройством кишков, эпохи >> ранних EXTов едва ли. >... этот тезис - твой, так что тебе и доказывать "окаменелость". http://www.opennet.dev/opennews/art.shtml?num=31615 29.08.2011 13:13 "Два интервью с участниками FreeBSD Core Team из бывшего CCCР" >Интервью (часть 1, часть 2) с Константином Белоусовым (последний состав Core Team) полностью посвящено FreeBS >... >Journaling в UFS еще слишком сырой; ...последний состав Core Team...Journaling в UFS еще слишком сырой >Так кто у нас "окаменевший выпердыш мамонта", а, объективный ты наш? UFS
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	202. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Школьник (ok) on 30-Сен-11, 10:27
	>>Journaling в UFS еще слишком сырой; Т.е. из-за того, что journaling там сырой, сразу следует то, что UFS "окаменела"? А это ничего, что с UFS+soft updates можно прекрасно жить и без journaling? (Только не надо сейчас рассказывать про долгий fsck после внезапного выключения сервера - проблемы красноглазых администраторов общажных сервачков Athlon X2 1800+ с 1Гб RAM, но без ИБП мне не интересны).
	Ответить | Правка | ^ к родителю #201 | Наверх | Cообщить модератору

	209. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от айзинка on 30-Сен-11, 15:58
	манера выражаться у тебя как раз как у красноглазых администраторов общажных сервачков. зыж если в фс нет базовой функциональности современного уровня, то остальные фичи и фичечки уже не имеют значения.
	Ответить | Правка | ^ к родителю #202 | Наверх | Cообщить модератору

	210. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+1 +/–
	Сообщение от Школьник (ok) on 30-Сен-11, 16:18
	> манера выражаться у тебя как раз как у красноглазых администраторов общажных сервачков. У меня отличная манера выражаться. Модератор пропускает, по крайней мере. Не нравится? Не участвуй в дискуссии. И да, я, в отличие от, не сыплю гуманитарными напыщенными метафорами "окаменелый выпердыш мамонта" и т.п., а все свои слова подтверждаю. Если меня тыкают мордой в несоответствие моих слов действительности (что редко, но бывает) - я это признаю. > зыж > если в фс нет базовой функциональности современного уровня, то остальные фичи и > фичечки уже не имеют значения. В какой ФС чего нет? Ты про UFS и журналирование? Ну так уже тысячи раз объясняли, что soft updates - это вполне хорошая альтернатива журналу. Единственная проблема с ними - при внезапном выключении сервера надо параллельно с работой делать fsck для пометки некоторых блоков освободившимися и исправлять счетчик ссылок на inode. Кстати говоря, у нормального администратора внезапных выключений сервера не должно происходить. Тот journaling, о котором идет речь, - он и нужен для того, чтобы не надо было делать fsck. Это не такой journaling, как в других файловых системах, там нет полных метаданных, это журнал намерений (intent log), в котором записываются только операции добавления/удаления ссылки на inode (hardlink) и операции добавления/удаления блока. Но красноглазым ведь это все неинтересно, они видят только слово journaling и тут же объявляют во всеуслышанье о том, что UFS - "окаменелый выпердыш", раз нет журнала.
	Ответить | Правка | ^ к родителю #209 | Наверх | Cообщить модератору

	213. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 02-Окт-11, 19:52
	> Нет, дорогой наш User294. Тезис о том, что... >> Сам по себе UFS - древнее тормозное барахло с архаичным устройством кишков, эпохи >> ранних EXTов едва ли. > ... этот тезис - твой, так что тебе и доказывать "окаменелость". Пока > что технических аргументов я не услышал, одни голословные обвинения. А чего там доказывать? Идете в гугл. Гуглите результаты бенчмарков. Ффтыкаете. По-моему там все доступно - UFS на фоне того же EXT4 например просто в безнадежной Ж. Если не ошибаюсь, были у того же фороникса. Собссно блочный аллокатор - прошлый век, сие выбросили вообще все новые дизайны ФС, ну наверное не без причин? :) Вообще, прикольно там у вас в бзде с ФС. Есть шаттл с ракетой и деревянная крестьянская телега (на шинах-дутиках и с рессорами, с запора сняли - новые технологии \m/ \m/). И более нихрена нет. И чего это до сих пор не вымерли велосипеды, автомобили, самолеты и поезда, не знаете?  :) Ну вот например тут: http://lists.freebsd.org/pipermail/freebsd-geom/2009-June/00... в 2 из 3 бенчей UFS2 слил даже античному EXT3. А EXT4 - сильно резвее, если что. Или вот http://www.phoronix.com/scan.php?page=article&item=dragonfly... - UFS демонстрирует то что и должен. Т.е. слив в большей части типов нагрузок. > Пустобрёхство. Самокритично. > ext3 и ext4 только в 2.6.29 научили перед снапшотом замораживаться так, чтобы > снапшот был в непротиворечивом состоянии. Что-то не помню такого. Впрочем, .29 был пару эпох назад, если честно - мне даже влом раскопки проводить чтобы проверить не соврали ли вы. Оставлю раскопки археологам, пожалуй, увы. А EXT4 стал юзабелен в районе 30-х ядер где-то, и он сильно быстрее ext3 под многими нагрузками. Учтя что UFS > UFS это умела делать с самого момента появления возможности снапшотов - где-то > за 5 лет до 2.6.29. Так кто у нас "окаменевший выпердыш мамонта", а, > объективный ты наш? :-) Даже если крестьянскую телегу поставить на шины-дутики, общий уровень технологичности от этого возрастает не сильно.
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	117. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	–4 +/–
	Сообщение от ананим on 27-Сен-11, 22:48
	А конструктивно тут недавно новость разработчиков бсд из снг была, так один код ufs сырым назвал, а второй так вообще всё раскритиковал. вывод - в попу фенечки, она хоть файлы сохранять умеет? Запор даже тюнингованный запором останется, уши всё-равно торчат.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	182. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 28-Сен-11, 19:19
	> А конструктивно тут недавно новость разработчиков бсд из снг была, так один > код ufs сырым назвал, а второй так вообще всё раскритиковал. читали-читали, читали-читали, да не вычитали. приходите сюда, когда читать научитесь.
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	101. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+3 +/–
	Сообщение от Аноним (??) on 27-Сен-11, 19:46
	>А школьники так и не догнали что UFS с своими снапшотами - не сильно лучше. Угу, только вот у этих школьников нормально реализованы бекапы через эти "не сильно лучше" и пару недель назад тут вылаживали скрипт. А линуксойды до сих пор не знают как к своим снапшотам через llvm подступаться и использовать их, вроде есть и вроде нет снапшотов...
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	104. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от anonymous (??) on 27-Сен-11, 20:02
	> вылаживали скрипт угу. «вылаживали» — это от слова «лажа».
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	113. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 20:53
	а по делу?
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	122. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от ананим on 27-Сен-11, 23:11
	А по делу - тут и советы как починить битые снэпшоты тоже были. И чё? Зыж бэкапы - вещь оч нужная. Но только после того, когда фс делает всё что ей положено.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	107. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 20:22
	> до сих пор не знают как к своим снапшотам через llvm подступаться Бздуны тоже имхо не знают как делать через llvm бэкапы. Вообще, сделать бэкап через llvm - не очень просто. Особенно если вспомнить что это виртуальная машина, которая бэкапам, как бы это сказать, слегонца ортогональна.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	77. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Andrew Kolchoogin on 27-Сен-11, 16:58
	> Красноглазым уже тысячи раз объясняли, чем плохи снэпшоты на уровне LVM, Тем, что они невозможны. > но они так и до сих пор не поняли этого. И до сих пор считают, что работающую базу данных можно "забэкапить" командой 'cp' или ей эквивалентной.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	93. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 18:23
	> Тем, что они невозможны. Нормально. Бсдшник рассказывает бсдшнику о тос что в линуксе невозможны LVM снапшоты. Парни, а вы линукс не хотите для проверки своих тезисов запустить? Или это ниже вашего достоинства? А гнать на форуме пургу - сойдет, типа? > И до сих пор считают, что работающую базу данных можно "забэкапить" командой > 'cp' или ей эквивалентной. В принципе - можно, ничему не противоречит. Если запись так или иначе запаузить на время копирования. Иначе можно поиметь очень странный бэкап, где файл менялся прямо во время копирования :)
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	97. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от anonymous (??) on 27-Сен-11, 19:02
	> В принципе - можно, ничему не противоречит. Если запись так или иначе > запаузить на время копирования. Иначе можно поиметь очень странный бэкап, где > файл менялся прямо во время копирования :) я так понимаю, бсдовые снапшоты эту проблему посностью исключают, и базу можно копировать как угодно и когда угодно, угу.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	102. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 19:49
	>> В принципе - можно, ничему не противоречит. Если запись так или иначе >> запаузить на время копирования. Иначе можно поиметь очень странный бэкап, где >> файл менялся прямо во время копирования :) > я так понимаю, бсдовые снапшоты эту проблему посностью исключают, и базу можно > копировать как угодно и когда угодно, угу. Представьте себе, при бекапах через снапшеты, базу нужно фризить не на весь цикл копи-паста базы, а только на время создания снапшота.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	109. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 20:28
	> цикл копи-паста базы, А можно оформить эту мыслю как-нибудь понаучнее, в виде названий системных вызовов и устоявшихся терминов? А то "цикл копи-паста базы" - сру кирпичами! Столь шикарное школьно-инженегровое описание технологий мне еще не попадалось!
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	114. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 21:02
	>> цикл копи-паста базы, > А можно оформить эту мыслю как-нибудь понаучнее, в виде названий системных вызовов > и устоявшихся терминов? А то "цикл копи-паста базы" - сру кирпичами! > Столь шикарное школьно-инженегровое описание технологий мне еще не попадалось! можно. "цикл копи-паста базы" = время копирование БД.
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	135. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 28-Сен-11, 11:05
	А, я кажется врубился что вы хотели сказать. Простите, а ничего что это самое верно для любой реализации снапшотов, которые вообще можно узреть в виде файловой структуры? Чисто по логике работы снапшотирования и его физическому смыслу - сложно сделать как-то иначе :)
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	180. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 28-Сен-11, 19:04
	> А, я кажется врубился что вы хотели сказать. Простите, а ничего что > это самое верно для любой реализации снапшотов... Прощаю. Да, вы сказали все верно, вот только ветку вы не читали, и к чему я это сказал - не поняли.
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	57. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от user295 on 27-Сен-11, 09:44
	а когда там в линуксах снепшоты фс реализовали? без лвм этой бесполезной. а работают они нормально?
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	65. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	–2 +/–
	Сообщение от anonymous (??) on 27-Сен-11, 12:20
	мантра юзера бсд: «всё, что в бсд не смогли портировать — бесполезно».
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	66. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+1 +/–
	Сообщение от тигар (ok) on 27-Сен-11, 12:31
	> мантра юзера бсд: «всё, что в бсд не смогли портировать — бесполезно». это все что ты смог вымучать из себя? между тем, вопрос задан правильный.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	67. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от anonymous (??) on 27-Сен-11, 12:41
	>> мантра юзера бсд: «всё, что в бсд не смогли портировать — бесполезно». > это все что ты смог вымучать из себя? между тем, вопрос задан > правильный. неа. правильный вопрос будет таким: «а когда уже в бсд появится инструмент, позволяющий делать снапшоты и не привязаный к конкретной фс?» обычно после этого набигают бсдоиды и начинают бессвязно нести околесицу.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	68. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+1 +/–
	Сообщение от тигар (ok) on 27-Сен-11, 12:51
	>>> мантра юзера бсд: «всё, что в бсд не смогли портировать — бесполезно». >> это все что ты смог вымучать из себя? между тем, вопрос задан >> правильный. > неа. правильный вопрос будет таким: «а когда уже в бсд появится инструмент, > позволяющий делать снапшоты и не привязаный к конкретной фс?» обычно после > этого набигают бсдоиды и начинают бессвязно нести околесицу. видишь ли... fs которые есть во фре умеют делать снепшоты сами, без привлечения неких дополнительных и ненужных абстракций. Этого в линукс, например, нету. по крайней мере стабильно работающего. Хотя, безусловно, ты же можешь расказать зачем нужен LVM, да?;) не сдерживай себя, своими словами раскажи
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	95. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+1 +/–
	Сообщение от Аноним (??) on 27-Сен-11, 18:51
	> видишь ли... fs которые есть во фре умеют делать снепшоты сами, без > привлечения неких дополнительных и ненужных абстракций. Это пользователи геома и нетграфа будут про абстракции рассказывать, угу. Лицемерненько :)
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	221. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Клыкастый (ok) on 04-Окт-11, 19:28
	> правильный вопрос будет таким: «а когда уже в бсд появится инструмент, позволяющий делать снапшоты и не привязаный к конкретной фс?» при наличии 2 FS необходимость в таком инструменте кажется надуманой.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	222. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от anonymous (??) on 04-Окт-11, 19:39
	> при наличии 2 FS необходимость в таком инструменте кажется надуманой. тоже правильно, там же и особого выбора между разными FS нет. очевидно, потому, что все остальные FS не нужны.
	Ответить | Правка | ^ к родителю #221 | Наверх | Cообщить модератору

	165. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 28-Сен-11, 16:55
	> мантра юзера бсд: «всё, что в бсд не смогли портировать — бесполезно». Ну вот про виртуализацию они это уже пробовали рассказывать. Яндекс их не понял.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	181. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 28-Сен-11, 19:09
	Ну вот вот Мэтью Диллон в DragonFlyBSD написал в одиночку с нуля новую фс, HAMMER. С офигенскими снепшотами и прочим. Я не думаю, что разрабы FreeBSD не могли написать новую фс самостоятельно, ну просто видимо есть на то причины.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	45. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+4 +/–
	Сообщение от freename (ok) on 27-Сен-11, 05:43
	>недо-рейд, не умеющий добавлять диски в пятый и шестой уровень, недо-менеджер томов, не >умеющий выводить тома из групп, недо-ФС Приставка "недо" к zfs не подходит, не какие  RAID+LVM+XFS/nilfs2/ext4 нельзя сравнивать с zfs это вообще разные технологии, реально c zfs могла бы соперничать c evms если ibm его не похоронила >медленно работающая и жрущая кучу памяти немного завышенное потребление памяти обусловлено тем, что zfs активно работает с кешэм, не вижу в этом не чего плохого(хотя конечно это не дает использовать zfs на продвинутых серверах с Pentium 4 и 512 ОЗУ) насчет скоростных характеристик могу сказать что не чем не хуже extX xfs btrfs и т.п. все эти миллисекунды теряются в погрешностях измерений по ощущениям вообще разницы не вижу, у каждой технологии свои сильные и слабые стороны
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	47. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 07:35
	А вот в чём разница evms с lvm? Пытался за пять секунд найти отличия и области применения. После чего плюнул и не стал копать доки.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	51. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от www2 (??) on 27-Сен-11, 07:59
	> А вот в чём разница evms с lvm? Пытался за пять секунд > найти отличия и области применения. После чего плюнул и не стал > копать доки. В том, что она сводила все дисково-файловосистемные технологии Linux воедино и предоставляла единый интерфейс, учитывающий особенности всех подсистем. В том числе могла управляться с томами LVM и LVM2.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	60. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 10:18
	спасибо.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	61. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 10:39
	хех. Пытаясь найти что-нибудь новое по evms наткнулся на одну интересную статью http://blogs.gnome.org/bolsh/2011/09/01/the-cost-of-going-it.../ .
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	100. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от freename (ok) on 27-Сен-11, 19:44
	проект похоронен окончательно все бывшие разработчики распущенны ibm, есть небольшая кучка энтузиастов которые работают над ней, но они не в состоянии пофиксить старые ошибки, так что нового у точно не чего нету
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	126. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 28-Сен-11, 07:37
	Да там в тексте так и написано.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	166. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 28-Сен-11, 16:56
	> xfs btrfs и т.п. все эти миллисекунды теряются в погрешностях измерений Нормально, бенчмарки - не нужны. Мы на глазок померим как настоящие джедаи.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	72. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+2 +/–
	Сообщение от Andrew Kolchoogin on 27-Сен-11, 13:31
	Вы не вполне хорошо себе представляете, зачем компьютеру ОЗУ. Если ваша любимая связка (LVM+что-то там) не может "освоить" всё имеющееся на компьютере ОЗУ под кэш -- значит, её надо выкинуть и честно признаться, что ZFS работает по-человечески, но пока не работает у вас. "Free memory is a wasted memory". Если вы не в курсе.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	73. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	–1 +/–
	Сообщение от айзинка on 27-Сен-11, 16:19
	>Если ваша любимая связка (LVM+что-то там) не может "освоить" всё имеющееся на компьютере ОЗУ под кэш -- значит что там работают процессы. а вот если для работы фс нужен минимум 1Гб и 64-битное ядро - это повод задуматся нужно ли такое счастье.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	75. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+1 +/–
	Сообщение от Andrew Kolchoogin on 27-Сен-11, 16:56
	> а вот если для работы фс нужен минимум 1Гб и 64-битное ядро - это ... вы сами придумали?
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	99. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от anonymous (??) on 27-Сен-11, 19:08
	> … вы сами придумали? нет, многие бсдоиды тут орали, что если конфиги хуже — то нечего с таким рылом соваться в зфс.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	103. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от freename (ok) on 27-Сен-11, 19:54
	zfs на такой конфигурации работать будет, но просто это бестолково, на основные задачи останется меньше ресурсов как правило если это не файловый сервер то основные задачи у него другие
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	106. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	–1 +/–
	Сообщение от anonymous (??) on 27-Сен-11, 20:05
	ч.т.д. — zfs на серверах не нужен, потому что отбирает ресурсы, которые нужны для работы серверного софта. и единственное место, где zfs хорошо — файлопомойка. вот ведь бсдоиды — если чуть-чуть подождать, то сами скажут о своей системе такое, что даже яростный антибсдоид не сможет.
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	111. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	–2 +/–
	Сообщение от Аноним (??) on 27-Сен-11, 20:34
	> ч.т.д. — zfs на серверах не нужен, потому что отбирает ресурсы, которые > нужны для работы серверного софта. Хоть ты и редиска, но в логическую ловушку поймал наивного бздуна технично. Epic win! :) На самом деле до некоторых жирафов просто медленно доходит что если ФС для быстрой работы надо вагон оперативы - значит диким буфером просто вытягивается из Ж тормозной по своей природе дизайн ФС. А с хрена ли блочному аллокатору быть быстрым?
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	123. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+2 +/–
	Сообщение от Школьник (ok) on 27-Сен-11, 23:37
	На самом деле, красноглазые про себя говорят куда более красноречивее. freename же вроде говорил про 1Гб RAM и 64-битное ядро. Кого сейчас удивишь гигабайтом оперативы? Кого сейчас удивишь даже 8 гигабайтами оперативы на сервере? Только одну категорию лиц - нищих, но красноглазых студентов, которые вместо того, чтобы читать умные книжки, занимаются накладыванием патчей для патча на патч самого свежего ванильного -rc ядра, чтобы потом за баночкой балтики похвастаться среди таких же красноглазых, как круто (теперь зависает только раз в сутки) он обновил ядро на общажном сервачке Athlon X2 1800+ с 1Гб RAM. Мой красноглазый оппонент, ты бы не позорился столь откровенным невежеством. Я тебя уверяю - начиная с 4 Гб оперативы ZFS что на Solaris, что на FreeBSD 8.x будет скакать и прыгать даже при наличии других хорошо потребляющих память сервисов. Особенно если не включать дедупликацию на многотерабайтном пуле. Сколько сейчас стоит 4 Гб оперативы - 700 или 800 рублей? ЕСС FBDIMM будет подороже, но все равно - для энтерпрайза даже средней руки это сущие копейки. А вот сделать из связки ext4+LVM нечто, хотя бы отдаленно напоминающее ZFS первых версий, за 800 рублей уже никак не получится. Я понимаю, красноглазым очень неудобно осознавать, что они лишены возможности пользоваться современной ФС, которая могла бы быть в ядре и нахаляву, да вот только Самая Свободная Во Вселенной Лицензия v2 мешает, ибо твердолобая и не приемлет свободу никакого иного толка, кроме как своего. Лицензию-то обошли, но драгоценное время потеряно. И самое главное - перспективы включения ZFS в ведро никакой, опять же из-за Великой Лицензии. А вне ядра поддерживать порт ZFS кто будет? У RedHat есть свой велосипед под именем ext4, в которую вбухана куча денег, и конкурирующая ФС ей не нужна. Oracle слил Btrfs, а уж ZFS он и подавно не будет поддерживать для линукса - иначе никто не будет покупать его СХД на базе Solaris+ZFS. Остается только сообщество - а оно представлено вот такими вот красноглазыми, как ты, которые даже троллить тонко не умеют. Единого порта ZFS сделать не получилось - и тут разнобой и шатания: два порта, не считая того, что через FUSE, один лучше другого, только все падают. Словом, совсем уж безрадостная картина. Поймите одно: LINUX CANNOT INTO ENTERPRISE NAS. И это - надолго.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	130. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от 1 (??) on 28-Сен-11, 09:50
	все верно, только с поправкой на то что Linux вообще кроме школ никуда не годится пока
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	136. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 28-Сен-11, 11:08
	> все верно, только с поправкой на то что Linux вообще кроме школ > никуда не годится пока Ага, вон в топ500 весьма лютая шк0л0та засела. На LSE и еще пачке бирж - тоже. Циско видимо тоже школьники. Вместе с редхатом.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	179. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	–2 +/–
	Сообщение от anonymous (??) on 28-Сен-11, 18:45
	опять простыня бреда и попаболи, перемешаная с киданием пальцев. в то время, как Ынтрыпразнутые покупают сервера с вёдрами планок памяти, красноглазые решают те же задачи на старом железе, предназначеном на списание. понятно, такой способ решения проблем в моск Ынтырапрайзнутого не помещается, получается перегрузка и неконтролируемое излияние бреда про Мегасервера и Очень Некачественный Линукс (потому что работает на старом железе — ну явно же некачественный, bsd+zfs там даже не кряхтит, а сидит в ступоре).
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	184. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	–1 +/–
	Сообщение от Школьник (ok) on 28-Сен-11, 20:38
	Ну гордись, гордись дальше тем, что твой линукс запускается на процессорах класса Z80. В контексте серверов это ну очень важно. Можно еще код файловой системы на ассемблере переписать - она же быстрее на 0.00001% заработает.
	Ответить | Правка | ^ к родителю #179 | Наверх | Cообщить модератору

	185. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от anonymous (??) on 28-Сен-11, 20:54
	да чем тут «гордиться»? это для бсд «новая фс, теперь с журналами!» — повод для гордости. а линукс — just works, при этом зачастую не требуя тотального обновления серверного парка для «новой крутой фичи». поэтому вашу бсд вместе с зфс и выбирают в качестве серверной системы намного реже. такие дела.
	Ответить | Правка | ^ к родителю #184 | Наверх | Cообщить модератору

	186. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Школьник (ok) on 28-Сен-11, 20:58
	> а линукс — just works, при этом > зачастую не требуя тотального обновления серверного парка для «новой крутой фичи». Это потому что в линуксовых ФС нет новых фич. Есть btrfs, которую до продакшна все никак не допилят. Когда допилят - тогда да, можно будет сказать, что новая фича.
	Ответить | Правка | ^ к родителю #185 | Наверх | Cообщить модератору

	197. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 30-Сен-11, 05:45
	> Поймите одно: LINUX CANNOT INTO ENTERPRISE NAS. И это - надолго. А фрю тоже как ынтырпрайзный NAS не больно то применяют. Более того - если вы разуете глаза то заметите что в реально больших инатслляциях стараются использовать распределенные ФС без единой точки отказа. Чем плохо одно огромное хранилище? Тем что большому кораблю и торпеды большие достаются. Если такое рассыпается - мало не кажется никому.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	204. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Школьник (ok) on 30-Сен-11, 11:26
	> А фрю тоже как ынтырпрайзный NAS не больно то применяют. А причем здесь FreeBSD? Я, вообще говоря, сторонник разумного выбора инструмента под задачу. Под NAS (именно под NAS, а не SAN или что-либо еще) Linux подходит плохо. Вот и все. > Более того > - если вы разуете глаза то заметите что в реально больших > инатслляциях стараются использовать распределенные ФС без единой точки отказа. Чем плохо > одно огромное хранилище? Тем что большому кораблю и торпеды большие достаются. > Если такое рассыпается - мало не кажется никому. В реально больших - да. Но, кроме них, есть еще просто большие и средние. И вот тут ZFS лучше всех других подходит.
	Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

	110. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 20:32
	> zfs на такой конфигурации работать будет, но просто это бестолково, Да, конечно - в силу довольно горбатого дизайна структур zfs без огроменного буфера просто тормозить будет немилосердно. А чего еще ожидать от файловой системы где даже экстентов толком нет - по сути задействован вариант блочного аллокатора, хоть и с блоками переменной длины.
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	115. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от freename (ok) on 27-Сен-11, 21:38
	отчасти zfs создана с заделом на будующие технологии, вы посмотрите тесты производительности на ssd ситуация совсем другая, а ведь они через года 3-5 вытеснят все блочные девайсы, по поводу дизайна сложно что то сказать, мне лично zfs очень нравится очень технологичная фс я еще не видел не одного человека который работал с zfs и говорил о ней отрицательно
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	138. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 28-Сен-11, 11:22
	> отчасти zfs создана с заделом на будующие технологии, вы посмотрите тесты производительности на ssd А на SSD знаете ли и другие не тормозят. Это заслуга малого seek time. А вот оверхед от файловой системы становится еще более заметен и ZFS'у тут совершенно нечем козырнуть.
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	188. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от iZEN (ok) on 28-Сен-11, 23:41
	>> отчасти zfs создана с заделом на будующие технологии, вы посмотрите тесты производительности на ssd > А на SSD знаете ли и другие не тормозят. Это заслуга малого > seek time. А вот оверхед от файловой системы становится еще более > заметен и ZFS'у тут совершенно нечем козырнуть. Разве? А ZFS L2ARC на MLC SSD для кэширования уже не в моде? А ещё ZIL размещают на сверхскоростных SLC SSD для ускорения записи на обычные носители — когда появится M-RAM, то будет ещё быстрее. В Linux пока что придумывают альтернативные решения для традиционных ФС и методов хранения данных: http://www.opennet.dev/tips/2629_flashcache_cache_disk_ssd_bl...
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	196. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 30-Сен-11, 05:42
	> Разве? А ZFS L2ARC на MLC SSD для кэширования уже не в моде? Знаешь, проблема в том что другие ФС размещенные на SSD тоже довольно быстро работают. И чего бы это они? :) > А ещё ZIL размещают на сверхскоростных SLC SSD для ускорения > записи на обычные носители — когда появится M-RAM, то будет ещё быстрее. А ты никогда не думал что ZFS довольно много всего делает? На очень скоростных носителях оверхед от служебных действий оной может начать икаться, пожалуй. То что он у других хуже - это как бы совсем не факт, я бы скорее поставил на обратное. > В Linux пока что придумывают альтернативные решения для традиционных ФС и методов > хранения данных: http://www.opennet.dev/tips/2629_flashcache_cache_disk_ssd_bl... Ну, придумывают. Вполне адекватно вроде придумали - кешируют не нечто абстрактное, а наиболее горячие файлы,такое хорошо например для HTTP серванта: прицельно закешировать всю статику, а по возможности и части динамики в нее же, и отдавать сие с обалденной скоростью с SSD. Сайт превратится в ракету. И флеш заведомо тратится на кеширование полезных сущностей, кешинг которых точно дает хороший результат.
	Ответить | Правка | ^ к родителю #188 | Наверх | Cообщить модератору

	211. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от iZEN (ok) on 30-Сен-11, 16:47
	>> Разве? А ZFS L2ARC на MLC SSD для кэширования уже не в моде? > Знаешь, проблема в том что другие ФС размещенные на SSD тоже довольно > быстро работают. И чего бы это они? :) Бегают, пока не нарвались на частичную деградацию флэшатины. :) В ZFS этот факт довольно быстро локализуется и сообщается о проблеме. На традиционных ФС о проблемах SSD пользователь узнаёт в поседнюю очередь по факту потери данных. > А ты никогда не думал что ZFS довольно много всего делает? На > очень скоростных носителях оверхед от служебных действий оной может начать икаться, > пожалуй. То что он у других хуже - это как бы > совсем не факт, я бы скорее поставил на обратное. Вот только я могу в любой момент "оттюнить" (в ущерб, естественно, сквозной целостности) свойства в ZFS до уровня той же Ext4 и получить от этого нехилую прибавку в скорости. Ext4 до уровня ZFS поднять даже теоритечески не получиться.
	Ответить | Правка | ^ к родителю #196 | Наверх | Cообщить модератору

	212. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от anonymous (??) on 30-Сен-11, 16:48
	> Бегают, пока не нарвались на частичную деградацию флэшатины. :) В ZFS этот > факт довольно быстро локализуется и сообщается о проблеме. На традиционных ФС > о проблемах SSD пользователь узнаёт в поседнюю очередь по факту потери > данных. в зфс таки вмонтировали libastral? круто. обожаю, когда изен поутру чушь несёт.
	Ответить | Правка | ^ к родителю #211 | Наверх | Cообщить модератору

	214. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 02-Окт-11, 20:01
	> Бегают, пока не нарвались на частичную деградацию флэшатины. :) В ZFS этот > факт довольно быстро локализуется и сообщается о проблеме. Ага, на лисяре можно посмотреть как перец бэды локализовывал, педаля структуры ZFS вручную :). Если уж на то пошло, EXT4 вручную разбирать как-то попроще будет :P. Случаев с RAID правда это не касается, все data recovery за восстановление с RAID дерут три шкуры т.к. возни заметно больше получается. >  На традиционных ФС о проблемах SSD пользователь узнаёт в поседнюю очередь по факту потери > данных. Ага, а судя по лисяре пользователь ZFS узнает о бэдах по напрочь немоунтабельному тому, с которого данные выцепить - слегка облом %). Это так уж принципиально лучше? >> пожалуй. То что он у других хуже - это как бы >> совсем не факт, я бы скорее поставил на обратное. > Вот только я могу в любой момент "оттюнить" (в ущерб, естественно, сквозной > целостности) свойства в ZFS до уровня той же Ext4 Ну как бы покажи _бенчмарки_ после тюнинга, разрывающие EXT4? А в похорониксовском postmark, где традиционный слив - слабо? Ну чтобы именно "до уровня"? :) > и получить от этого нехилую прибавку в скорости. Ext4 до уровня ZFS поднять > даже теоритечески не получиться. Почему же, с LVM большинство фич приматываются проволокой. Менее изящно, но работает.
	Ответить | Правка | ^ к родителю #211 | Наверх | Cообщить модератору

	124. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+2 +/–
	Сообщение от Wulf (??) on 28-Сен-11, 00:16
	> даже экстентов толком нет - по сути задействован вариант блочного аллокатора, хоть и с блоками переменной длины. Откуда вы все такие беретесь, анонимные авторы оксюморонов? Какое ПТУ вас производит? Каким образом блочный аллокатор может определить по номеру блока его расположение на носителе, если блоки будут переменной длины? перемножением на средний размер блока или вызовом функции random? У ZFS самый настоящий экстентный аллокатор с размером блока унаследованным от HDD - 512 байт и размером экстента, устанавливаемым парамером recordsize (default 128K, max 1MB). Авторы его называют гибридным из-за относительно небольшого размера экстента, но механика вся экстентная. http://www.dfrws.org/2009/proceedings/p99-beebe.pdf
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	137. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 28-Сен-11, 11:19
	> У ZFS самый настоящий экстентный аллокатор с размером блока унаследованным от HDD > - 512 байт и размером экстента, устанавливаемым парамером recordsize (default 128K, > max 1MB). Действительно, идиотизм с битмапами влобешник там убит. Но проблема в том что "экстент" маленького размера - идиотизм. Мелкие экстенты вообше глупое начинание, в клинических случаях они даже могут проиграть традиционному блочному аллокатору с битмапами. Для сравнения у EXT4 размер экстента по дефолту до 128Мб. Что, всего в 1024 раза больше? :) LOLWUT :)))). Поэтому считать то что сделано в ZFS полноценной реализацией идеи с экстентами может только ZFS'ный маньяк-задрот, не рассматривавший остальные ФС и их анатомию вообще.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	141. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Wulf (??) on 28-Сен-11, 12:32
	> Для сравнения у EXT4 размер экстента по дефолту до 128Мб. Что, всего в 1024 раза больше? Сравнение с ext4 вообще не катит - там нет COW Интереснее сравнение с подходом btrfs. Ибо процесс, используемый там тоже совсем неоднозначный - дробление обычных экстентов на слайсы, т.н. bookend extents. Но, отсутствие последней в каком-либо серьезном продакшене не позволяет, во всяком случае пока, это сделать.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	144. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от ананим on 28-Сен-11, 13:28
	в общем и эктентов достаточно. настоящих. с битмэпами и деревьями. которые очень прилично подняли производительность и были дотянуты до такого состояния продуктивной системы, что гугл все сервисы перевёл на неё.
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	147. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Wulf (??) on 28-Сен-11, 14:05
	> гугл все сервисы перевёл на неё На кого ее? btrfs? Не верю!!! (с)
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	148. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от ананим on 28-Сен-11, 14:12
	Речь о ext4. Очевидно же. Но если мьсе не читатель...
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	156. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Wulf (??) on 28-Сен-11, 15:40
	> Речь о ext4. Речь о том что ФС с COW бессмысленно сравнивать по типичному размеру экстента с ФС без нее. В последнем случае не всегда обязательно копировать весь экстент на новое место из-за изменения 1-го байта.
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

	159. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от ананим on 28-Сен-11, 15:50
	согласитесь, любые фс можно сравнивать по эффективности выполняемой ею работы. ну и про эктенты настоящие, с битмэпами и деревьями, я уже говорил. а именно такие и в ext4, и в бтр.
	Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

	168. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Wulf (??) on 28-Сен-11, 17:10
	> про эктенты настоящие, с битмэпами и деревьями, я уже говорил. а именно такие и в ext4, и в бтр. Понятно, а в ZFS они "ненастоящие", "без битмапов и деревьев" :-) И работает она неэффективно, как я понимаю Вы уже все замерили и сравнили :-) Ну, ну, сидите дальше в своем танке :-)
	Ответить | Правка | ^ к родителю #159 | Наверх | Cообщить модератору

	167. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 28-Сен-11, 17:02
	> Речь о том что ФС с COW бессмысленно сравнивать по типичному размеру > экстента с ФС без нее. В последнем случае не всегда обязательно > копировать весь экстент на новое место из-за изменения 1-го байта. Да, но если мы пишем например 100-меговый кус файла, размер экстента все-таки может нас немного интересовать. От него оверхед будет зависеть. Зачем вообще ограничивать размет блока то? Да еще такой мелкой величиной? Чтобы притормозить?!
	Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

	170. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Wulf (??) on 28-Сен-11, 17:25
	>> Речь о том что ФС с COW бессмысленно сравнивать по типичному размеру >> экстента с ФС без нее. В последнем случае не всегда обязательно >> копировать весь экстент на новое место из-за изменения 1-го байта. > Да, но если мы пишем например 100-меговый кус файла, размер экстента все-таки > может нас немного интересовать. От него оверхед будет зависеть. Зачем вообще > ограничивать размет блока то? Да еще такой мелкой величиной? Чтобы притормозить?! На диск информация скидывается все-равно раз в 30 сек. При этом все изменения объединяются в одну транзакцию и таким образом метаданные на диске не надо исправлять после каждых записанных 128К, только в памяти. Так-что оверхеда особого и нет, учитывая, что sun-овцы очень хвалились эффективностью своей системы кеширования. Сложнее, когда идет синхронная запись или есть memory pressure, но и для этого есть механихзмы ZIL и write-throttling-а.
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

	192. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 30-Сен-11, 04:44
	> На диск информация скидывается все-равно раз в 30 сек. При этом все > изменения объединяются в одну транзакцию и таким образом метаданные на диске > не надо исправлять после каждых записанных 128К, только в памяти. Все-равно оверхеда будет здорово больше. И на операции в памяти, и на сохранение служебных сущностей на диск. Вкатить 1 х 100Мб кусок в любом случае оптимальнее чем порядка 800 кусков для того же самого делать. > Так-что оверхеда особого и нет, учитывая, что sun-овцы очень хвалились > эффективностью своей системы кеширования. Я бы сказал что у них объем маркетинга зачастую перевешивал объем здравого смысла. Вот за это я и не люблю таких махровых коммерсантов - лапши уж больно много с ушей надо снимать. Cложно понять где кончается правда и начинается маркетинг. Поэтому если я думаю о сановских технологиях хуже чем они есть - сани сами виноваты, стандартная компенсация маркетинга врубается. > Сложнее, когда идет синхронная запись или есть memory pressure, > но и для этого есть механихзмы ZIL и write-throttling-а. Для CoW постоянная запись особенно когда диск забит - вообще довольно сложный сценарий. Кстати я вообще нигде в манах не нашел у саней описания как у них расчистка места сделана. Плохо искал?
	Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

	207. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Wulf (??) on 30-Сен-11, 12:52
	> Вкатить 1 х 100Мб кусок в любом случае оптимальнее чем порядка 800 кусков для того же самого делать. Вкатить 1 х 100Мб кусок - Это сфероконь в вакууме. В реальности основные задачи, как раз наоборот, регулярно вкатывать куски по 100Кб. Могу их Вам перечислить: - Перезаписать в произвольном месте файла кусок 8-16Кб (базы данных) - Дописать в конец файла несколько десятков килобайт (логи) - создать и удалить в некоем каталоге несколько десятков - сотен файлов средним размером около 100Кб (кеширование, например, почты, веба или чего-либо подобного) Ряд можно продолжать. Приведите plz, пример полезной загрузки, когда нужно постоянно писать по 100Мб? Файлопомойка студенческой общаги? И да, посчитайте как в вышеупомянутых задачах будут вести себя 100Мб экстенты. Напоминаю про COW, экстенты нельзя править, только записывать заново. Да, кстати, можно и оверхед посчитать для 128кб экстентов и 100Мб файла. Нам надо записать в метадату 800 экстентов. В теории ФС, каждый экстент представляет из себя 2 числа: смещение от начала и длину. Отведем под смещение ZFS-ные 128бит, т.е. 16байт, добавим еще байт на длину (она кратна 512б в ZFS), ок. уложим длину в 4 байта, на всякий случай. Итого 20байт - экстент. Умножаем на 800. получаем 16Кб. Вспоминаем, что нужно поправить еще некоторое кол-во метаданных: space-maps, uberblock и т.д, поэтому домножим на взятый с запасом с потолка коэффициент 10. получаем 160кб. И вспоминаем, что только что мы записали на диск 100Мб. Оверхед - 0.1% Осталось придумать, как этот оверхед измерить :-) А вот с blocksize 4/8кб от ext2-3, ufs и т.д. оверхед уже вполне заметный. > Я бы сказал что у них объем маркетинга зачастую перевешивал объем здравого смысла. Есть в этом правда. Но про эффективность я читал в блогах разработчиков. Они, в частности некоторые структуры, которые на диске хранятся в виде списков/таблиц, в памяти разворачивают в деревья, тем самым сильно ускоряя обработку метаданных, но, при этом, теряют возможность оперативно подгружать их с диска и вынуждены постоянно держать в памяти. > как у них расчистка места сделана. Плохо искал? что такое расчистка места? Дефрагментация что-ли? Тогда никак
	Ответить | Правка | ^ к родителю #192 | Наверх | Cообщить модератору

	215. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 02-Окт-11, 21:05
	>> Вкатить 1 х 100Мб кусок в любом случае оптимальнее чем порядка 800 кусков для того же самого делать. > Вкатить 1 х 100Мб кусок - Это сфероконь в вакууме. В реальности > основные задачи, как раз наоборот, регулярно вкатывать куски по 100Кб. Как бы от задачи сильно зависит. > Могу их Вам перечислить: > - Перезаписать в произвольном месте файла кусок 8-16Кб (базы данных) ZFS почему-то на этих задачах ничего такого интересного не демонстрирует. > - Дописать в конец файла несколько десятков килобайт (логи) Ну, допустим. Только интенсивность этих операций невысока и всем похрену на их скорость. > - создать и удалить в некоем каталоге несколько десятков - сотен файлов > средним размером около 100Кб (кеширование, например, почты, веба или чего-либо подобного) Капитан намекает что файлы бывают разные, поэтому не вижу вреда от возможности выделить одним чихом и несколько мегов, в случае если файл окажется крупнее. Кстати если уж на то пошло, ZFS традиционно сливает тест postmark у похорониксов с разгромным счетом. Что-то не работает ваш юзкейс, а? > Ряд можно продолжать. Приведите plz, пример полезной загрузки, когда нужно постоянно писать > по 100Мб? Файлопомойка студенческой общаги? Файлопомойки (не обязательно студенческие). Фото и видео хостинги, бэкапы, зеркала дистрибутивов и репов и куча всего еще. Вообще, от возможности выделить более крупный экстент хуже как-то не становится (а с чего?), а вот лучше - может. Поэтому не вижу смысла лимитировать размер экстента. От более крупных экстентов может стать лучше, если удалось сэкономить, но хуже то не станет. > И да, посчитайте как в вышеупомянутых задачах будут вести себя 100Мб экстенты. У, я думал что вы умнее, а вы оказывается ни в зуб ногой :(. Нормально они себя ведут, потому что это максимальный размер. Это не мешает делать экстенты меньше. Если надо меньше, будет меньше. Кстати можете посмотреть на постмарк у похороникса, вместе похохочем над "якобы оверхед" у EXT4 по сравнению с ZFS. Как раз примерно указанный вами сценарий - относительно мелкие файлы оптом. Лол :). Подозреваю что дело в том что соотношение "записать 1 экстент" или например "записать 3 экстента" при мелких файлах совсем невкусно: относительный процент на саму запись данных не так уж велик и поэтому эффективность работы с метаданными начинает сильно роялить. Ну вот видимо ZFS и тушуется. > Напоминаю про COW, экстенты нельзя править, только записывать заново. Не вижу принципиальных отличий. Я исходил из общей логики: лопатить структуры которые описывают экстент - придется. Вот оттуда и оверхед: чем больше одним куском описывает экстент, тем меньше относительный оверхед на работу с структурами ФС для записи одного и того же объема данных. [...] > коэффициент 10. получаем 160кб. Тут проблема будет не столько в самих 160 Кб, сколько в том что часть этих данных надо вычислять и все это не обязательно удастся записать одним куском. Что и просадит скорость. Проще говоря, файловая система будет делать довольно много действий которых можно было бы избежать, что не добавит ей скорости работы. Кстати может поэтому постмарк и тухнет? Если на больших файлах все будет похоже на 0.1% указанный вами, то вот когда файл мелкий, запись 1 экстента или допустим 3х - разница в _три_ раза получается. Если время записи самих данных маленькое, это начнет сильно роялить. > И вспоминаем, что только что мы записали на диск 100Мб. Оверхед - 0.1% Как бы то что по объему 0.1% еще не означает что время генерации метаданных и их записи будет 0.1% от потраченного на операцию времени. Тут все очень зависит от. Если на больших файлах нечто похожее на это соотношение еще можно будет увидеть, то вот на файлах размерами порядка нескольких экстентов ZFS... не получится ли как в postmark похороникса? :) > Осталось придумать, как этот оверхед измерить :-) А вот с blocksize 4/8кб от > ext2-3, ufs и т.д. оверхед уже вполне заметный. Естественно, им еще и битмапы занятости надо обновлять на каждый пшик. Что скорости им совсем не добавляет. >> Я бы сказал что у них объем маркетинга зачастую перевешивал объем здравого смысла. > Есть в этом правда. Но про эффективность я читал в блогах разработчиков. У разработчиков есть такое свойство: они все очень любят себя хвалить. > Они, в частности некоторые структуры, которые на диске хранятся в виде > списков/таблиц, в памяти разворачивают в деревья, Такой подход возможен даже для антикварного FAT, но проблема в том что это может жрать довольно много памяти и кроме того "на холодную" этих данных в памяти нет, при холодном доступе тратится некое время на построение в памяти нужных структур. И всегда держать таковые структуры в памяти, особенно если их много, можно только если памяти реально дохрена и она больше никем не используется, а это верно разве что для выделенных файлсерверов. Такой подход - индикация того что дисковые структуры надизайнили не так как надо было бы, а потом передумали и воткнули компромиссный костылик. > тем самым сильно ускоряя обработку метаданных, но, при этом, теряют > возможность оперативно подгружать их с диска и вынуждены постоянно держать в памяти. См. выше, этот подход известен но это в общем то компромиссный вариант исправления перфоманса без существенной переделки дискового формата. Более прямой вариант - дизайнить дисковый формат которому не требуются такие костыли, имхо. >> как у них расчистка места сделана. Плохо искал? > что такое расчистка места? Дефрагментация что-ли? Тогда никак Ну собственно CoW производит запись в сторону. Отсюда вытекает нужда стирать иногда старые данные, иначе место на томе закончится по очевидной причине. У саней в манах про алгоритмы всего этого вообще что-то ни звука. И кстати не вижу причин по которым нельзя сделать дефраг в процессе этого действа.
	Ответить | Правка | ^ к родителю #207 | Наверх | Cообщить модератору

	163. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 28-Сен-11, 16:31
	> Сравнение с ext4 вообще не катит - там нет COW И что? Сравнить техники и их эффективность - можно. Ничему особо не противоречит. > Интереснее сравнение с подходом btrfs. Ибо процесс, используемый там тоже > совсем неоднозначный - дробление обычных экстентов на слайсы, т.н. bookend extents. Оно возникает только в достаточно специфичной ситуации как я понимаю, когда переписывается экстент снапшота или клонированного файла используемый в нескольких местах. И кстати я не вижу - где там лимит на размеры экстентов. Это просто тезническая операция для выкручивания из хитрой ситуации возможной за счет врайтабельных снапшотов и клонированных файлов, когда экстент юзавшийся несколькими сущностями вроде как был изменен и надо бы что-то сделать по этому поводу (в более простых реализациях этой затеи без клонирования файлов и записываемых снапшотов такая проблема просто не возникает, как я понимаю, ну а тут пришлось придумать как это разруливать). > Но, отсутствие последней в каком-либо серьезном продакшене не позволяет, > во всяком случае пока, это сделать. Не позволяет сделать что? Базовая часть btrfs уже более-менее стабильна.
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	171. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Wulf (??) on 28-Сен-11, 17:29
	> Базовая часть btrfs уже более-менее стабильна. Ожидание redhat-овцами готовности утилиты fsck для файловой системы, которая должна быть всегда консистентной "by design" говорит об обратном.
	Ответить | Правка | ^ к родителю #163 | Наверх | Cообщить модератору

	193. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 30-Сен-11, 05:20
	> Ожидание redhat-овцами готовности утилиты fsck для файловой системы, которая должна быть > всегда консистентной "by design" говорит об обратном. Должна но не обязана. В ряде случаев (например бэд сектор неудачно вылез) - может получиться так что консистентность все-таки нарушена и самой ФС не чинится, поскольку структуры ФС разрушены и более не консистентны. Характерный пример висит на лисяре, где товарисч переколупывал структуры ZFS вручную. В таком случае логично как раз иметь утиль которая сделает полный проход по всем структурам, проверит их на вменяемость, исправит откровенный левак или если невозможно то хотя-бы нейтрализует его до состояния в котором том (и вообще пул) можно смонтировать без приключений. Вообще, на каждый пшик пересобирать заново многодисковый массив и раскатывать на него бэкап - довольно утомительно и не прикольно. Особенно если пострадало по факту пара файлов не сильно важных, например. То что редхат меньше напирает на маркетинг и больше на технические моменты дает ему пять очков форы вперед перед санями, которые любили чрезмерно себя перехваливать, компенсируя технические упущения красивым маркетингом.
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	208. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Wulf (??) on 30-Сен-11, 13:24
	>> Ожидание redhat-овцами готовности утилиты fsck для файловой системы, которая должна быть >> всегда консистентной "by design" говорит об обратном. > Должна но не обязана. В ряде случаев (например бэд сектор неудачно вылез) > - может получиться так что консистентность все-таки нарушена и самой ФС > не чинится, поскольку структуры ФС разрушены и более не консистентны. Характерный > пример висит на лисяре, где товарисч переколупывал структуры ZFS вручную. Все постоянно ссылаются на один и тот-же пример с лисяры, где товарищ добил уже ранее деградировавший пул. Ну не повезло человеку, вернее ССЗБу, угробил из 3-х дисков в raid-е 2. И то, структуры он особо не переколупывал. Пытался просто откатить последние транзакции. Нынче для этого уже ключик -F к zpool import придумали для автоматизации процедуры. В > таком случае логично как раз иметь утиль которая сделает полный проход > по всем структурам, проверит их на вменяемость, исправит откровенный левак или > если невозможно то хотя-бы нейтрализует его до состояния в котором том > (и вообще пул) можно смонтировать без приключений. Да умеет ZFS это само, причем на лету. В zfs метаданные хранятся в 2-х экземплярах, а глобальные, вообще в 3-х. да еще и с контрольными суммами, причем сквозными для всей транзакции, т.е. ФС может в любой момент понять какая копия правильная.  И инициировать  принудительную проверку так-же легко одной командой. > Вообще, на каждый пшик пересобирать заново многодисковый массив и раскатывать на него > бэкап - довольно утомительно и не прикольно. Особенно если пострадало по > факту пара файлов не сильно важных, например. Если просто пострадали файлы, ZFS без проблем монтируется и работает в rw режиме без всяких ограничений. При этом еще и пишет в zpool status, какие конкретно файлы пострадали. Проверенно эксплуатацией машин с глючными sata-контроллерами. А убить несколько копий метаданных еще постараться надо. Хотя, согласен, у некоторых получалось. > То что редхат меньше > напирает на маркетинг и больше на технические моменты дает ему пять > очков форы вперед перед санями, которые любили чрезмерно себя перехваливать, компенсируя > технические упущения красивым маркетингом. Ну, ZFS это определенно не техническое упущение. Это флагман в своем классе. btrfs и hammer явно еще не успели стать взрослыми.
	Ответить | Правка | ^ к родителю #193 | Наверх | Cообщить модератору

	216. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 02-Окт-11, 21:36
	> Все постоянно ссылаются на один и тот-же пример с лисяры, где товарищ > добил уже ранее деградировавший пул. Ну не повезло человеку, вернее ССЗБу, Не вижу, что помешает тому чтобы такое же "везение" посетило и остальных. Как бы fsck и нужен в случае когда не повезло. RAIDы вообще очень надежны в теории, а при реальных непредсказуемых глюках оборудования и отказах - больше похоже на лотерею. Оборудование имеет свойство подыхать совсем не так как было задумано в RAID-ах, поэтому надеяться на то что слой RAID-а однозначно спасет - лично я бы не стал. Потому что прецеденты странной смерти оборудования - бывают. При этом бывает все что угодно и совсем не в том виде в каком было задумано :D. > угробил из 3-х дисков в raid-е 2. Я и более прикольные рассыпоны многодисковых рэйдов видал. Это у него еще так, ерунда. Обычный бэд, относительно безобидный сценарий. Бывает намного хуже. > И то, структуры он особо не переколупывал. Пытался просто откатить > последние транзакции. Нынче для этого уже ключик -F к zpool import придумали для автоматизации процедуры. Да-да, один конкретный сценарий - заткнули. Проблема только в том что таких сценариев - over 9000, и поэтому нормальный подход это утиль который сделает проход по метаданным, проверит их на вменяемость и исправит заведомо попорченные данные, перестроив их (if possible) или хотя-бы нейтрализует их до логически непротиворечивого состояния (почистит). Ну, чтобы можно было все это смонтировать по человечески и вынуть то что уцелело. На случай если нет актуального бэкапа или там что еще - must have. Тем более что ресторить 100500дисковый пул с бэкапа занимает туеву хучу времени. Идеальное решение - убрать с сбоящего диска данные (btrfs сие умеет, например), прогнать проверку, посмотреть чего побилось, воткнуть новый диск, отребалансить на него данные, восстановить из бэкапов то что пострадало. А то если из-за бэдов реально убилось только пару файлов - тупо раскатывать весь массив на 100500 дисков из бэкапа. Это ж долго и геморно что пипец. >> если невозможно то хотя-бы нейтрализует его до состояния в котором том >> (и вообще пул) можно смонтировать без приключений. > Да умеет ZFS это само, причем на лету. Проблема в том что fsck умеет (должен уметь) это намного лучше и продвинутее. Он может позволить себе именно техники анализа и перестройки/нейтрализации метаданных, которые геморно впихивать в драйвер ФС. А что там ZFS умеет - видно на примере пресловутого лисяры. Вот в таких случаях это должен быть универсальный пинок fsck который отколупает то что отколупывалось и сделает ФС монтируемой. > В zfs метаданные хранятся в 2-х экземплярах, а глобальные, вообще в 3-х. да еще и > с контрольными суммами, причем сквозными для всей транзакции, т.е. ФС может > в любой момент понять какая копия правильная.  И инициировать  принудительную > проверку так-же легко одной командой. Опять же, глюки бывают разные. А как насчет того что в каком-то локальном месте грохнется обе копии метаданных? Потому что гладиолус^W глюк случился именно вот так, а не как-то иначе? Ну допустим проверка даже обнаружит что там - опа. А дальше что? Хексэдитором в ФС, как парень с лисяры? Вот админам больше делать нефиг. > Если просто пострадали файлы, ZFS без проблем монтируется и работает в rw > режиме без всяких ограничений. Глюки как-то не очень выбирают где им вылезти, поэтому они могут и метаданные накрыть. Знаете какие чудеса например на диски пишутся если контроллер на котором пачка дисков висит немного подглючил раз в сто лет и половина пачки дисков ушло оффлайн а потом вернулось онлайн и так несколько раз, да еще с записью порции вермишели мимо цели? При таком для некоего файла могут оказаться испорчены вообще все копии метаданных. И чего? За хексэдитор? Или из-за 1-2 засранных файлов весь немеряный массив перераскатывать из бэкапа? > При этом еще и пишет в zpool status, какие конкретно файлы пострадали. > Проверенно эксплуатацией машин с глючными sata-контроллерами. > А убить несколько копий метаданных еще постараться надо. Хотя, согласен, у > некоторых получалось. При развале многодисковых конфигураций факап сразу по нескольким дискам - довольно частое явление природы. Особенно если взглюканул чипсет контроллера на котором висела куча дисков. RAID-ы при таких глюках имееют свойство эпично лажаться, т.к. на произвольный отвал группы дисков или запись порции левых данных на сразу несколько дисков они разумеется не рассчитаны. [...] >> технические упущения красивым маркетингом. > Ну, ZFS это определенно не техническое упущение. Это флагман в своем классе. > btrfs и hammer явно еще не успели стать взрослыми. Они были первыми, и этого не отнять. Но новые дизайны будут лучше. Потому что учтут старые упущения + им не надо держать совместимость с старым форматом или делать утили конверсии форматов. Это нормально, это жизнь.
	Ответить | Правка | ^ к родителю #208 | Наверх | Cообщить модератору

	217. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от iZEN (ok) on 02-Окт-11, 22:56
	>[оверквотинг удален] >> добил уже ранее деградировавший пул. Ну не повезло человеку, вернее ССЗБу, > Не вижу, что помешает тому чтобы такое же "везение" посетило и остальных. > Как бы fsck и нужен в случае когда не повезло. RAIDы > вообще очень надежны в теории, а при реальных непредсказуемых глюках оборудования > и отказах - больше похоже на лотерею. Оборудование имеет свойство подыхать > совсем не так как было задумано в RAID-ах, поэтому надеяться на > то что слой RAID-а однозначно спасет - лично я бы не > стал. Потому что прецеденты странной смерти оборудования - бывают. При этом > бывает все что угодно и совсем не в том виде в > каком было задумано :D. Да. Бывает на традиционных ФС, где ФС и менеджеры томов не знают о сквозной целостности данных, которые они обрабатывают и хранят. Типичный случай: рассинхронизация классического RAID-1. Кто знает, почему такое происходит довольно часто, что приходится периодически запускать специальную утилиту верификации от производителя RAID? Нет ответа. >[оверквотинг удален] >> И то, структуры он особо не переколупывал. Пытался просто откатить >> последние транзакции. Нынче для этого уже ключик -F к zpool import придумали для автоматизации процедуры. > Да-да, один конкретный сценарий - заткнули. Проблема только в том что таких > сценариев - over 9000, и поэтому нормальный подход это утиль который > сделает проход по метаданным, проверит их на вменяемость и исправит заведомо > попорченные данные, перестроив их (if possible) или хотя-бы нейтрализует их до > логически непротиворечивого состояния (почистит). Ну, чтобы можно было все это смонтировать > по человечески и вынуть то что уцелело. На случай если нет > актуального бэкапа или там что еще - must have. Это вы сейчас zpool scrub описали? > Тем более что ресторить 100500дисковый пул с бэкапа занимает туеву хучу времени. Опять же, для ZFS быстрее ресторить отдельную ФС из бэкапа, так как повреждения файлов локализуются в отдельных ФС. Восстановление отдельных ФС делается очень быстро — быстрее, чем поблочное копирование RAW-устройств, так как в бэкапных снимках сохраняются данные только файлов, а не тома. > Идеальное > решение - убрать с сбоящего диска данные (btrfs сие умеет, например), > прогнать проверку, посмотреть чего побилось, воткнуть новый диск, отребалансить на него > данные, восстановить из бэкапов то что пострадало. Что, Btrfs уже научилась самостоятельно RAID-5 без всяких посторонних менеджеров томов? > А то если из-за > бэдов реально убилось только пару файлов - тупо раскатывать весь массив > на 100500 дисков из бэкапа. Это ж долго и геморно что > пипец. zpool scrub в статусе проверенного пула как раз-таки сохраняет информацию о повреждённых файлах с полными путями к ним — легко восстановить из бэкапа. fsck обычных ФС (молитесь, чтобы в Btrfs было хоть какое-то подобие scrub) обычно складывает неидентифицированные файлы кучей в /lost+found. > Проблема в том что fsck умеет (должен уметь) это намного лучше и продвинутее. Так умеет или должен уметь? Назовите прецедент, где fsck восстановил из повреждённых файлов хотя бы один. Да ему наплевать на пользовательские данные — он ремотирует ФС, а найденные обломки сложит кучкой и всё. > Опять же, глюки бывают разные. А как насчет того что в каком-то локальном месте грохнется обе копии метаданных? А избыточность на что? В Mirror этих копий метаданных достаточно, чтобы определить, какие метаданные уцелели, а какие нет, заменить сбойные. То же самое с повреждёниями файлов на одном из резервируемых носителей — ZFS просто не отдаст неверные данные операционной системе, а восстановит их из уцелевших с одного из носителей (сделает резервную копию), на что традиционные ФС просто неспособны. Традиционные дешёвый аппаратный или программный RAID-1 со сбойным носителем будет отдавать мусор, пока не запустят утилиту верификации блоков данных RAID. > Глюки как-то не очень выбирают где им вылезти, поэтому они могут и > метаданные накрыть. Знаете какие чудеса например на диски пишутся если контроллер > на котором пачка дисков висит немного подглючил раз в сто лет > и половина пачки дисков ушло оффлайн а потом вернулось онлайн и > так несколько раз, да еще с записью порции вермишели мимо цели? Во-первых, давайте не разводить дискуссий, в которых прослеживается явное незнание матчасти по работе (испорченного, в том числе) пула. Во-вторых, сначала подтвердите свои измышления практикой: создайте собственные ZFS-пулы и поэкспериментируйте с ними. А то от вас очень много болтовни феерической глупости.
	Ответить | Правка | ^ к родителю #216 | Наверх | Cообщить модератору

	169. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 28-Сен-11, 17:19
	> но механика вся экстентная. http://www.dfrws.org/2009/proceedings/p99-beebe.pdf Указанный документ понимает под экстентом нечто свое собственное. В общем случае - они зачем-то называют кластер экстентом. Хотя обычно под ним понимают выносок файла, эти господа почему-то прикрутили его к понятию кластера или блока файловой систеы.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	127. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от тигар (ok) on 28-Сен-11, 09:40
	>> … вы сами придумали? > нет, многие бсдоиды тут орали, что если конфиги хуже — то нечего > с таким рылом соваться в зфс. орали, видимо, такие же "специалисты" как и Вы, либо другой вариант: Вы как "специалист" не поняли то, о чем они писали. там я выше уже попросил расказать для чего нужен LVM (своими словами), "не заметил я!" да?;)
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	145. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от ананим on 28-Сен-11, 13:32
	А также доки с системными требованиями всяких писибздей/соляр и тд. Какие уж там спецы, в кавычках или нет, вам виднее.
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	146. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от тигар (ok) on 28-Сен-11, 13:42
	> А также доки с системными требованиями всяких писибздей/соляр и тд. > Какие уж там спецы, в кавычках или нет, вам виднее. может даже есть чего показать в виде http* ?
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	149. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от ананим on 28-Сен-11, 14:15
	ещё как есть! тут же на этом сайте и обсуждали производительность zfs на pcbsd и офигенно так докопались до скрипта - если озу меньше 1GB, то zfs посылается. могу и повторить. а то мало-ли. вдруг ресурсов бздишнегу не хватает в своей системе разобраться. >Updated the PC-BSD install script to detect if the user is below 1GB of memory when trying to use ZFS, and stop them. >  echo "WARNING: ZFS was enabled, but the system does not have the required 1GB of memory!" >  echo "Please increase the memory to 1GB or above to install with ZFS." >  echo "You may still install normally with UFS2 or UFS2 + Journaling." http://trac.pcbsd.org/changeset/2962
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	150. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от тигар (ok) on 28-Сен-11, 14:34
	> ещё как есть! тут же на этом сайте и обсуждали производительность zfs > на pcbsd и офигенно так докопались до скрипта - если озу > меньше 1GB, то zfs посылается. > могу и повторить. а то мало-ли. вдруг ресурсов бздишнегу не хватает в > своей системе разобраться. >>Updated the PC-BSD install script to detect if the user is below 1GB of memory when trying to use ZFS, and stop them. >>  echo "WARNING: ZFS was enabled, but the system does not have the required 1GB of memory!" >>  echo "Please increase the memory to 1GB or above to install with ZFS." >>  echo "You may still install normally with UFS2 or UFS2 + Journaling." > http://trac.pcbsd.org/changeset/2962 спасибо поржал. только одного не понял: каким боком инсталляционный скрипт pc-bsd относится к FreeBSD и, тем более, к solaris ? и, в догонку, как Вы думаете... если убрать этот if система не поставится/не будет работать?;-) по поводу "вдруг ресурсов бздишнегу не хватает в своей системе разобраться": вера в линуксойдов у меня еще больше подорвалась, почему-то сплошь и рядом такие Специалисты как Вы отмечаются. Для Вас, например, какие-то плюшки/недостатки в убунту, напримеру, есть показатель что линукс это круто/говно? btw, я на 98% уверен, что у Вас либо виндовс7 либо убунту стоит на десктопе/ноуте, я прав?
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	151. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	–1 +/–
	Сообщение от ананим on 28-Сен-11, 14:44
	>спасибо поржал. только одного не понял: каким боком инсталляционный скрипт pc-bsd относится к FreeBSD и, тем более, к solaris ? вот такие они, крикуны от бздей - и я не я, и лошадь не моя, и в писибзд своя zfs со своими поэтессами. а в скрипт так, для смеху ограничения понаписали.
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	153. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Школьник (ok) on 28-Сен-11, 15:06
	PCBSD - это desktop-friendly дистрибутив, рассчитанный на начинающих, который по умолчанию ставит KDE4 со всякими akonadi, virtuoso и прочей порнографией. KDE4 в инсталляции по умолчанию - тот еще потребитель памяти. Логично, что разработчики PCBSD решили оградить себя от нытья "тормозит!"  умников, решивших взгромоздить одновременно ZFS и KDE4 на компьютеры с 512 Мб RAM. Никто же не говорит о том, что Linux'у нужно минимум 512 Мб памяти только потому, что в Ubuntu Installation System Requirements написано 512 Mb RAM? Это проблемы конкретно Ubuntu, и в первом случае - это проблемы конкретно PCBSD. Хотя мне по-прежнему непонятно, где сейчас найти компьютер, у которого нет 1Гб RAM. Это еще постараться ведь надо.
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	157. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	–2 +/–
	Сообщение от ананим on 28-Сен-11, 15:44
	>PCBSD - это desktop-friendly дистрибутив, рассчитанный на начинающих, я ж и говорю - там своя-своя, совсем друга zfs. и ниразу не фрибздишная. :D ну и конечно бздишнеги нихера не знают требования из доки самого производителя: >Ознакомьтесь со следующими требованиями к объемам для пула устройств хранения данных ZFS: >768 МБ – минимальный объем памяти, необходимый для установки корневой файловой системы ZFS. >Для оптимизации общей производительности ZFS рекомендуется использовать 1 ГБ памяти. >Рекомендуется использовать по крайней мере 16 ГБ дискового пространства. http://download.oracle.com/docs/cd/E19253-01/820-0836/gitgn/... вот под такими словами - орали, видимо, такие же "специалисты" как и Вы, либо другой вариант: Вы как "специалист" не поняли то, о чем они писали. - тигрёнок и останеться в аналах истории опеннета :D >Хотя мне по-прежнему непонятно, где сейчас найти компьютер, у которого нет 1Гб RAM. Это еще постараться ведь надо. это не повод его тратить. и тем более не аргумент. особенно если на том же ext4 сюда 4-е виртуалки влезут на хостинге. Или пару сотен самба-пользователей.
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	161. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Школьник (ok) on 28-Сен-11, 16:06
	> я ж и говорю - там своя-своя, совсем друга zfs. и ниразу > не фрибздишная. :D Повторю еще раз для тех, кто не умеет читать: там, кроме ZFS, куча других специфичных для десктопа потребителей памяти. > ну и конечно бздишнеги нихера не знают требования из доки самого производителя: >>Для оптимизации общей производительности ZFS рекомендуется использовать 1 ГБ памяти. Мне нужно разъяснить значение слова "рекомендуется"? >>Хотя мне по-прежнему непонятно, где сейчас найти компьютер, у которого нет 1Гб RAM. Это еще постараться ведь надо. > это не повод его тратить. Она будет тратиться под кэш, что дает нехилый прирост производительности. > на том же ext4 сюда 4-е виртуалки влезут на хостинге. Или > пару сотен самба-пользователей. А я потрачу дополнительные 800 рублей и точно также заведу 4 или больше виртуалок и 100500 самба-пользователей, только буду пользоваться нормальной ФС. Ну а ты на сэкономленные 800 рублей сможешь купить бочонок балтики :-)
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

	162. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	–2 +/–
	Сообщение от ананим on 28-Сен-11, 16:26
	>Повторю еще раз для тех, кто не умеет читать: там, кроме ZFS, куча других специфичных ну даже не смешно чесслово. lkz тех, кто не умеет считать - если операционка вся целиком на уфс ставится на 128Мб и только для zfs требует 1Gb, то эта куча вырождается только в одну - zfs. Ещё раз - в скрипте куча не указана: echo "Please increase the memory to 1GB or above to install with ZFS." >Мне нужно разъяснить значение слова "рекомендуется"? Вот требования этой файловой системы от производителя: >Ознакомьтесь со следующими требованиями к объемам для пула устройств хранения данных ZFS: >768 МБ – минимальный объем памяти, необходимый для установки корневой файловой системы ZFS. >Для оптимизации общей производительности ZFS рекомендуется использовать 1 ГБ памяти. >Рекомендуется использовать по крайней мере 16 ГБ дискового пространства. http://download.oracle.com/docs/cd/E19253-01/820-0836/gitgn/... нужно объяснять "минимальный объем памяти"? >Она будет тратиться под кэш, в линухе ВСЯ СВОБОДНАЯ память тратится под кэш. И он не требует "минимальный объем памяти". >А я потрачу дополнительные 800 рублей и точно также заведу 4 или больше виртуалок и 100500 самба-пользователей я ВСЕГДА смогу завести на 4 виртуалки или на 100500 самба-пользователей больше.
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

	190. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от iZEN (ok) on 29-Сен-11, 00:05
	>>Повторю еще раз для тех, кто не умеет читать: там, кроме ZFS, куча других специфичных > ну даже не смешно чесслово. lkz тех, кто не умеет считать - > если операционка вся целиком на уфс ставится на 128Мб и только > для zfs требует 1Gb, то эта куча вырождается только в одну > - zfs. Ещё раз - в скрипте куча не указана: > echo "Please increase the memory to 1GB or above to install with > ZFS." 1 Gb — это минимальные требования для развёртки ARC файловой системы ZFS, вообще-то. Что вы хотите доказать, что по этому показателю ZFS будет хуже всех традиционных ФС? Несомненно. Так и традиционные ФС до уровня ZFS не доросли пока. Ещё вопросы? > я ВСЕГДА смогу завести на 4 виртуалки или на 100500 самба-пользователей больше. А мы можем уместить миллионы одинаковых файловых наборов (для тех же виртуалок) в небольшом пространстве диска вследствие dedup'ликации ZFS, и что дальше?
	Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

	195. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (??) on 30-Сен-11, 05:23
	> А я потрачу дополнительные 800 рублей Хм... получается что у BSD выше TCO на 25 баксов/машину? :)
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

	205. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Школьник (ok) on 30-Сен-11, 11:28
	Только если не считать профит, который может быть получен от всяких плюшек ZFS типа дедупликации, компрессии, checksumming и т.д.
	Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

	43. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+2 +/–
	Сообщение от kshetragia (ok) on 27-Сен-11, 05:40
	>> зачем уходить с гнутого стека? Ради возможности не показывать свой код? > Разумеется. В технологическом плане BSD-системы вот уже несколько лет пытаются догнать > пингвина, но получается все хуже и хуже. Но технологическое отставание компенсируется > серьезными бонусами - прирученным сообществом (можно мягко и ненавязчиво задавать направления > развития) и возможностью спокойно использовать его труд в проприетарной продукции. Чо?... Кто кого догоняет... У вас какие-то неправильные пчелы.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	56. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	–2 +/–
	Сообщение от XPEH on 27-Сен-11, 09:22
	Это у вас какая-то другая реальность.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	59. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от user295 on 27-Сен-11, 09:47
	> Это у вас какая-то другая реальность. а ты раскажи про свою, сравним, у кого "реальность" реальнее;-)
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	82. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 27-Сен-11, 17:19
	> а ты раскажи про свою, сравним, у кого "реальность" реальнее;-) 8086 real mode. Реальнее некуда.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	121. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+1 +/–
	Сообщение от Клыкастый (ok) on 27-Сен-11, 23:08
	>> зачем уходить с гнутого стека? Ради возможности не показывать свой код? > Разумеется. В технологическом плане BSD-системы вот уже несколько лет пытаются догнать > пингвина, вы не с той стороны смотрите. переверните картинку
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	194. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Аноним (??) on 30-Сен-11, 05:22
	> вы не с той стороны смотрите. переверните картинку Расскажите это рамблеру и яндексу. А то их конский топот аж с хабрахабры слышно.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	218. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Клыкастый (ok) on 04-Окт-11, 14:14
	> Расскажите это рамблеру и яндексу. А то их конский топот аж с хабрахабры слышно. давайте подождём чуть-чуть и посмотрим статистику по серверам. кстати, переход с FreeBSD на Linux на моей практике происходит по одному и тому же сценарию. Сначала из команды разработчиков вымываются программисты. И набираются ОЦК (особоценныекадры), которые не в состоянии делать элементарные с точки зрения программирования вещи. А те, ктоторые умеют делать, не умеют делать хорошо. Затем начинается поиск причин возникших проблем. После чего появляются Linux и в комплекте пионэр с минимильным его (Linux-а) знанием. Поймите меня правильно, я не с целью там как-то унизить Linux, мне лично не нравится тенденция. Но связь очевидна, к сожалению: переход на Линукс и деградация команды идут параллельно. Буду рад, если где-то не так. Но "не так" мне лично не встречалось.
	Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

	219. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Andrey Mitrofanov on 04-Окт-11, 14:22
	...может, во FreeBSD что-то поправить?... X)
	Ответить | Правка | ^ к родителю #218 | Наверх | Cообщить модератору

	220. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от Клыкастый (ok) on 04-Окт-11, 14:47
	> ...может, во FreeBSD что-то поправить?... X) Вы что-то конкретное имеете в виду, или это непроизвольные выкрики?
	Ответить | Правка | ^ к родителю #219 | Наверх | Cообщить модератору

54. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
Сообщение от midori (ok) on 27-Сен-11, 08:13
а может, все это связано с Днем рождения Google - ему сегодня 13!)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

116. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
Сообщение от Аноним (??) on 27-Сен-11, 22:34
Лучше бы они utf-8 в коробку засунули.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	131. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	+/–
	Сообщение от 1 (??) on 28-Сен-11, 09:53
	что это даст?
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	164. "FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..."	–1 +/–
	Сообщение от Аноним (??) on 28-Сен-11, 16:33
	> что это даст? +1 к ЧСВ таких как вы :)
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

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

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