https://opennet.ru/openforum/vsluhforumID3/80482.html Организация FreeBSD Foundation объявила (http://freebsdfoundation.blogspot.com/) о выделении денежных грантов на развитие двух (http://freebsdfoundation.blogspot.com/2011/09/diffuse-for-freebsd.html) проектов (http://freebsdfoundation.blogspot.com/2011/09/implementing-xlocale-apis.html):<br><br><br><br>- В октябре планируется (http://freebsdfoundation.blogspot.com/2011/09/diffuse-for-freebsd.html) довести до готовности к интеграции с деревом исходных текстов FreeBSD проекта DIFFUSE (http://caia.swin.edu.au/urp/diffuse/) (DIstributed Firewall and Flow-shaper Using Statistical Evidence), добавляющего в пакетный фильтр IPFW функции классификации трафика на основании статистических параметров потоков данных, отслеживаемых в режиме реального времени на одном или нескольких узлах. Иными словами, для классификации трафика DIFFUSE оперирует не параметрами в заголовках пакетов и не анализом содержимого передаваемых в пакетах данных, а статистическими характеристиками потока, свойственными определенным...<br><br>URL: http://freebsd https://opennet.ru/openforum/vsluhforumID3/80482.html#222 Tue, 04 Oct 2011 15:39:12 GMT &gt; при наличии 2 FS необходимость в таком инструменте кажется надуманой.<br><br>тоже правильно, там же и особого выбора между разными FS нет. очевидно, потому, что все остальные FS не нужны.<br> https://opennet.ru/openforum/vsluhforumID3/80482.html#221 Tue, 04 Oct 2011 15:28:05 GMT &gt; правильный вопрос будет таким: &#171;а когда уже в бсд появится инструмент, позволяющий делать снапшоты и не привязаный к конкретной фс?&#187;<br><br>при наличии 2 FS необходимость в таком инструменте кажется надуманой.<br><br> https://opennet.ru/openforum/vsluhforumID3/80482.html#220 Tue, 04 Oct 2011 10:47:54 GMT &gt; ...может, во FreeBSD что-то поправить?... X) <br><br>Вы что-то конкретное имеете в виду, или это непроизвольные выкрики?<br> https://opennet.ru/openforum/vsluhforumID3/80482.html#219 Tue, 04 Oct 2011 10:22:30 GMT ...может, во FreeBSD что-то поправить?... X)<br> https://opennet.ru/openforum/vsluhforumID3/80482.html#218 Tue, 04 Oct 2011 10:14:19 GMT &gt; Расскажите это рамблеру и яндексу. А то их конский топот аж с хабрахабры слышно.<br><br>давайте подождём чуть-чуть и посмотрим статистику по серверам. кстати, переход с FreeBSD на Linux на моей практике происходит по одному и тому же сценарию. Сначала из команды разработчиков вымываются программисты. И набираются ОЦК (особоценныекадры), которые не в состоянии делать элементарные с точки зрения программирования вещи. А те, ктоторые умеют делать, не умеют делать хорошо. Затем начинается поиск причин возникших проблем. После чего появляются Linux и в комплекте пионэр с минимильным его (Linux-а) знанием. Поймите меня правильно, я не с целью там как-то унизить Linux, мне лично не нравится тенденция. Но связь очевидна, к сожалению: переход на Линукс и деградация команды идут параллельно. Буду рад, если где-то не так. Но "не так" мне лично не встречалось.<br><br> https://opennet.ru/openforum/vsluhforumID3/80482.html#217 Sun, 02 Oct 2011 18:56:21 GMT &gt;[оверквотинг удален]<br>&gt;&gt; добил уже ранее деградировавший пул. Ну не повезло человеку, вернее ССЗБу, <br>&gt; Не вижу, что помешает тому чтобы такое же "везение" посетило и остальных. <br>&gt; Как бы fsck и нужен в случае когда не повезло. RAIDы <br>&gt; вообще очень надежны в теории, а при реальных непредсказуемых глюках оборудования <br>&gt; и отказах - больше похоже на лотерею. Оборудование имеет свойство подыхать <br>&gt; совсем не так как было задумано в RAID-ах, поэтому надеяться на <br>&gt; то что слой RAID-а однозначно спасет - лично я бы не <br>&gt; стал. Потому что прецеденты странной смерти оборудования - бывают. При этом <br>&gt; бывает все что угодно и совсем не в том виде в <br>&gt; каком было задумано :D.<br><br>Да. Бывает на традиционных ФС, где ФС и менеджеры томов не знают о сквозной целостности данных, которые они обрабатывают и хранят. Типичный случай: рассинхронизация классического RAID-1. Кто знает, почему такое происходит довольно часто, что приходится периодически запускать специальную утилиту верификации от производителя RAID? Нет https://opennet.ru/openforum/vsluhforumID3/80482.html#216 Sun, 02 Oct 2011 17:36:25 GMT &gt; Все постоянно ссылаются на один и тот-же пример с лисяры, где товарищ <br>&gt; добил уже ранее деградировавший пул. Ну не повезло человеку, вернее ССЗБу,<br><br>Не вижу, что помешает тому чтобы такое же "везение" посетило и остальных. Как бы fsck и нужен в случае когда не повезло. RAIDы вообще очень надежны в теории, а при реальных непредсказуемых глюках оборудования и отказах - больше похоже на лотерею. Оборудование имеет свойство подыхать совсем не так как было задумано в RAID-ах, поэтому надеяться на то что слой RAID-а однозначно спасет - лично я бы не стал. Потому что прецеденты странной смерти оборудования - бывают. При этом бывает все что угодно и совсем не в том виде в каком было задумано :D.<br><br>&gt; угробил из 3-х дисков в raid-е 2. <br><br>Я и более прикольные рассыпоны многодисковых рэйдов видал. Это у него еще так, ерунда. Обычный бэд, относительно безобидный сценарий. Бывает намного хуже.<br><br>&gt; И то, структуры он особо не переколупывал. Пытался просто откатить <br>&gt; последние транзакции. Нынче для этого уже ключик - https://opennet.ru/openforum/vsluhforumID3/80482.html#215 Sun, 02 Oct 2011 17:05:13 GMT &gt;&gt; Вкатить 1 х 100Мб кусок в любом случае оптимальнее чем порядка 800 кусков для того же самого делать.<br>&gt; Вкатить 1 х 100Мб кусок - Это сфероконь в вакууме. В реальности <br>&gt; основные задачи, как раз наоборот, регулярно вкатывать куски по 100Кб.<br><br>Как бы от задачи сильно зависит.<br><br>&gt; Могу их Вам перечислить: <br>&gt; - Перезаписать в произвольном месте файла кусок 8-16Кб (базы данных) <br><br>ZFS почему-то на этих задачах ничего такого интересного не демонстрирует.<br><br>&gt; - Дописать в конец файла несколько десятков килобайт (логи) <br><br>Ну, допустим. Только интенсивность этих операций невысока и всем похрену на их скорость.<br><br>&gt; - создать и удалить в некоем каталоге несколько десятков - сотен файлов <br>&gt; средним размером около 100Кб (кеширование, например, почты, веба или чего-либо подобного) <br><br>Капитан намекает что файлы бывают разные, поэтому не вижу вреда от возможности выделить одним чихом и несколько мегов, в случае если файл окажется крупнее. Кстати если уж на то пошло, ZFS традиционно сливает тест postmark у похорони https://opennet.ru/openforum/vsluhforumID3/80482.html#214 Sun, 02 Oct 2011 16:01:14 GMT &gt; Бегают, пока не нарвались на частичную деградацию флэшатины. :) В ZFS этот <br>&gt; факт довольно быстро локализуется и сообщается о проблеме.<br><br>Ага, на лисяре можно посмотреть как перец бэды локализовывал, педаля структуры ZFS вручную :). Если уж на то пошло, EXT4 вручную разбирать как-то попроще будет :P. Случаев с RAID правда это не касается, все data recovery за восстановление с RAID дерут три шкуры т.к. возни заметно больше получается.<br><br>&gt; На традиционных ФС о проблемах SSD пользователь узнаёт в поседнюю очередь по факту потери <br>&gt; данных.<br><br>Ага, а судя по лисяре пользователь ZFS узнает о бэдах по напрочь немоунтабельному тому, с которого данные выцепить - слегка облом %). Это так уж принципиально лучше?<br><br>&gt;&gt; пожалуй. То что он у других хуже - это как бы <br>&gt;&gt; совсем не факт, я бы скорее поставил на обратное.<br>&gt; Вот только я могу в любой момент "оттюнить" (в ущерб, естественно, сквозной <br>&gt; целостности) свойства в ZFS до уровня той же Ext4 <br><br>Ну как бы покажи _бенчмарки_ после тюнинга, разрывающие EXT4? А