https://www.opennet.ru/openforum/vsluhforumID3/114186.html Увидел свет (https://www.openindiana.org/2018/04/28/openindiana-hipster-2018-04-is-here/) релиз свободного дистрибутива OpenIndiana 2018.04 (https://wiki.openindiana.org/oi/2018.04+Release+notes), пришедшего на смену бинарному дистрибутиву OpenSolaris, развитие которого было прекращено компанией Oracle. OpenIndiana предоставляет пользователю рабочее окружение, построенное на базе свежего среза кодовой базы проекта Illumos (http://www.illumos.org/). Непосредственно разработка технологий OpenSolaris продолжается проектом Illumos, в котором развивается ядро, сетевой стек, файловые системы, драйверы, а также базовый набор пользовательских системных утилит и библиотек. Для загрузки сформировано (http://dlc.openindiana.org/isos/hipster/) три вида iso-образов - серверная редакция с консольными приложениями (664 Мб), минимальная сборка (391 Мб) и сборка с графическим окружением MATE (1.5 Гб).<br><br><br><br><br>Основные изменения (https://wiki.openindiana.org/oi/2018.04+Release+notes) в OpenIndiana 2018.04:<br><br><br>- Пользовательск https://www.opennet.ru/openforum/vsluhforumID3/114186.html#44 Tue, 08 May 2018 11:30:39 GMT Чем лучше обычной солярки?<br> https://www.opennet.ru/openforum/vsluhforumID3/114186.html#43 Sat, 05 May 2018 23:23:13 GMT &gt; И journal_checksum добавили туда чисто по приколу, ага.<br><br>это на совсем другой случай - не когда запись подтвердилась но не доехала до диска, а когда система просто навернулась на полном ходу, и есть шанс, что напоследок записала туда вообще какой-то мусор из поврежденного стека, или электричества хватило на половину блока, а вторую тупо не успела.<br><br>Прецедентов в начале 2000х было, причем усугублялись забавным свойством ext3 накатывать журнал необратимо и неостановимо при любом обращении к разделу, даже на чтение. (возможность принудительно заблокировать журнал появилась тогда же, когда write barriers и проверки консистентности - то есть когда уже было особо и не нужно)<br><br>Но, как видим, не стали рассказывать что "это у вас у всех диски неправильные", а сделали чтоб работало правильно (и flush cache тоже научились делать на шатдауне, хотя это и полумера, но во многих случаях ее хватает)<br><br> https://www.opennet.ru/openforum/vsluhforumID3/114186.html#42 Fri, 04 May 2018 20:31:42 GMT &gt; У ext4, к примеру, ее нет (потому что нет "софтапдейтов"). При неподтвержденном <br>&gt; write накатится лишний раз уже накаченное <br><br>И journal_checksum добавили туда чисто по приколу, ага. <br> https://www.opennet.ru/openforum/vsluhforumID3/114186.html#41 Fri, 04 May 2018 20:25:22 GMT разрыв пердака засчитан.<br><br>(неумение пользоваться гуглем тоже)<br><br>&gt; Это неправда.<br><br>"главное - верить!"<br> https://www.opennet.ru/openforum/vsluhforumID3/114186.html#40 Fri, 04 May 2018 20:04:10 GMT &gt; он и посейчас, только вместо (вместе с) улета приложений по sigsegv или <br>&gt; кернельного oom - локапы и битые пулы.<br><br>Что ж ты врёшь?<br><br>&gt; Доулучшали.<br>&gt; Именно по той причине, что тех частей, которые есть в соляре, и <br>&gt; которыми невозбранно пользуется arc.c, у фри нет. И своих нет (там <br>&gt; память жрать может не только ARC, и результат будет ровно тот <br>&gt; же - памяти дофига, но приложению ее не дают, а при <br>&gt; попытке поискать - виснем, потому что поиску в ядре не хватило <br>&gt; памяти, а свопаться само ядро не умеет, поэтому своп стоит пустой)<br><br>Это неправда.<br> https://www.opennet.ru/openforum/vsluhforumID3/114186.html#39 Thu, 03 May 2018 19:04:40 GMT &gt; Этот дистриб не для декстопа же.<br><br>этот - именно для десктопа и для недо-сереров в единичном экземпляре. (зачем бы туда тащить mate с мазилой, действительно)<br>То что его еще выпускают - хороший признак, значит разработчики еще едят собственную выпечку, а не сплошь пуссиэкзешники.<br><br>Для голого сервера делаются OmniOS и этот, joyent'овский, опятьзабыл.<br>Только они все полуживые, к сожалению.<br><br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/114186.html#38 Thu, 03 May 2018 18:55:37 GMT &gt; А если почитать оригинал, а не слушать перепев Рабиновича^W поха, то проблема <br>&gt; там в write cache самого диска и фейковом подтверждении синка без <br>&gt; записи на носитель.<br><br>да-да, все на свете диски неправильные, у нас works as intended.<br><br>&gt; "Правильной работой диска" назвать это можно разве что перепив смузи и навернувшись <br>&gt; с гироскутера.<br><br>лолшта? Вы хотите выключить кэш у hdd ? Или возврат success это неправильная работа writeback кэша? <br><br>проблема там в непригодной для работы с кэширующими носителями структуре журнала (и, кажется, еще и неумении системы делать syncronize cache на shutdown). У ext4, к примеру, ее нет (потому что нет "софтапдейтов"). При неподтвержденном write накатится лишний раз уже накаченное (ничего не изменится) или не накатится последняя запись из лога (пропадет бесследно только что созданный файл, но fs останется консистентна) <br>У zfs тоже нет, поскольку COW. Либо пропадет последняя операция, либо операция выполнится но метаинформация останется старой и fs будет выглядеть, ка https://www.opennet.ru/openforum/vsluhforumID3/114186.html#37 Thu, 03 May 2018 18:39:43 GMT &gt; А у соляры для начала управление памятью нормальное сделали? Чтобы ядро могло <br><br>да.<br>&gt; при нужде резко отобрать у дискового кэша память, а не прикладывать <br>&gt; приложения out of memory при отожранном кэше. А то когда *bsd <br>&gt; передирали ZFS из соляры - в этом аспекте вышел трэш и <br>&gt; угар.<br><br>он и посейчас, только вместо (вместе с) улета приложений по sigsegv или кернельного oom - локапы и битые пулы.<br>Доулучшали.<br><br>Именно по той причине, что тех частей, которые есть в соляре, и которыми невозбранно пользуется arc.c, у фри нет. И своих нет (там память жрать может не только ARC, и результат будет ровно тот же - памяти дофига, но приложению ее не дают, а при попытке поискать - виснем, потому что поиску в ядре не хватило памяти, а свопаться само ядро не умеет, поэтому своп стоит пустой)<br><br>Я бы с интересом послушал опыт с ZOL на ту же тему - как взаимодействует "неродной" ARC, "родной" buffer cache и предоставление памяти приложениям. Подозреваю, тоже все плохо, или совсем плохо, тех механизмов там тоже нет.<br> https://www.opennet.ru/openforum/vsluhforumID3/114186.html#36 Thu, 03 May 2018 18:32:35 GMT &gt;&gt; Теоретическая копи/паста которая в реальных боевых условиях под нагрузкой нефига не значит.<br><br>она на виртуалке на древнем ноуте нихрена не значит. Виснет 100%. Рецепт известен, причины тоже (их больше одной), толку от этого знания ноль.<br><br>&gt; Есть доказательства? Приведите - почитаем.<br><br>я затрахался их приводить в каждом треде, упоминающем ваш фетиш.<br>Пользуйтесь поиском. Или гуглем. Нет, не исправлено, с 2016го года, когда проблема всплыла глобально. Разработчики предпочитают заметать крошки под ковер.<br><br>И нет, у индианы все хорошо, у нее по другому устроена система управления памятью в принципе, проблема существует только в вашей любимой системе, жертве копипастинга и гонора горе-"разработчиков". <br><br>Только прикладных задач под ней не решают, поэтому пользы от этого никому и никакой.<br><br>