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

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

"OpenNews: Новое распределенное хранилище данных будет включе..."

Сообщение от opennews (??) on 29-Окт-07, 03:19

Наработки по созданию транспортного уровня для организации распределенных хранилищ данных (http://tservice.net.ru/~s0mbre/old/?section=projects&item=dst) (DST), созданные Евгением Поляковым, одобрены (http://kerneltrap.org/Linux/Distributed_Storage_Subsystem_Headed_For_-mm) для включения в экспериментальную "-mm" ветку Linux ядра. DST функционирует на уровне блочного устройства, работающего поверх нескольких машин в сети (ближайшие аналоги - DRBD (http://www.drbd.org/), iSCSI (http://linux-iscsi.sourceforge.net/) и NBD (http://nbd.sourceforge.net/)). Обработка данных производится в неблоркирующем режиме. Поддерживаются различные алгоритмы распределения данных, например - зеркалирование или создание линейного хранилища охватывающего все узлы. Кроме того, система снабжена средствами автоконфигурации (параметры удаленных узлов определяются автоматически) и автоматической обработки ситуации сбоя: при обнаружении сбоя (например, выключения удаленной машины), проблемный узел помечается неактивным до момента возобновления достижимости, после чего накопившиеся данные синхронизируются на него, не требуя какого-либо участия администратора. URL: http://kerneltrap.org/Linux/Distributed_Storage_Subsystem_Headed_For_-mm Новость: http://www.opennet.me/opennews/art.shtml?num=12558

Высказать мнение | Ответить | Правка | Cообщить модератору

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

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

1. "Новое распределенное хранилище данных будет включено в Linux..."

Сообщение от Nick (??) on 29-Окт-07, 03:19

ниасилившым люстру посвящаеться...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от avatar (??) on 29-Окт-07, 12:26
	Не кластерное, а распределённое, прошу заметить.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от Nick (??) on 29-Окт-07, 12:28
	>Не кластерное, а распределённое, прошу заметить. согласен принимаеццо
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	35. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от Johny on 30-Окт-07, 22:34
	>ниасилившым люстру посвящаеться... А вот вы не в курсе, когда в люстре появится режим мирроринга для файлов, а не только stripe?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	36. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от Nick (??) on 31-Окт-07, 08:26
	>А вот вы не в курсе, когда в люстре появится режим мирроринга >для файлов, а не только stripe? вкурсе если и изначально не было (давно дело было...) то щас он есть. Каждая нода в люстре - виртуальная и можем состоять из нескольких физических нод. READs/WRITEs идут на рабочую, активную; и WRITEs на остальные, бекапные. В любой момент любая бекапная нода может продолжить правое дело памшего товарисча...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	38. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от Johny on 01-Ноя-07, 15:30
	>Каждая нода в люстре - виртуальная и можем состоять из нескольких >физических нод. READs/WRITEs идут на рабочую, активную; и WRITEs на остальные, бекапные. > > >В любой момент любая бекапная нода может продолжить правое дело памшего товарисча... > В целом приемлимо, но  --- насколько я понял никакого автоматического Fallover для MGS/MDT службы нету. Ну то есть нельзя сделать например 2 штуки MGS чтоб в случае сбоя одного, второй включался автоматически. А насчёт "мирррор"  меня интересует когда можно будет задавать это в аттрибутах файла.... что вот этот файл страйпед, а вот этот мирроред.... про "продолжение дела падшего товарища" -- как не пытался настроить, не ловится кактус. то есть оно работает тока при живом MGS иначе всё отмонтировать и перетыкать руками. Так я и без всякой люстры умею -- тупо любая файловая система + drbd если чё -- перемонтировал на другой сервер вручную
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	39. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от Nick (??) on 02-Ноя-07, 15:40
	>В целом приемлимо, но  --- насколько я понял никакого автоматического Fallover >для MGS/MDT службы нету. вот с этого места тебя поправить и остальная часть поста сама собой отпадает. MGS/MDT может зеркалироваться (точно так же как и OST) для переключения в случае пипеца. Сама люстра не провайдит методов определения failover событий и их обработку. Для этого они рекомендуют HeartBeat (linux-ha.org), который будет определять жив ли нод и менять конфиг люстры.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Новое распределенное хранилище данных будет включено в Linux..."

Сообщение от fresco (??) on 29-Окт-07, 08:33

Фигли толку, reiser4 в этой -mm ветке уже 4 года сидит.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Новое распределенное хранилище данных будет включено в Linux..."

Сообщение от Аноним on 29-Окт-07, 10:31

А так ожесточенно сопротивлялись, и все-токи включили. А с люстрой нечего сравнивать, у них разные ниши. А вот reiser4 не нужен :) ИМХО.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от fresco (??) on 29-Окт-07, 11:39
	Да хз. Мне бы не помешал. Штука хорошая. ZFS нам (Linux'оидам) все равно не светит, кроме того, не так уж она и производительна, да и ниши у них несколько разные. А из существующих Linux-ФС reiser4 лучшая. Опять же, ИМХО, но могу обосновать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от Аноним on 29-Окт-07, 11:59
	Я не против reiserfs, просто у меня с ней были проблемы на ровном месте, да и в новых ядрах как-то не особо видно патчей к ней (хотя может всё работает ну разве что квоты не очень :), и у Ганса проблемы, вроде он главный вдохновитель и координатор проекта. Поэтому и ИМХО.  Законы рынка блин, если в кампании не лады - акции падают :). А так я на XFS перешёл. > Опять же, ИМХО, но могу обосновать. Обоснуёте, но только с позиции стороннего наблюдателя, какие плюсы и минусы. Не вдаваясь в крайности, а то мало где можно встретить обсуждение без примеси религии.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от fresco (??) on 29-Окт-07, 12:28
	> да и в новых ядрах как-то не особо видно патчей к ней Посмотрите на changelog'и .23 и .24-rc1 ядер, особенно  последнего -- там приличный объем фиксов и чиски кода для reisrfs Это раз. reiser4 -- совершенно самостоятельная ФС, никак не новая версия reiserfs. По поводу обоснования. 1. Не верьте бенчмаркам. Работает у всех по-разному. Чуть поменяли оборудование, условия теста -- и все, результаты поплыли. Статистика -- самая лживая вещь на свете. Смотрите на логику работы, математику. На крайняк -- проверяйте производительность сами. 2. Описания файловых систем (в т.ч. XFS и reiser4) лежат на http://www.filesystems.nm.ru/  Читайте, думайте. Подозреваю, что модератор скоро начнет меня резать за саморекламу, но повторять то, о чем рассказывал в статьях и много раз говорил здесь -- не вижу смысла.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	25. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от Лузер on 30-Окт-07, 03:24
	>1. Не верьте бенчмаркам. Работает у всех по-разному. Чуть поменяли оборудование, Это да.Очень достает.Ценность бенчмарков мала.Чуть что отличается и файловые системы меняют лидеров на противоположных. Лично я в данный момент на жирных разделах (сотни гиг) юзаю JFS.Имхо достаточно шустрая и стабильная ФС вроде.Меня не подводила.Юзал бы XFS но случаи описанные в интернете с забитием данных нулями при внезапном power off как-то ну совсем не радуют.В FAQ у SGI есть про это, равно как и упоминание что что-то дополнительно дофикшено в марте 2007 года кой-что на этот счет.Кто юзает и у кого часты некорректные слеты питания - скажите, как оно?Эта проблема все еще есть?Мне нужны мои данные.А не нули в них.В _любой_ ситуации множество данных не должно забиваться нулями.А в интернете полно случаев когда данные в энной ситуации забивались нулями.Думается что вся эта крутая буферизация, отложенные записи и задержка апдейтов метаданных конечно круто и скорости добавляет.Но надежность резонно просаживается. >на свете. Смотрите на логику работы, математику. Дядьку, чтобы понять как файловая система поведет себя на энном железе с его особенностями и лимитами на основе формального описания ФС и ее работы к тому же довольно сложного и не дающего видения типового workflow - админ должен иметь знания уровня доктора физматнаук и мозг способный поспорить с Карповым и Каспаровым при оценке сложных последовательностей действий.Таких админов десяток на всю планету спасибо если наскребется... :\ >На крайняк -- проверяйте производительность сами. Может я тупой но по формальному описанию ФС мне как-то непросто проиграть в голове полный список всех операций ФС чтобы сравнить "кто быстрее".Еще более непросто наложить этот список действий на крайне необычную штуку, называемую жестким диском.Формально, он, конечно для ос просто линейный набор секторов.Но реально разные скорости на разных треках, ненулевое время track to track seek и т.п. ненапряжно отправят в дурку бОльшую половину тех кто попытается в голове проиграть этот сценарий с учетом хотя-бы основных факторов, чтобы получить что-то хоть немного похожее на реальность.А потом придется вкурить в особенности архитектур, реализации алгоритмов в конкретном драйвере... уй... крыша хлопает в ладоши.Всем спасибо, план хороший. >2. Описания файловых систем (в т.ч. XFS и reiser4) лежат на http://www.filesystems.nm.ru/ > Читайте, думайте. А чем ваше описание так хорошо?Вроде это банальные перевод доков с сайтов контор?Или я чего-то не понял?Или это для тех недо-админов которые инглиш не осилили?Рейзер 4 в принципе неплохо описан на сайте их конторы.Задуман неплохо.Но зверски сложный и посему непонятно что от него ждать в реальной жизни.Ну, может наши внуки смогут даже насладиться его стабильной версией :).И еще, интуиция подсказывает что хорошие алгоритмы просты и красивы.Рейзер в это не вписывается.Слишком наворочен, IMHO.Кроме того во всех бенчах попадается ряд операций на которых рейзер (что 3.х что 4) традиционно не силен.Статистика конечно лживая но когда она слишком часто начинает говорить одно и то же - это уже легкая претензия на объективность.Скажем насколько я понимаю, рейзеры не любят удаление разлапистых каталогов и многих тысяч файлов и каталогов? Вот вы как видимо неплохо разбирающийся в вопросе что скажете про XFS vs JFS например?Сильные и слабые стороны обрисовать могете?Да и для других ФС велкам :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от fresco (??) on 30-Окт-07, 10:11
	> Юзал бы XFS но случаи описанные в интернете с забитием данных нулями при внезапном power off Это, как говорится, не бага -- это фича. Это политическое решение -- забивать сомнительные (в плане целостности указывающих на них структур данных) блоки нулями, что бы кто-то другой не получли случайно доступ к вашим данным. Данных о том, что от этой фишки собирались отказаться у меня нет. > Вроде это банальные перевод доков с сайтов контор?Или я чего-то не понял?Или это для тех недо-админов которые инглиш не осилили? Где как. Есть и переводы доков. Статья по reiser4, к примеру, на 90% перевод комментариев в исходниках. Этих данных вы нигде, кроме как в сырцах, не найдете. И не стоит так принижать людей. Английский на приемлемом для понимания таких материалов уровне знают не все. Потом, в материал на родном языке врубаешься все равно на порядок быстрее. > Рейзер 4 ... Задуман неплохо.Но зверски сложный и посему непонятно что от него ждать в реальной жизни. Что вы, reiser4 одна из самых простых ФС. Именно за счет применения единой семантики ко всем типам данных. XFS или JFS гораздо сложнее, с огромным количеством разномастных сущностей и методов к ним. Ну, теперь по поводу сравнения ФС. Дальше пойдет чистое ИМХО, флейм прошу не начинать -- каждыйимеет право на свое мнение, я свое обосновал в статьях, повторять не буду. reiserfs. Достаточно добротная ФС. Имеет хорошие показатели при чтении, в т.ч. больших каталогов -- за счет применения единого дерева и эффективной группировки в нем связанных данных. На запись подтормаживает из-за использования битовых карт, отсутствия распараллеливания операций с деревом и эффективных схем отложенного размещения. Не очень хорошо противодействует фрагментации. JFS. На чтение достаточно эффективна, хорошо справляется с большими каталогами (деревья) и фрагментацией (за счет применения групп размещения). Схема выделения блоков имеет ряд недостатков, в т.ч. не стандартный механизм учета свободного пространства -- вроде бы это и деревья экстентов, но неклассические, с большим количеством ограничений. Из-за этого более подвержена фрагментации, чем XFS, медленнее выделяет блоки. Хороша на медленных дисках (отложенная запись). XFS. Можно сказать, классическая advaced ФС. B+ деревья по всюду. Экстенты тоже. Группы размещения. Не подвержена фрагментации, быстро читает данные и каталоги, хорошо выделяет блоки, противодействует фрагментации. Хороша на медленных дисках. Практически замечено отставание при записи больших файлов -- объяснить не могу :) Предположительно на дисках более 8 Tb производительность будет падать нелинейно. reiser4. Обладает всеми преимуществами reiserfs, лишена ее недостатков -- опреции с деревом эффективно распараллеливаются, имеется отложенная запись и группировка запросов. Для учета свободных блоков использует битовые карты -- это минус. Еще -- невозможно отключить журналирование данных. Хотя используются хорошие схемы замещения (как в log-structured ФС, ZFS) -- все равно это минус. При использовании сжатия данных на машинах с быстрым CPU и большим кэшем будет лидером по записи. При использовании репакера -- лидером по чтению. ext2/3. No comments. Лидер на маленьких разделах, явный аутсайдер на больших. ext4. Мало данных.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	30. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от Аноним on 30-Окт-07, 12:10
	>Ну, теперь по поводу сравнения ФС. Дальше пойдет чистое ИМХО, флейм прошу >не начинать -- каждыйимеет право на свое мнение, я свое обосновал >в статьях, повторять не буду. У автора этого распределенного хранилища в блоге нашел кучу бенчмарков разных FS, включая ext123, jfx, xfs, reiser34... Теория не совпадает с практикой: http://tservice.net.ru/~s0mbre/old/?section=projects&item=fs_contest
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	31. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от fresco (??) on 30-Окт-07, 12:26
	Объяснял же -- не верьте бенчмаркам! У всех по-разному работает. Вам мои что ли показать?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	32. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от Аноним on 30-Окт-07, 12:36
	>Объяснял же -- не верьте бенчмаркам! У всех по-разному работает. Вам мои >что ли показать? Одни и те же бенчмарки должны давать один и тот же результат в схожих условиях, так что если у вас неподдерживаемая jfs неожиданно стала работать быстрее xfs и reiser (или хоть чего-нибудь), то было бы интересно на это посмотреть. Кстати, ext2 наверное самая быстрая из всех существующих систем, для одного потока чтения или записи это абсолютно точно. Другое дело, что fsck в случае сбоя будет вечным, и надежность никакая...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	33. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от fresco (??) on 30-Окт-07, 13:01
	В схожих -- да. Только эти условия должны быть_очень_ схожи. К примеру, меняете диск на более медленный -- и все, лидеры совсем другие. Практически же получение схожих результатов реально только на абсолютно одинаковом железе (вывод чисто эмпирический). ext2 -- она идеально для небольших, малозаполненных (следовательно не фргментированных) разделов. На активно используемом диске объемом, хотя бы, 100 Gb, заполненном на 70%, она явный аутсайдер по всем параметрам. По чисто математическим причинам.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	37. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от Аноним on 31-Окт-07, 16:06
	>В схожих -- да. Только эти условия должны быть_очень_ схожи. К примеру, >меняете диск на более медленный -- и все, лидеры совсем другие. >Практически же получение схожих результатов реально только на абсолютно одинаковом железе >(вывод чисто эмпирический). > >ext2 -- она идеально для небольших, малозаполненных (следовательно не фргментированных) разделов. На >активно используемом диске объемом, хотя бы, 100 Gb, заполненном на 70%, >она явный аутсайдер по всем параметрам. По чисто математическим причинам. А у вас есть какие нибудь сведения на счет надёжности reiserfs4 (может тесты устраивали), интересует как она ведёт себя при возникновении единичного бэда или ошибки при передаче по  шине винчестера (если винт переносной или комп лажёвый :). На бедах reiserfs v3  говорил "Permission denied" руту при открытии файла :) PS: Нда, флеймеры быстро набежали...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от Nick (??) on 29-Окт-07, 12:15
	>ZFS нам (Linux'оидам) все равно не светит как это не светит? еще и как. Или FUSE значит фтопку?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от fresco (??) on 29-Окт-07, 12:16
	А вы ее попробуйте заюзать через этот FUSE. Тормознее даже ntfs-3g получается. Не, посмотреть и восхититься, конечно, можно. Но не работать!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от Nick (??) on 29-Окт-07, 12:19
	>А вы ее попробуйте заюзать через этот FUSE. Тормознее даже ntfs-3g получается. >Не, посмотреть и восхититься, конечно, можно. Но не работать! ну разве что. А не вкурсе че нету патчей сторонних на ядро? У них настолько несовместимы лицензии, что и скомпилить нельзя линух с ZFS?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от fresco (??) on 29-Окт-07, 12:33
	Скомпилить-то можно (было бы, если б был код!). Только вот что-то никто портированием не занимается. К большому сожалению. ZFS -- очень сильная технология, в промышленности приживется на раз. Вот увидите, как в следующем году народ c Linux на семерку повалит. Про порты под Linux-kernel-API ничего не слышал. Видимо, энтузиастов нет, да и Sun будет всячески мешать появлению  таких продуктов.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от Nick (??) on 29-Окт-07, 12:36
	>Про порты под Linux-kernel-API ничего не слышал. Видимо, энтузиастов нет, да и >Sun будет всячески мешать появлению  таких продуктов. ну да... а мешать бздунам - все равно что бить по рукам ребенка, тянущегося за конфетой :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от fresco (??) on 29-Окт-07, 12:57
	Не в этом дело. BSD им не конкурент. А вот о принятии курса на вытеснение Linux OpenSolaris'ом со всех позиций (вплоть до десктопа) было заявлено открыто. А на BSD Sun'у наплевать, она вне рынка, ее никто не покупает. Люди, которым нужна поддержка, в ее сторону даже не посмотрят.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от fresco (??) on 29-Окт-07, 12:59
	А BSD'шники, кстати, в этом плане оказались большие молодцы. Сразу смекнули, что к чему и активно взялись за портирование ZFS. Теперь имеют реальный шанс оттяпать у Linux хорошую долю на несопровождаемых северах.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	27. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от Лузер on 30-Окт-07, 03:33
	>А BSD'шники, кстати, в этом плане оказались большие молодцы. Сразу смекнули, что >к чему и активно взялись за портирование ZFS. Теперь имеют реальный >шанс оттяпать у Linux хорошую долю на несопровождаемых северах. Удачи в этом нелегком деле и все такое, посмотрим чего понты бздунофф стоят... но лучше бы вы оттяпывали проценты у микрософта :) а то пока вы пилите доли процента с линуксоидами, смотрите  как бы микрософт не подавился своим куском пирога.Может, лучше их обувать бум сообща?А то у линуксоидов всего с десяток процентов серверного рынка.У микрософта куда как больше ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от Nick (??) on 29-Окт-07, 13:00
	>Не в этом дело. BSD им не конкурент. А вот о принятии >курса на вытеснение Linux OpenSolaris'ом со всех позиций (вплоть до десктопа) >было заявлено открыто. А на BSD Sun'у наплевать, она вне рынка, >ее никто не покупает. Люди, которым нужна поддержка, в ее сторону >даже не посмотрят. Ну, тогда остеться лишь возрадоваться :) Больших врагов не бывает у мелких проектов
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от Аноним on 29-Окт-07, 17:26
	Да чтобы nick прошел мимио слова BSD не тявкнув :) Неее - не верю! Не научная фантастика :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	23. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от fresco (??) on 29-Окт-07, 20:30
	Ну, nick, по крайней мере, никогда не высказывался не обоснованно. Чего нельзя сказать о всяких анонимах.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	28. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от Лузер on 30-Окт-07, 03:38
	>Не в этом дело. BSD им не конкурент. А вот о принятии >курса на вытеснение Linux OpenSolaris'ом со всех позиций Ага, а в итоге выиграет как всегда - микрософт, который только порадуется этой пирровой победе в случае если она состоится :(.Растоптать SUN микрософту раз плюнуть когда он один.А вот все линуксное сообщество - ну удачи, ага... они вон пыжатся с патентами но хрен у них что получается.Собака Баллмера лает а караван линуксоидов - идет.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от Лузер on 30-Окт-07, 03:29
	>Или FUSE значит фтопку? Достаточно посмотреть на NTFS-3G.Многие операции с ним упираются... нет, не в диск.В _процессор_... это на x64 системе с AMD x2 3800+ (2 ядра по 2.0GHz) и гигом 2-канальной DDR2-800.Я не хочу ничего сказать, но это не диагноз а пригвор!Не быть файловым системам в FUSE чемпионами в бенчах.Посему - да, фтопку.Есть куча нормальных и _быстрых_ ФС не нагружающих процессор реализованных в кернеле.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

17. "Новое распределенное хранилище данных будет включено в Linux..."

Сообщение от guest (??) on 29-Окт-07, 15:39

Лучше бы его kevent (вместо signalfd) и netchannels (как альтернатива socket) включили.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от devcoder (??) on 29-Окт-07, 17:12
	> Лучше бы его kevent Мимо темы конечно... Торвальдс на kevent зуб точит или завидует, что сам первым не придумал :-) Советую почитать Igor Sysoev http://www.opennet.me/base/dev/kqueue_vs_epoll.txt.html Лично для меня, основное преимущество работы с kevent, так это замес сигналов и дескрипторов.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от Nick (??) on 29-Окт-07, 17:23
	>[оверквотинг удален] > >Мимо темы конечно... > >Торвальдс на kevent зуб точит или завидует, что сам первым не придумал >:-) > >Советую почитать Igor Sysoev http://www.opennet.me/base/dev/kqueue_vs_epoll.txt.html > >Лично для меня, основное преимущество работы с kevent, так это замес сигналов >и дескрипторов. постыдилсо бы на такую древность линки кидать... Jan 2003 особенно порадовало "(эй, в Линуксе знают о aio операциях !?!)"  %))))) улыбнуло. пасиба. ну а ваще все те "вкусности", что позволяет этот kqueue уже давно есть в Линухе, и не слеплены в один сискол.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от Аноним on 29-Окт-07, 17:53
	>ну а ваще все те "вкусности", что позволяет этот kqueue уже давно >есть в Линухе, >и не слеплены в один сискол. Кстати появились они только после kevent патчей, да и то несколько кривовато... Хотя в kqueue используется intptr_t, который суть указатель и следовательно не работает, если ядро 64 бит, а userspace - 32.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	22. "Новое распределенное хранилище данных будет включено в Linux..."
	Сообщение от devcoder (??) on 29-Окт-07, 18:45
	> и НЕ слеплены в один сискол. Разве это удобно? Лично мне, как сишному програмисту под Linux, это не очень _удобно_ (хотя конечно же возможно). Особенно когда пишешь демоны, то есть когда нужно одновременно обрабатывать и сигналы и fd-события. И основное неудобство даже не в кол-ве строк кода, а в том, что логику работы программы нужно составлять с учётом "независимости" обработчиков (sigaction и epool/select/pool). Можно конечно унифицировать через RTSIG, но там свои засады (ограничения). В общем, кто писАл подобное - поймёт, кто не писАл - звиняйте за оффтоп (кстати!).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]