https://opennet.ru/openforum/vsluhforumID3/40808.html Daniel Phillips представил (http://lwn.net/Articles/272534/) начальную реализацию виртуального устройства Ramback, представляющего собой RAM-диск снабженный средствами синхронизации данных на жесткий диск. При тестировании нового устройства, было зафиксировано увеличение производительности примерно в 25 раз, при гарантированной сохранности информации в случае перезагрузки (после загрузки задумано автоматическое восстановление содержимого Ramback-диска).<br><br><br>К сожалению, высокая производительность имеет свою цену - Ramback не рассчитан на обработку ситуации экстренного пропадания питания в случае сбоя, он лишь помечает в реальном режиме времени измененные области данных, далее периодически запускается процесс сбрасывающий изменения на диск. В случае если до сброса изменений произойдет сбой - данные будут потеряны и для восстановления целостности Ramback-диска понадобиться выполнение fsck.<br><br><br>Кроме того, Christoph Lameter предложил (http://groups.google.com/group/fa.linux.kernel/msg/0a7...<br><br>URL: http://www.lin https://opennet.ru/openforum/vsluhforumID3/40808.html#28 Sat, 29 Mar 2008 22:11:02 GMT &gt;&gt;&gt;Фо фре вообще элементарно делается gmirror'ом между file-based и ram-based <br>&gt;&gt;&gt;md-устройствами. <br>&gt;&gt;Политика зеркалирования там подкручивается? Тут это как раз важно. <br>&gt;Из man gmirror: [...]<br>&gt;Нужен prefer, видимо. <br><br>Эх, надо было сразу уточнить.<br><br>Про запись речь, не про чтение. Чтоб если файл потрогали два раза за полминуты с интенсивным обменом -- то долетело, и то может быть не сразу, последнее состояние на момент простоя. А не залипли после того, как первое решило синкнуться, почувствовав странички грязными.<br> https://opennet.ru/openforum/vsluhforumID3/40808.html#27 Tue, 25 Mar 2008 12:38:41 GMT &gt;Думаю, примерно то же, что у tmpfs, только с требованием сохранения данных <br>&gt;между загрузками. <br>&gt;<br>&gt;Например, пакеты или исошки в памяти собирать сильно веселей, поскольку то, что <br>&gt;должно бы писаться на диск из грязного кэша -- до диска <br>&gt;обычно не долетает за ненадобностью. <br><br>В fido7.ru.unix.bsd делал такое для /usr/obj на swap-backed md-диске - ускоряло да. И даже между перезагрузками выживало, пока эту недокументированную фичу не поломали.<br> https://opennet.ru/openforum/vsluhforumID3/40808.html#26 Tue, 25 Mar 2008 12:29:44 GMT &gt;&gt;Фо фре вообще элементарно делается gmirror'ом между file-based и ram-based md-устройствами. <br>&gt;<br>&gt;Политика зеркалирования там подкручивается? Тут это как раз важно. <br><br>Из man gmirror:<br><br>-b balance Specifies balance algorithm to use, one of:<br><br> load Read from the component with the<br> lowest load.<br><br> prefer Read from the component with the<br> biggest priority.<br><br> round-robin Use round-robin algorithm when<br> choosing component to read.<br><br> split Split read requests, which are big-<br> ger than or equal to slice size on N<br> pieces, where N is the number of<br> active components. This is the<br> default balance algorithm.<br><br>Нужен prefer, видимо.<br> https://opennet.ru/openforum/vsluhforumID3/40808.html#25 Mon, 24 Mar 2008 11:13:03 GMT &gt; Про ccache они не в курсе часом? ~/.ccache/ можно организовать [симлинком] на <br>&gt; отдельный tmpfs уже сегодня. <br><br>А почему не в переменную окружения? Неужели опрос симлинка выходит дешевле опроса переменной окружения?<br> https://opennet.ru/openforum/vsluhforumID3/40808.html#24 Mon, 24 Mar 2008 04:18:30 GMT Если Ramback можно использовать и как обычный рамдиск без средств синхронизации с тем же самым увеличением производительности по сравнению с Ram-диском в 25 раз, то это уже само по себе ценное достижение. Рамдиск как рамдиск широко используется в Live-системах (RTK GNU/Linux, например ;-)). Маршрутизаторы, опять же. Да много где. Даже на обычном дестопе многие дистрибутивные ядра, до монтирования основной корневой ФС подгружают необходимые модули с рамдиска. Так что, думаю, в скором времени фишка под названием Ramback войдет в майнлайн ядра.<br> https://opennet.ru/openforum/vsluhforumID3/40808.html#23 Sat, 22 Mar 2008 02:23:14 GMT Думаю можно применять для хранения баз 1с.<br><br>Да и еще применений придумать можно...<br><br><br> https://opennet.ru/openforum/vsluhforumID3/40808.html#22 Fri, 21 Mar 2008 15:48:31 GMT &gt;ram disk активно пытаются у нас внедрить разработчики для разработки - исходники <br>&gt;на ЖД, а результаты компиляции в память <br><br>Про ccache они не в курсе часом? ~/.ccache/ можно организовать [симлинком] на отдельный tmpfs уже сегодня.<br> https://opennet.ru/openforum/vsluhforumID3/40808.html#21 Fri, 21 Mar 2008 15:47:20 GMT &gt;Второй патч, более интересный, но закрадываются сомнения... <br>&gt;1. Проблема фрагментации обычно возникает как раз на большом кол-ве, но маленьких <br>&gt;malloc_ов.<br><br>Тут про выделение заведомо известно, что оно короткоживущее -- соответственно возможно решать другую задачу (иначе).<br><br>&gt;2. А если не удастся выделить непрерывную область виртуальной памяти. <br><br>Берётся из отложенного в нижней.<br><br>Лучше на LWN читать: http://lwn.net/Articles/272693/ (A better DMA memory allocator) и http://lwn.net/Articles/273030/ (How to use a terabyte of RAM)<br> https://opennet.ru/openforum/vsluhforumID3/40808.html#20 Fri, 21 Mar 2008 15:42:22 GMT Во мы лохи.... <br>Цэ есть ничто иное как реклама этого девайса - http://www.violin-memory.com/products/violin1010.html<br><br>