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

FreeBSD Foundation профинансирует доработку DIFFUSE и реализ..., opennews (?), 26-Сен-11, (0) [смотреть все] Реквестую название FreeBSD X , Зловред (?), 21:38 , 26-Сен-11, (1) +17 // FreeBSD OS X c 1993-2011 Apple Inc , Аноним (-), 22:08 , 26-Сен-11, (8) +6 Патентные иски от эппла - в нагрузку , Аноним (-), 23:19 , 26-Сен-11, (14) –3 // Зачем им рубить сук, на котором они сидят Правильно, Леня, мы - партнеры с , Аноним (-), 23:58 , 26-Сен-11, (20) // Леня, ты халявщик такое тоже было , kombat (ok), 05:06 , 27-Сен-11, (42) Apple активный партнёр, FreeBSD пассивный , СуперАноним (?), 08:04 , 27-Сен-11, (53) –1 Ага, патенты на цифры Глупости-то уж не надо - , Ян Злобин (ok), 07:44 , 27-Сен-11, (48) // Все еще впереди Уже существуют запрещенные числа, за публикацию которых копирас, Аноним (-), 08:00 , 27-Сен-11, (52) –1 не перл-код , а ключ, невежда , anonymous (??), 12:06 , 27-Сен-11, (62) +1 Пусть подадут в суд на Mitsubishi - во смеху-то будет , Александр (??), 16:57 , 27-Сен-11, (76) +1 // На Тошибу Чтобы окончательно сорвать себе поставки DRAM и NAND , Аноним (-), 17:06 , 27-Сен-11, (78) Чувак вообще не в теме, лол, Аноним (-), 18:17 , 27-Сен-11, (91) Такими темпами FreeBSD станет карманным проектом Эппла , Аноним (-), 21:39 , 26-Сен-11, (2) +1 // а оно и было таковым, VKraft (?), 21:45 , 26-Сен-11, (3) +1 // Одного угробленного дарвина им мало , Аноним (-), 23:23 , 26-Сен-11, (15) // угробленного D, анонимус (??), 06:39 , 27-Сен-11, (46) Да, открытый вариант оного практически сдох - комьюнити разработчиков нету , Аноним (-), 12:56 , 27-Сен-11, (69) обоснуйте, Клыкастый (ok), 23:02 , 27-Сен-11, (119) Насчет DIFFUSE - похоже, все-таки торчат уши Жунипера, яблоку эта тематика не ос, Аноним (-), 21:51 , 26-Сен-11, (4) // По ссылке ходить пробовали This project began in June 2010 and has been made , Аноним (-), 18:22 , 27-Сен-11, (92) Некоторые компании используют двойную систему распространения своего ПО открыта, Аноним (-), 22:01 , 26-Сен-11, (5) +2 // кто например , predator (ok), 22:44 , 26-Сен-11, (12) +3 Удобна Смотря для кого Уж явно не для тех кто внедрит а потом ему и скажут - о, Аноним (-), 23:25 , 26-Сен-11, (17) // На мой взгляд, вполне справедливый метод заработка За роскошь надо платить , Аноним (-), 23:57 , 26-Сен-11, (19) За свою роскошь менеджеры корпорация платят из вашего кармана, а программерам ко, runoverheads (ok), 02:48 , 27-Сен-11, (40) +2 конечно 171 пилите, Шура, пилите 8212 они золотые 187 при такой модели н, anonymous (??), 12:10 , 27-Сен-11, (63) А потом эти господа еще и удивояются кога яндексы и рамблеры выдают характерные , Аноним (-), 17:08 , 27-Сен-11, (79) Ага, а вся команда ядерщиков на всю толпу кой-как наскребает 200к в год, едва св, Аноним (-), 17:22 , 27-Сен-11, (83) Что-то я не понял из высказывания, вы за модель развития по сценарию MySQL и Jav, iZEN (ok), 00:15 , 27-Сен-11, (21) Я бы предпочел, только где их взять приведенные тандемы в обмене ништяками зам, Аноним (-), 00:20 , 27-Сен-11, (22) +1 Эх, мечтатели Apple - вовсе не IBM , Аноним (-), 00:30 , 27-Сен-11, (23) написано так, как будто базовая Java не несет бОльшую часть реально нужных фич , VoDA (ok), 08:45 , 27-Сен-11, (55) DIFFUSE интересная вещь ждем , freename (ok), 22:06 , 26-Сен-11, (6) // Мне вот интересно, а кто ее пробовал в реальной практике Насколько точное обу, artemrts (ok), 23:03 , 26-Сен-11, (13) // Мне кажется, что отрабатывать бинарной логикой allow deny на статистические св, Andrew Kolchoogin (?), 23:24 , 26-Сен-11, (16) Идея DIFFUSE настолько оторвана от привычных сетевых задач, что ее возникновение, Аноним (-), 00:36 , 27-Сен-11, (24) +1 // Скорее всего Juniper ом Вообще не понимаю причем тут Эппл в комментариях выше у, Ищавин (?), 00:50 , 27-Сен-11, (25) а вот тут хотелось бы поподробнее насколько я знаю оно уже в не таком далеком , fidaj (ok), 01:27 , 27-Сен-11, (28) В начале 2009 Им стало влом потом писать plist ы для тонны софта и они не знали, Ищавин (?), 13:18 , 27-Сен-11, (70) я посмотрел по git-ам svn-ам - последние движения были датированы 2009-ым то ч, fidaj (ok), 13:29 , 27-Сен-11, (71) Собирались, если быть точным Мечтателей там дофига, а разработчиков полтора чел, Аноним (-), 02:23 , 27-Сен-11, (32) А еще был с помпой представлен порт на AVR32 А еще был сделан порт на DIR320 И, Аноним (-), 17:26 , 27-Сен-11, (84) Привычная такая сетевая задача классифицировать трафик по его поведению 8212, iZEN (ok), 01:36 , 27-Сен-11, (29) для этого достаточно cisco sce cisco csg iZEN, ты глупости бы не говорил, а , Добрый Дохтур (?), 01:55 , 27-Сен-11, (30) Вот я и говорю, что Ростелекому не по плечу оказалась DPI 8212 надо придумать, iZEN (ok), 02:23 , 27-Сен-11, (31) Ой, да вы, оказывается, инсайдер из Ростелекома Извините, не признали сразу Кон, Аноним (-), 02:33 , 27-Сен-11, (35) Кому что, а лысому - расчёска Только неуёмное помешательство на FreeBSD и парано, www2 (??), 07:50 , 27-Сен-11, (49) Походу многих смущает термин классификации трафика на основании статистических , Аноним (-), 17:42 , 27-Сен-11, (87) 1 А зачем вообще это ограничивать 2 Неужто ipfw настолько топор что число syn, Аноним (-), 00:25 , 28-Сен-11, (125) Вроде в 8ке только общее количество коннектов А никак не во времени Да была т, Аноним (-), 13:11 , 28-Сен-11, (143) Ппц, а в лине можно например отмаркировать все syn-пакеты иптаблезом как неки, Аноним (-), 15:49 , 28-Сен-11, (158) Ура, циска раздаёт куски IOS , AHAHAC (ok), 00:56 , 27-Сен-11, (26) –1 зачем уходить с гнутого стека Ради возможности не показывать свой код , Vernat (ok), 01:19 , 27-Сен-11, (27) –5 // Разумеется В технологическом плане BSD-системы вот уже несколько лет пытаются д, Аноним (-), 02:28 , 27-Сен-11, (33) –7 // Я что-то пропустил, Red Hat, Oracle, CISCO отказываются от пингвина в пользу BSD, iZEN (ok), 02:32 , 27-Сен-11, (34) +2 // Насчет пропустили - не знаю, но трава у вас хорошая Отсыплете , Аноним (-), 02:35 , 27-Сен-11, (36) Это же изен Он доставляет Лулзы в основном , Аноним (-), 17:11 , 27-Сен-11, (80) Редхату и Ораклу проще открывать код, чем пытаться дотянуть BSD до пингвиньего , Аноним (-), 02:39 , 27-Сен-11, (37) –1 В больших цисках типа ASR грузится Линух, и поверх запускается IOS который уже и, Diden05 (ok), 17:58 , 27-Сен-11, (89) BtrFS допилите, тогда и поговорим А то сколько было словесного грохота Не нужн, Andrew Kolchoogin (?), 02:40 , 27-Сен-11, (38) +3   // До уровня ZFS недо-рейд, не умеющий добавлять диски в пятый и шестой уровень, , Аноним (-), 02:47 , 27-Сен-11, (39) –4   Вообще это такой посттравматический синдром долгие годы во фре не было нормальн, Аноним (-), 02:56 , 27-Сен-11, (41) –5   снимая лапшу с ушей Вы когда-нибудь Фрюшу живую видели , kshetragia (ok), 05:43 , 27-Сен-11, (44)   А что не так Если отбросить подаренный FreeBSD ZFS и совсем недавно появившееся, www2 (??), 07:57 , 27-Сен-11, (50)   а в голой ufs есть снепшоты, без вашего этого lvm где они есть работают ли они, user295 (?), 09:45 , 27-Сен-11, (58)   прикинь, а без ядра вообще никакой софт не работает а без tar и gzip tgz-тарбол, anonymous (??), 12:19 , 27-Сен-11, (64)   Красноглазым уже тысячи раз объясняли, чем плохи снэпшоты на уровне LVM, но они , Школьник (ok), 16:33 , 27-Сен-11, (74) +3   А школьники так и не догнали что UFS с своими снапшотами - не сильно лучше Норм, Аноним (-), 17:30 , 27-Сен-11, (85) –3   Конкретные недостатки работы snapshots в UFS2 - в студию Тезисы об окаменелых , Школьник (ok), 17:54 , 27-Сен-11, (88) +2   Лучше поставить вопрос иначе придумайте хоть одно достоинство этого костыля Са, Аноним (-), 18:50 , 27-Сен-11, (94)   Если почитать умную книжку разработчиков FreeBSD на момент выхода FreeBSD 5 2, т, iZEN (ok), 20:48 , 27-Сен-11, (112)   Когда тут с месяц назад интервью с разрабами бзд было и тот, что лояльный к бзд,, ананим (?), 22:55 , 27-Сен-11, (118) –2   LVM снапшоты так-то до сих пор на уровне dd остались, юзабельными назвать язык н, 1 (??), 09:42 , 28-Сен-11, (128) –1   Вот по это хавтухе http wiki samba org index php Script работает файловый серв, ананим (?), 11:56 , 28-Сен-11, (139)   А ты попробуй сделать снапшот ФС с файлами базы данных Например, MySQL ISAM хо, Школьник (ok), 12:24 , 28-Сен-11, (140)   Без блокировки и в уфс нельзя И в зфс нельзя Прикинь новость DИ если уж мне де, ананим (?), 12:49 , 28-Сен-11, (142)   Да, тут я действительно сморозил глупость Наверное, потому, что в ZFS записываем, Школьник (ok), 14:51 , 28-Сен-11, (152)   поверьте, снэпшоты в оракловом решении - 100500 место по важности Dпочитайте по, ананим (?), 15:29 , 28-Сен-11, (154)   Прочитал А какой смысл сравнивать специализированное решение для хранения файло, Школьник (ok), 18:11 , 28-Сен-11, (177)   да хоть с чем угодно сравнивайте Один ой вы уже сказали, второй ой ocfs2 в в, ананим (?), 19:42 , 28-Сен-11, (183)   Оракл вообще бсд как платформу для своих БД не рассматривает , Аноним (-), 05:56 , 30-Сен-11, (199)   В btrfs есть и записываемые снапшоты и клоны файлов, когда файл расщепляется на , Аноним (-), 05:55 , 30-Сен-11, (198)   1 Я рад за btrfs Только мне по-прежнему не видно его особых преимуществ перед , Школьник (ok), 10:36 , 30-Сен-11, (203)   У XFS отдельно доставляются утилиты поддержки инкрементных снапшотов xfsdump xfs, iZEN (ok), 23:50 , 28-Сен-11, (189)   ещё раз - прочитайте что вот это http wiki samba org index php Scrip делает, з, айзинка (?), 07:18 , 30-Сен-11, (200)   Это как И при чем тут dd вообще Сколько вам за чмыреж пингвина платят Мне, пра, Аноним (-), 15:50 , 28-Сен-11, (160)   Никто не чмырит пингвина лучше его community с зашкаливающим количеством красног, Школьник (ok), 17:59 , 28-Сен-11, (176)   Это видимо про Школьник и FreeBSD было Ник удивительно соответствует содержанию, Аноним (-), 00:32 , 30-Сен-11, (191)   Когда аргументов не остается, тогда начинают переходить к никам, вспоминают про , Школьник (ok), 11:33 , 30-Сен-11, (206)   А если почитать и другие ресурсы, можно узнать что в UFS не стали переделывать б, Аноним (-), 10:49 , 28-Сен-11, (133)   Немедленно в студию аналог команды zfs rollback на LVM2 P S User294, хватит фи, iZEN (ok), 23:34 , 28-Сен-11, (187)   Нет, дорогой наш User294 Тезис о том, что этот тезис - твой, так что тебе, Школьник (ok), 17:51 , 28-Сен-11, (174)   http www opennet ru opennews art shtml num 3161529 08 2011 13 13 Два интервью, айзинка (?), 07:36 , 30-Сен-11, (201)   Т е из-за того, что journaling там сырой, сразу следует то, что UFS окаменела , Школьник (ok), 10:27 , 30-Сен-11, (202)   манера выражаться у тебя как раз как у красноглазых администраторов общажных сер, айзинка (?), 15:58 , 30-Сен-11, (209)   У меня отличная манера выражаться Модератор пропускает, по крайней мере Не нра, Школьник (ok), 16:18 , 30-Сен-11, (210) +1   А чего там доказывать Идете в гугл Гуглите результаты бенчмарков Ффтыкаете П, Аноним (-), 19:52 , 02-Окт-11, (213)   А конструктивно тут недавно новость разработчиков бсд из снг была, так один код , ананим (?), 22:48 , 27-Сен-11, (117) –4   читали-читали, читали-читали, да не вычитали приходите сюда, когда читать научи, Аноним (-), 19:19 , 28-Сен-11, (182)   Угу, только вот у этих школьников нормально реализованы бекапы через эти не сил, Аноним (-), 19:46 , 27-Сен-11, (101) +3   угу 171 вылаживали 187 8212 это от слова 171 лажа 187 , anonymous (??), 20:02 , 27-Сен-11, (104)   а по делу , Аноним (-), 20:53 , 27-Сен-11, (113)   А по делу - тут и советы как починить битые снэпшоты тоже были И чё Зыжбэкапы - , ананим (?), 23:11 , 27-Сен-11, (122)   Бздуны тоже имхо не знают как делать через llvm бэкапы Вообще, сделать бэкап че, Аноним (-), 20:22 , 27-Сен-11, (107)   Тем, что они невозможны И до сих пор считают, что работающую базу данных можно , Andrew Kolchoogin (?), 16:58 , 27-Сен-11, (77)   Нормально Бсдшник рассказывает бсдшнику о тос что в линуксе невозможны LVM снап, Аноним (-), 18:23 , 27-Сен-11, (93)   я так понимаю, бсдовые снапшоты эту проблему посностью исключают, и базу можно к, anonymous (??), 19:02 , 27-Сен-11, (97)   Представьте себе, при бекапах через снапшеты, базу нужно фризить не на весь цикл, Аноним (-), 19:49 , 27-Сен-11, (102)   А можно оформить эту мыслю как-нибудь понаучнее, в виде названий системных вызов, Аноним (-), 20:28 , 27-Сен-11, (109)   можно цикл копи-паста базы время копирование БД , Аноним (-), 21:02 , 27-Сен-11, (114)   А, я кажется врубился что вы хотели сказать Простите, а ничего что это самое ве, Аноним (-), 11:05 , 28-Сен-11, (135)   Прощаю Да, вы сказали все верно, вот только ветку вы не читали, и к чему я это , Аноним (-), 19:04 , 28-Сен-11, (180)   а когда там в линуксах снепшоты фс реализовали без лвм этой бесполезной а рабо, user295 (?), 09:44 , 27-Сен-11, (57)   мантра юзера бсд 171 всё, что в бсд не смогли портировать 8212 бесполезно , anonymous (??), 12:20 , 27-Сен-11, (65) –2   это все что ты смог вымучать из себя между тем, вопрос задан правильный , тигар (ok), 12:31 , 27-Сен-11, (66) +1   неа правильный вопрос будет таким 171 а когда уже в бсд появится инструмент,, anonymous (??), 12:41 , 27-Сен-11, (67)   видишь ли fs которые есть во фре умеют делать снепшоты сами, без привлечения , тигар (ok), 12:51 , 27-Сен-11, (68) +1   Это пользователи геома и нетграфа будут про абстракции рассказывать, угу Лицеме, Аноним (-), 18:51 , 27-Сен-11, (95) +1   при наличии 2 FS необходимость в таком инструменте кажется надуманой , Клыкастый (ok), 19:28 , 04-Окт-11, (221)   тоже правильно, там же и особого выбора между разными FS нет очевидно, потому, , anonymous (??), 19:39 , 04-Окт-11, (222)   Ну вот про виртуализацию они это уже пробовали рассказывать Яндекс их не понял , Аноним (-), 16:55 , 28-Сен-11, (165)   Ну вот вот Мэтью Диллон в DragonFlyBSD написал в одиночку с нуля новую фс, HAMME, Аноним (-), 19:09 , 28-Сен-11, (181)   Приставка недо к zfs не подходит, не какие RAID LVM XFS nilfs2 ext4 нельзя ср, freename (ok), 05:43 , 27-Сен-11, (45) +4   А вот в чём разница evms с lvm Пытался за пять секунд найти отличия и области п, Аноним (-), 07:35 , 27-Сен-11, (47)   В том, что она сводила все дисково-файловосистемные технологии Linux воедино и п, www2 (??), 07:59 , 27-Сен-11, (51)   спасибо , Аноним (-), 10:18 , 27-Сен-11, (60)   хех Пытаясь найти что-нибудь новое по evms наткнулся на одну интересную статью , Аноним (-), 10:39 , 27-Сен-11, (61)   проект похоронен окончательно все бывшие разработчики распущенны ibm, есть небол, freename (ok), 19:44 , 27-Сен-11, (100)   Да там в тексте так и написано , Аноним (-), 07:37 , 28-Сен-11, (126)   Нормально, бенчмарки - не нужны Мы на глазок померим как настоящие джедаи , Аноним (-), 16:56 , 28-Сен-11, (166)   Вы не вполне хорошо себе представляете, зачем компьютеру ОЗУ Если ваша любимая с, Andrew Kolchoogin (?), 13:31 , 27-Сен-11, (72) +2   что там работают процессы а вот если для работы фс нужен минимум 1Гб и 64-битное, айзинка (?), 16:19 , 27-Сен-11, (73) –1   вы сами придумали , Andrew Kolchoogin (?), 16:56 , 27-Сен-11, (75) +1   нет, многие бсдоиды тут орали, что если конфиги хуже 8212 то нечего с таким р, anonymous (??), 19:08 , 27-Сен-11, (99)   zfs на такой конфигурации работать будет, но просто это бестолково, на основные , freename (ok), 19:54 , 27-Сен-11, (103)   ч т д 8212 zfs на серверах не нужен, потому что отбирает ресурсы, которые ну, anonymous (??), 20:05 , 27-Сен-11, (106) –1   Хоть ты и редиска, но в логическую ловушку поймал наивного бздуна технично Epic, Аноним (-), 20:34 , 27-Сен-11, (111) –2   На самом деле, красноглазые про себя говорят куда более красноречивее freename , Школьник (ok), 23:37 , 27-Сен-11, (123) +2   все верно, только с поправкой на то что Linux вообще кроме школ никуда не годитс, 1 (??), 09:50 , 28-Сен-11, (130)   Ага, вон в топ500 весьма лютая шк0л0та засела На LSE и еще пачке бирж - тоже Ц, Аноним (-), 11:08 , 28-Сен-11, (136)   опять простыня бреда и попаболи, перемешаная с киданием пальцев в то время, как, anonymous (??), 18:45 , 28-Сен-11, (179) –2   Ну гордись, гордись дальше тем, что твой линукс запускается на процессорах класс, Школьник (ok), 20:38 , 28-Сен-11, (184) –1   да чем тут 171 гордиться 187 это для бсд 171 новая фс, теперь с журналами, anonymous (??), 20:54 , 28-Сен-11, (185)   Это потому что в линуксовых ФС нет новых фич Есть btrfs, которую до продакшна в, Школьник (ok), 20:58 , 28-Сен-11, (186)   А фрю тоже как ынтырпрайзный NAS не больно то применяют Более того - если вы ра, Аноним (-), 05:45 , 30-Сен-11, (197)   А причем здесь FreeBSD Я, вообще говоря, сторонник разумного выбора инструмента, Школьник (ok), 11:26 , 30-Сен-11, (204)   Да, конечно - в силу довольно горбатого дизайна структур zfs без огроменного буф, Аноним (-), 20:32 , 27-Сен-11, (110)   отчасти zfs создана с заделом на будующие технологии, вы посмотрите тесты произв, freename (ok), 21:38 , 27-Сен-11, (115)   А на SSD знаете ли и другие не тормозят Это заслуга малого seek time А вот ове, Аноним (-), 11:22 , 28-Сен-11, (138)   Разве А ZFS L2ARC на MLC SSD для кэширования уже не в моде А ещё ZIL размещают, iZEN (ok), 23:41 , 28-Сен-11, (188)   Знаешь, проблема в том что другие ФС размещенные на SSD тоже довольно быстро раб, Аноним (-), 05:42 , 30-Сен-11, (196)   Бегают, пока не нарвались на частичную деградацию флэшатины В ZFS этот факт , iZEN (ok), 16:47 , 30-Сен-11, (211)   в зфс таки вмонтировали libastral круто обожаю, когда изен поутру чушь несёт , anonymous (??), 16:48 , 30-Сен-11, (212)   Ага, на лисяре можно посмотреть как перец бэды локализовывал, педаля структуры Z, Аноним (-), 20:01 , 02-Окт-11, (214)   Откуда вы все такие беретесь, анонимные авторы оксюморонов Какое ПТУ вас произв, Wulf (??), 00:16 , 28-Сен-11, (124) +2   Действительно, идиотизм с битмапами влобешник там убит Но проблема в том что э, Аноним (-), 11:19 , 28-Сен-11, (137)   Сравнение с ext4 вообще не катит - там нет COWИнтереснее сравнение с подходом bt, Wulf (??), 12:32 , 28-Сен-11, (141)   в общем и эктентов достаточно настоящих с битмэпами и деревьями которые очень , ананим (?), 13:28 , 28-Сен-11, (144)   На кого ее btrfs Не верю с , Wulf (??), 14:05 , 28-Сен-11, (147)   Речь о ext4 Очевидно же Но если мьсе не читатель , ананим (?), 14:12 , 28-Сен-11, (148)   Речь о том что ФС с COW бессмысленно сравнивать по типичному размеру экстента с , Wulf (??), 15:40 , 28-Сен-11, (156)   согласитесь, любые фс можно сравнивать по эффективности выполняемой ею работы ну, ананим (?), 15:50 , 28-Сен-11, (159)   а именно такие и в ext4, и в бтр Понятно, а в ZFS они ненастоящие , без битмап, Wulf (??), 17:10 , 28-Сен-11, (168)   Да, но если мы пишем например 100-меговый кус файла, размер экстента все-таки мо, Аноним (-), 17:02 , 28-Сен-11, (167)   На диск информация скидывается все-равно раз в 30 сек При этом все изменения об, Wulf (??), 17:25 , 28-Сен-11, (170)   Все-равно оверхеда будет здорово больше И на операции в памяти, и на сохранение, Аноним (-), 04:44 , 30-Сен-11, (192)   Вкатить 1 х 100Мб кусок - Это сфероконь в вакууме В реальности основные задачи,, Wulf (??), 12:52 , 30-Сен-11, (207)   Как бы от задачи сильно зависит ZFS почему-то на этих задачах ничего такого инте, Аноним (-), 21:05 , 02-Окт-11, (215)   И что Сравнить техники и их эффективность - можно Ничему особо не противоречит, Аноним (-), 16:31 , 28-Сен-11, (163)   Ожидание redhat-овцами готовности утилиты fsck для файловой системы, которая дол, Wulf (??), 17:29 , 28-Сен-11, (171)   Должна но не обязана В ряде случаев например бэд сектор неудачно вылез - може, Аноним (-), 05:20 , 30-Сен-11, (193)   Все постоянно ссылаются на один и тот-же пример с лисяры, где товарищ добил уже , Wulf (??), 13:24 , 30-Сен-11, (208)   Не вижу, что помешает тому чтобы такое же везение посетило и остальных Как бы, Аноним (-), 21:36 , 02-Окт-11, (216)   gt оверквотинг удален Да Бывает на традиционных ФС, где ФС и менеджеры томов , iZEN (ok), 22:56 , 02-Окт-11, (217)   Указанный документ понимает под экстентом нечто свое собственное В общем случае, Аноним (-), 17:19 , 28-Сен-11, (169)   орали, видимо, такие же специалисты как и Вы, либо другой вариант Вы как спе, тигар (ok), 09:40 , 28-Сен-11, (127)   А также доки с системными требованиями всяких писибздей соляр и тд Какие уж там , ананим (?), 13:32 , 28-Сен-11, (145)   может даже есть чего показать в виде http , тигар (ok), 13:42 , 28-Сен-11, (146)   ещё как есть тут же на этом сайте и обсуждали производительность zfs на pcbsd и, ананим (?), 14:15 , 28-Сен-11, (149)   спасибо поржал только одного не понял каким боком инсталляционный скрипт pc-bs, тигар (ok), 14:34 , 28-Сен-11, (150)   вот такие они, крикуны от бздей - и я не я, и лошадь не моя, и в писибзд своя zf, ананим (?), 14:44 , 28-Сен-11, (151) –1   PCBSD - это desktop-friendly дистрибутив, рассчитанный на начинающих, который по, Школьник (ok), 15:06 , 28-Сен-11, (153)   я ж и говорю - там своя-своя, совсем друга zfs и ниразу не фрибздишная Dну и , ананим (?), 15:44 , 28-Сен-11, (157) –2   Повторю еще раз для тех, кто не умеет читать там, кроме ZFS, куча других специф, Школьник (ok), 16:06 , 28-Сен-11, (161)   ну даже не смешно чесслово lkz тех, кто не умеет считать - если операционка вся, ананим (?), 16:26 , 28-Сен-11, (162) –2   1 Gb 8212 это минимальные требования для развёртки ARC файловой системы ZFS, , iZEN (ok), 00:05 , 29-Сен-11, (190)   Хм получается что у BSD выше TCO на 25 баксов машину , Аноним (-), 05:23 , 30-Сен-11, (195)   Только если не считать профит, который может быть получен от всяких плюшек ZFS т, Школьник (ok), 11:28 , 30-Сен-11, (205)   Чо Кто кого догоняет У вас какие-то неправильные пчелы , kshetragia (ok), 05:40 , 27-Сен-11, (43) +2 // Это у вас какая-то другая реальность , XPEH (?), 09:22 , 27-Сен-11, (56) –2 а ты раскажи про свою, сравним, у кого реальность реальнее - , user295 (?), 09:47 , 27-Сен-11, (59) 8086 real mode Реальнее некуда , Аноним (-), 17:19 , 27-Сен-11, (82) вы не с той стороны смотрите переверните картинку, Клыкастый (ok), 23:08 , 27-Сен-11, (121) +1 // Расскажите это рамблеру и яндексу А то их конский топот аж с хабрахабры слышно , Аноним (-), 05:22 , 30-Сен-11, (194) давайте подождём чуть-чуть и посмотрим статистику по серверам кстати, переход с, Клыкастый (ok), 14:14 , 04-Окт-11, (218) может, во FreeBSD что-то поправить X , Andrey Mitrofanov (?), 14:22 , 04-Окт-11, (219) Вы что-то конкретное имеете в виду, или это непроизвольные выкрики , Клыкастый (ok), 14:47 , 04-Окт-11, (220) а может, все это связано с Днем рождения Google - ему сегодня 13 , midori (ok), 08:13 , 27-Сен-11, (54) Лучше бы они utf-8 в коробку засунули , Аноним (-), 22:34 , 27-Сен-11, (116) // что это даст , 1 (??), 09:53 , 28-Сен-11, (131) // 1 к ЧСВ таких как вы , Аноним (-), 16:33 , 28-Сен-11, (164) –1 1,2,6,26,27,54,116

Сообщения

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

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

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

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

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

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

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

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

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

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

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

	94. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (-), 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 уже отменили? Не, если у кого зад просит приключений с свежаком и патчами - это вариант, но можно же и без острых ощущений, а?
	Ответить | Правка | Наверх | Cообщить модератору

	112. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от iZEN (ok), 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 +/–
	Сообщение от ананим (?), 27-Сен-11, 22:55
	Когда тут с месяц назад интервью с разрабами бзд было и тот, что лояльный к бзд, назвал код уфс явно сырым, то айзен помалкивал. хрена ли, это не фс писать. тут и потролячить можно.
	Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	213. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от Аноним (-), 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 +/–
	Сообщение от ананим (?), 27-Сен-11, 22:48
	А конструктивно тут недавно новость разработчиков бсд из снг была, так один код ufs сырым назвал, а второй так вообще всё раскритиковал. вывод - в попу фенечки, она хоть файлы сохранять умеет? Запор даже тюнингованный запором останется, уши всё-равно торчат.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	123. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+2 +/–
	Сообщение от Школьник (ok), 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 (??), 28-Сен-11, 09:50
	все верно, только с поправкой на то что Linux вообще кроме школ никуда не годится пока
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	149. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от ананим (?), 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
	Ответить | Правка | Наверх | Cообщить модератору

	150. "FreeBSD Foundation профинансирует доработку DIFFUSE и..."	+/–
	Сообщение от тигар (ok), 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 либо убунту стоит на десктопе/ноуте, я прав?
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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