The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

Обновление кластерной файловой системы LizardFS 3.13.0-rc2, opennews (??), 10-Ноя-19, (0) [смотреть все]

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


63. "Обновление кластерной файловой системы LizardFS 3.13.0-rc2"  +/
Сообщение от edo (ok), 20-Июн-20, 11:47 
> Пользоваться этой штукой можно будет через два месяца - _если_ новые разработчики (и, главное, новые погонщики с плетками) справятся с поставленной задачей - выпустят таки 13ю версию которой можно пользоваться.

что-то релиза нет, таки не шмогла?

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

65. "Обновление кластерной файловой системы LizardFS 3.13.0-rc2"  +/
Сообщение от пох. (?), 20-Июн-20, 12:38 
>> Пользоваться этой штукой можно будет через два месяца - _если_ новые разработчики (и,
>> главное, новые погонщики с плетками) справятся с поставленной задачей - выпустят таки 13ю
>> версию которой можно пользоваться.
> что-то релиза нет, таки не шмогла?

таки не. Нет не то что релиза, а rc3 с закрытием назойливого бага - который должен был быть в марте.

https://github.com/lizardfs/lizardfs/commits/master
героическими усилиями только сломали совместимость с python2. При том что эта часть скорее клиент чем сервер, и поддержка "немодных" систем должна быть как минимум как опция.

Насколько я понимаю, основные денежки проекту капают от коммерческих клиентов, купивших все вместе с обслуживанием - и все усилия уходят на то чтобы они не сбежали окончательно.

А те навряд ли вообще планируют апгрейдиться - наелись предыдущего раза. Поэтому вместо разработки разработчики занимаются вот таким: https://github.com/lizardfs/lizardfs-audit

community-форум угробили, линк на него возвращает обратно на lizardfs.com, как будто так и надо (обещали еще в марте что-то сделать вместо - и ничего ниасилили)

Причем в апреле они гордо говорили что наняли таки разработчиков - включая одного из первоначальных авторов форка. Но судя по комитам - разработчики у них только на sh и python.

Так что либо делать и поддерживать свой форк, либо закапывать. :-(

btw, если кто готов помочь с гуглокодом - буду крайне признателен. Хотя бы в виде тыканья пальцем, где читать документацию. (кусок кода скопипащен из мертвого гуглопрожекта. Он a) x8664 only b) неправильно детектирует конфигурацию. К сожалению, я ничерта не понимаю ни в интрисиках, ни в системах команд модных процессоров.)

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

67. "Обновление кластерной файловой системы LizardFS 3.13.0-rc2"  +/
Сообщение от edo (ok), 20-Июн-20, 13:02 
> Так что либо делать и поддерживать свой форк, либо закапывать. :-(

а что вообще стоит посмотреть? примерно 10kk файлов, под 150 Tb.
основная задача: отдавать nginx'ом статику

сейчас сделано просто: несколько машин с дисками по 10 Tb, на каждой свой nginx, в базе указано какой файл где лежит.
работает отлично, но хочется иметь некоторую избыточность/EC (на несколько реплик денег жалко).

> btw, если кто готов помочь с гуглокодом - буду крайне признателен. Хотя бы в виде тыканья пальцем, где читать документацию. (кусок кода скопипащен из мертвого гуглопрожекта. Он a) x8664 only b) неправильно детектирует конфигурацию. К сожалению, я ничерта не понимаю ни в интрисиках, ни в системах команд модных процессоров.)

я что-то потерял нить…

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

68. "Обновление кластерной файловой системы LizardFS 3.13.0-rc2"  +/
Сообщение от пох. (?), 20-Июн-20, 13:41 
> а что вообще стоит посмотреть?

если это у тебя за деньги - не вижу проблем ни с gluster, ни с moose.

Тупо сравнить производительность на твоих задачах, и остановиться на первой приемлемой.
distributed тебе при этом не надо, так что gluster ближе всего к искомому.

Но, опять же - если это за деньги, смотреть скорее в репликацию а не в ec.

> я что-то потерял нить…

это текущая проблема lizard лично для меня.
Существует в v3.12.0 (поскольку более новые даже в костюме химзащиты нельзя ставить) - в external/crcutil-1.0 лежит кусок гуглового навоза. Это даже не соберется на неправильной платформе (традиционный гуглокодинг стайл).

Еще одно нехорошее место - src/common/galois_field_encode.cc - это собирается (единственноверным компилятором, конечно), но оптимизации есть только для x86

где про эту муть вообще почитать, и отдельно - про neon ?

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

69. "Обновление кластерной файловой системы LizardFS 3.13.0-rc2"  +/
Сообщение от edo (ok), 21-Июн-20, 00:55 
> если это у тебя за деньги - не вижу проблем ни с
> gluster, ни с moose.

нет, хочется бесплатно )

> Тупо сравнить производительность на твоих задачах, и остановиться на первой приемлемой.

«тупо сравнить» на объёме >>100 Tb не так уж и просто.

> это текущая проблема lizard лично для меня.
> Существует в v3.12.0 (поскольку более новые даже в костюме химзащиты нельзя ставить)
> - в external/crcutil-1.0 лежит кусок гуглового навоза. Это даже не соберется
> на неправильной платформе (традиционный гуглокодинг стайл).
> Еще одно нехорошее место - src/common/galois_field_encode.cc - это собирается (единственноверным
> компилятором, конечно), но оптимизации есть только для x86
> где про эту муть вообще почитать, и отдельно - про neon ?

хочется запустить это всё на арме с оптмизациями? я не уверен, если честно, что оптимизации расчёта crc как-то повлияют на итоговую производительность, да и про ec надо смотреть, возможно, оптимизации не так уж и важны.

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

70. "Обновление кластерной файловой системы LizardFS 3.13.0-rc2"  +/
Сообщение от пох. (?), 21-Июн-20, 10:34 
> «тупо сравнить» на объёме >>100 Tb не так уж и просто.

сравни на части объема. Они не требуют переформатировать диски если там не ntfs, можно запустить обе параллельно и продолжить раздавать основную часть старым способом.

Но ec в гластере - крайне загадочны и толком никем не тестированы. Впрочем, он весь загадочен, и я его забраковал по расистским соображениям.

> хочется запустить это всё на арме с оптмизациями?

там не только на арме, там даже llvm не соберет.
Впрочем, оно без ручных правок не собирается даже на 32битных системах - сборку там писал какой-то дятел, вообще не понимающий как работает cmake и наговнявший как попало.

Теоретически, оно может этот крэп выкинуть и собраться с isal, если найдет, но для моей системы нет isal и его тут будет очень сложно собрать. И все это ради функции в двадцать строчек я точно не хочу. При этом все эти вычисления, как и у gluster, выполняются _на_клиенте_, так что производительность важна, клиенты у меня разные, и чаще всего - дохловаты для 100mb/s. crc менее важен, но, afiu - напрямую влияет на цикл проверки bitrot, чем он короче, тем безопаснее с этим жить.

Так что повторяю вопрос - где прочитать что эти все закорючки означают и где накопипастить закорючек для neon?

Ну где-то же авторы нашли всю эту хрень (хотя могли и копипастить у интела, не понимая ни слова, конечно - может потому и не смогли пофиксить фичу 13й - не понимали, что творят).

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

71. "Обновление кластерной файловой системы LizardFS 3.13.0-rc2"  +/
Сообщение от пох. (?), 21-Июн-20, 18:17 
результаты теста (винды) на слабом процессоре оказались довольно предсказуемы - 28-30мб write, 16 in. Упирается именно в процессор. _клиента_.

При goal=1 - сразу же 35 (упирается уже в возможности тестовой vm) и 25. Таки говорите не нужны оптимизации? ;-)

Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру