https://www.opennet.dev/openforum/vsluhforumID3/119452.html В ходе обсуждения тестов планировщика задач, один из участников дискуссии привёл пример того, что несмотря на заявления о необходимости сохранения совместимости при разработке ядра Linux, недавние изменения в ядре нарушили корректную работу модуля "ZFS on Linux". Линус Торвальдс ответил, что принцип "не ломать пользователей" относится к сохранению внешних интерфейсов ядра, используемых приложениями в пространстве пользователя, а также самого ядра. Но он не охватывает отдельно развиваемые сторонние надстроки над ядром, не принятые в основной состав ядра, авторы которых на свой страх и риск сами должны отслеживать изменения в ядре...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52164<br> https://www.opennet.dev/openforum/vsluhforumID3/119452.html#382 Mon, 05 Feb 2024 13:39:50 GMT Сказали докер-адепты&#8230;<br> https://www.opennet.dev/openforum/vsluhforumID3/119452.html#381 Mon, 27 Jan 2020 12:33:39 GMT &gt; Жаль только что в корень ее не поставить стандартными средствами.<br><br> Что за бред ты несешь?<br> https://www.opennet.dev/openforum/vsluhforumID3/119452.html#380 Thu, 23 Jan 2020 16:57:51 GMT &gt;&gt; про это курятник, как показала жизнь за прошедшие четверть века, задумываться <br>&gt;&gt; принципиально неспособен.<br>&gt; Как-то так оказалось что остальные - еще более не способны. Бсды - <br>&gt; даже выкинутую подачку ассимилировать толком не могут. Не говоря о том <br>&gt; чтобы самим что-то разработать. Ладно, за исключением NetBSD и hammerfs. Этот <br>&gt; куда ни шел - но маргинален просто до жути.<br><br>Движение ради движения &#8212; это мастурбация. У движения должна быть цель, станция назначения. Все основные проекты семейства BSD движутся в направлении целей, обозначенных в их философских основаниях.<br><br><br>&gt; Винды? MS как максимум смог выжать из себя ReFS. С большим отставанием, <br>&gt; только для серверов и ... там даже близко не идет речь <br>&gt; ни о каком паритете по фичам ни с btrfs ни с <br>&gt; zfs, как я понимаю.<br><br>Каких тебе не хватает фич? Свистелок и перделок? Есть. Запускать винду на суперкомпьютерах? Но зачем?<br> https://www.opennet.dev/openforum/vsluhforumID3/119452.html#378 Wed, 22 Jan 2020 08:17:54 GMT &gt;&gt; raidz из трех дисков при чтении первращается в страйп на три диска.<br>&gt; Оп. Не на два ли? (n+1) жеж.<br><br>нет. Повторяю - времена raid3 с выделенным "+1" - в глубоком прошлом, именно потому что он был - тормоз. В raidz, как и в raid5/6 данные пишутся на все диски равномерно (как и контрольные блоки - тоже на все примерно поровну), и имеются специальные механизмы выравнивания производительности (чтобы нечаянно не получить снова raid3 ;) Поэтому M*(n+1) последовательных блоков читаются с "n+1" дисков параллельно (а контрольные блоки просто не читаются вообще).<br><br>То есть тут результат теста - +- похож на правильный. (и, разумеется, эффективность не в точности n*100%, обязательно будут потери)<br><br>Вот как они получили последовательную запись (и хрен с ним с процессором - что, dma тоже отменили?) - это другой вопрос. Возможно, оно так делает на зеркале ради гарантий целостности. Возможно просто баги реализации. А может это так проявляет себя write multiplication. Поскольку у нас нет никакой информации о технике тес https://www.opennet.dev/openforum/vsluhforumID3/119452.html#377 Wed, 22 Jan 2020 07:50:24 GMT &gt; причем бы тут объем?<br><br>При том что "подскок *выше* 100". При одинаковом объёме данных, с добавлением шпинделей в массив данные будут съезжать наружу блинов. Добавляя %% к скорости чтения/записи. И уменьшая latency в тестах.<br><br>&gt; 2x3 = 6, что тут не так?<br><br>То что не совсем 6. Было "лучше чем могло", стало "хуже чем могло". Что дало повод предположить влияние выравнивания данных.<br><br>&gt; писать на mirror - двойной объем.<br><br>Судя по скоростям, писали не через IDE. И даже старый шедулер с одной очередью на всех в linux не был настолько гуано. Чтобы не уметь параллельную запись. Ну вот разве что в тестовом стенде было ровно одно ядро CPU (которое висело в iowait)?<br><br>&gt; raidz из трех дисков при чтении первращается в страйп на три диска.<br><br>Оп. Не на два ли? (n+1) жеж.<br> https://www.opennet.dev/openforum/vsluhforumID3/119452.html#376 Mon, 20 Jan 2020 14:26:00 GMT &gt; Возможно, про "одного" несколько перегнул. См. ниже.<br>&gt; Но касаемо приведённых замеров, хотелось бы увидеть методику тестирования.<br><br>сорри, пропустил в свое время. Да, методика тестирования незнамочего там - причудливенькая.<br>На некоторые вещи, тем не менее, ответ напрашивается:<br><br>&gt; 1. Умеем читать оба диска в зеркале по очереди?<br><br>очевидно что наоборот - умеем читать параллельно. А писать - не умеем. (логичненько)<br><br>&gt; 2. Тестировали примерно на 50% объёма одного НЖМД. Отсюда подскок выше 100% <br><br>причем бы тут объем? Зеркало и должно выдавать 2x на чтение - поскольку блоки читаются параллельно (при нормальной реализации, а не как у linux md)<br><br>&gt;&gt; 3x 4TB, mirror (raid1), 3.7 TB, w=106MB/s , rw=49MB/s , r=589MB/s <br>&gt; 3. Чтение таки не совсем линейное. На 3-х шпинделях попадает хуже. (Или <br><br>2x3 = 6, что тут не так?<br><br>&gt; 5. Гоп,стоп. Это что же, 200М/с = скорость *одного* диска? А что <br><br>да. <br><br>&gt; тогда надо сделать, чтобы в *два* раза просадить запись?<br><br>писать на mirror - двойной объем. <br><br>&gt; 6. https://www.opennet.dev/openforum/vsluhforumID3/119452.html#375 Mon, 20 Jan 2020 08:39:09 GMT Производительность может и хуже, зато пользы столько что выше крыши. Я пользуюсь этой фс еще со времен соляриса, а теперь и на линуксе и доволен очень. Жаль только что в корень ее не поставить стандартными средствами. <br> https://www.opennet.dev/openforum/vsluhforumID3/119452.html#374 Wed, 15 Jan 2020 15:31:28 GMT Работают.<br> https://www.opennet.dev/openforum/vsluhforumID3/119452.html#373 Wed, 15 Jan 2020 13:37:28 GMT &gt;&gt; окей. как долго вы юзали Photoshop, а затем перешли на Gimp? сколько <br>&gt;&gt; теоретической базы у вас есть по Photoshop?<br>&gt; Зачем мне теоретическая база _по фотошопу_? Я читал теоретическую базу _по фотографии_ <br><br>затем, что очень легко рассуждать, как просто с фотошопа перейти на гимп, если ни тем, ни другим на самом деле пользоваться толком не умел. На что ваш оппонент прозрачненько и намекнул.<br><br>&gt; начиная с бумажных книжек для пленки и заканчивая форматами файлов, принципами <br><br>здорово, что тут как раз пропущено все, о чем, собственно - фотошоп. Слово я не назову, понимающий да угадает. А вы - пропустили теоретическую базу, угу.<br><br>&gt; работы матриц, алгоритмами и всем таким. По поводу чего у меня <br>&gt; есть сносное понимание процесса, dos и donts и всего такого. Но <br><br>ок, опишите своими словами сущность процесса unsharp mask (надеюсь, он уже есть в gimp?). Я достал пивас и сникерс, и удобно уселся в кресле.<br><br>&gt; это для себя, чтобы фоткать получше чем рядовые хомяки, выставляющие объектив <br>&gt; в солнце.<br><br>эт