https://89.19.215.112/openforum/vsluhforumID3/118968.html После годичного затишья в разработке возобновилась работа над новой веткой отказоустойчивой распределённой файловой системы LizardF 3.13 и опубликован второй кандадат в релизы. Недавно произошла смена владельцев компании, развивающей LizardFS, было принято новое руководство и сменились разработчики. Последние два года проект отстранился от сообщества и не уделял ему должного внимания, но новая команда намерена возродить прежние отношения с сообществом и наладить с ним тесное взаимодействие. Код проекта написан на языках С и С++ и распространяется под лицензий GPLv3...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=51804<br> https://89.19.215.112/openforum/vsluhforumID3/118968.html#72 Fri, 18 Sep 2020 22:39:27 GMT а там есть что открывать?<br>из https://bitblaze.ru/wp-content/uploads/2020/08/ru_prvl_00001_01_bitblaze_kfs_rukovodstvo_administratora.pdf торчат уши moosefs/lizardfs<br> https://89.19.215.112/openforum/vsluhforumID3/118968.html#71 Sun, 21 Jun 2020 15:17:01 GMT результаты теста (винды) на слабом процессоре оказались довольно предсказуемы - 28-30мб write, 16 in. Упирается именно в процессор. _клиента_.<br><br>При goal=1 - сразу же 35 (упирается уже в возможности тестовой vm) и 25. Таки говорите не нужны оптимизации? ;-)<br><br> https://89.19.215.112/openforum/vsluhforumID3/118968.html#70 Sun, 21 Jun 2020 07:34:39 GMT &gt; &#171;тупо сравнить&#187; на объёме &gt;&gt;100&#8239;Tb не так уж и просто.<br><br>сравни на части объема. Они не требуют переформатировать диски если там не ntfs, можно запустить обе параллельно и продолжить раздавать основную часть старым способом.<br><br>Но ec в гластере - крайне загадочны и толком никем не тестированы. Впрочем, он весь загадочен, и я его забраковал по расистским соображениям.<br><br>&gt; хочется запустить это всё на арме с оптмизациями? <br><br>там не только на арме, там даже llvm не соберет.<br>Впрочем, оно без ручных правок не собирается даже на 32битных системах - сборку там писал какой-то дятел, вообще не понимающий как работает cmake и наговнявший как попало.<br><br>Теоретически, оно может этот крэп выкинуть и собраться с isal, если найдет, но для моей системы нет isal и его тут будет очень сложно собрать. И все это ради функции в двадцать строчек я точно не хочу. При этом все эти вычисления, как и у gluster, выполняются _на_клиенте_, так что производительность важна, клиенты у меня разные, и чаще всего - дохлова https://89.19.215.112/openforum/vsluhforumID3/118968.html#69 Sat, 20 Jun 2020 21:55:50 GMT &gt; если это у тебя за деньги - не вижу проблем ни с <br>&gt; gluster, ни с moose.<br><br>нет, хочется бесплатно )<br><br>&gt; Тупо сравнить производительность на твоих задачах, и остановиться на первой приемлемой. <br><br>&#171;тупо сравнить&#187; на объёме &gt;&gt;100&#8239;Tb не так уж и просто.<br> <br>&gt; это текущая проблема lizard лично для меня.<br>&gt; Существует в v3.12.0 (поскольку более новые даже в костюме химзащиты нельзя ставить) <br>&gt; - в external/crcutil-1.0 лежит кусок гуглового навоза. Это даже не соберется <br>&gt; на неправильной платформе (традиционный гуглокодинг стайл).<br>&gt; Еще одно нехорошее место - src/common/galois_field_encode.cc - это собирается (единственноверным <br>&gt; компилятором, конечно), но оптимизации есть только для x86 <br>&gt; где про эту муть вообще почитать, и отдельно - про neon ? <br><br>хочется запустить это всё на арме с оптмизациями? я не уверен, если честно, что оптимизации расчёта crc как-то повлияют на итоговую производительность, да и про ec надо смотреть, возможно, оптимизации не так уж и важны.<br> https://89.19.215.112/openforum/vsluhforumID3/118968.html#68 Sat, 20 Jun 2020 10:41:04 GMT &gt; а что вообще стоит посмотреть?<br><br>если это у тебя за деньги - не вижу проблем ни с gluster, ни с moose.<br><br>Тупо сравнить производительность на твоих задачах, и остановиться на первой приемлемой.<br>distributed тебе при этом не надо, так что gluster ближе всего к искомому.<br><br>Но, опять же - если это за деньги, смотреть скорее в репликацию а не в ec. <br><br>&gt; я что-то потерял нить&#8230;<br><br>это текущая проблема lizard лично для меня. <br>Существует в v3.12.0 (поскольку более новые даже в костюме химзащиты нельзя ставить) - в external/crcutil-1.0 лежит кусок гуглового навоза. Это даже не соберется на неправильной платформе (традиционный гуглокодинг стайл).<br><br>Еще одно нехорошее место - src/common/galois_field_encode.cc - это собирается (единственноверным компилятором, конечно), но оптимизации есть только для x86<br><br>где про эту муть вообще почитать, и отдельно - про neon ?<br> https://89.19.215.112/openforum/vsluhforumID3/118968.html#67 Sat, 20 Jun 2020 10:02:21 GMT &gt; Так что либо делать и поддерживать свой форк, либо закапывать. :-(<br><br>а что вообще стоит посмотреть? примерно 10kk файлов, под 150&#8239;Tb.<br>основная задача: отдавать nginx'ом статику<br><br>сейчас сделано просто: несколько машин с дисками по 10&#8239;Tb, на каждой свой nginx, в базе указано какой файл где лежит.<br>работает отлично, но хочется иметь некоторую избыточность/EC (на несколько реплик денег жалко).<br><br>&gt; btw, если кто готов помочь с гуглокодом - буду крайне признателен. Хотя бы в виде тыканья пальцем, где читать документацию. (кусок кода скопипащен из мертвого гуглопрожекта. Он a) x8664 only b) неправильно детектирует конфигурацию. К сожалению, я ничерта не понимаю ни в интрисиках, ни в системах команд модных процессоров.)<br><br>я что-то потерял нить&#8230;<br> https://89.19.215.112/openforum/vsluhforumID3/118968.html#66 Sat, 20 Jun 2020 09:43:49 GMT &gt;&gt; При том что рядом лежала работающая (если забыть о ec или купить <br>&gt;&gt; кота в мешке) moose, и почти работающий gluster...<br>&gt; так у moose, кажется, тоже стагнация <br><br>у moose живое комьюнити и живые продажи. Там тоже полтора поляка в разработке, поэтому чудес не происходит - но им и не надо, у них нет пяти висящих багов с тотальным разрушением кластеров.<br><br>То есть оно как-то работает, поддерживается, ошибки фиксятся. Новых чудес не обещают, но не больно и хотелось бы. <br><br>Проблема с музей лично для меня в том что a) оно не поддерживает ec кроме коммерческой версии и той в очень странной конфигурации 8+ nodes, чего я у себя категорически не желаю b) ее виндовый драйвер (тоже платный) использует устаревший и неэффективный dokany.<br><br> https://89.19.215.112/openforum/vsluhforumID3/118968.html#65 Sat, 20 Jun 2020 09:38:04 GMT &gt;&gt; Пользоваться этой штукой можно будет через два месяца - _если_ новые разработчики (и,<br>&gt;&gt; главное, новые погонщики с плетками) справятся с поставленной задачей - выпустят таки 13ю<br>&gt;&gt; версию которой можно пользоваться.<br>&gt; что-то релиза нет, таки не шмогла?<br><br>таки не. Нет не то что релиза, а rc3 с закрытием назойливого бага - который должен был быть в марте.<br><br>https://github.com/lizardfs/lizardfs/commits/master<br>героическими усилиями только сломали совместимость с python2. При том что эта часть скорее клиент чем сервер, и поддержка "немодных" систем должна быть как минимум как опция.<br><br>Насколько я понимаю, основные денежки проекту капают от коммерческих клиентов, купивших все вместе с обслуживанием - и все усилия уходят на то чтобы они не сбежали окончательно.<br><br>А те навряд ли вообще планируют апгрейдиться - наелись предыдущего раза. Поэтому вместо разработки разработчики занимаются вот таким: https://github.com/lizardfs/lizardfs-audit<br><br>community-форум угробили, линк на него возвращает обратно на lizar https://89.19.215.112/openforum/vsluhforumID3/118968.html#64 Sat, 20 Jun 2020 08:49:11 GMT &gt; При том что рядом лежала работающая (если забыть о ec или купить <br>&gt; кота в мешке) moose, и почти работающий gluster...<br><br>так у moose, кажется, тоже стагнация<br>