Возможно ли объеденить RAM и SSD в 1 диск?

кэш маленький

Ты мысленный эксперимент проводишь, или что? У актуальных райзенов кеша под сотню мегабайт. Умножь на 10. Оперативу ты уже выбросил, почему нет.

я ничего не выбрасывал, это выше ещё один упоротый регистрант предлагал(какая-то эпидемия тупака у регистрантов). а кэш просто так нарастить нельзя - падает скорость. поэтому и существует целая иерархия памяти в виде разных уровней кэшей, оперативы и потом уже диска

я ничего не выбрасывал

Как и я ничего не сравнивал. 🤦‍♀️

Но разница всё равно не так драматична. Можно и кеш внутри самого SSD нарастить, который — та же DRAM.

А почему крутые ssd сравниваются с как бы устаревшей памятью?

Кстати, описанная ТСом задача как то подозрительно напоминает симуляцию этого самого майнерского сверхбыстрого ssd…

960 Evo как раз времён актуальности скайлейка и DDR3L, во-первых, а, во-вторых, в том же сообщении и так абсолютно прозрачно сказано почему.

Ещё бы, ведь все терабайтники уже скупили.

Раньше была PCI-карта (задолго до этих ваших NVME), куда натыкивалась оперативка, и это работало как очень быстрый диск (там ещё батарейка есть чтобы данные при выключении не пропадали какое-то время).

Вот идея для стартапа. Оперативка - туземун.

Без тестов памяти как стораджа все твои предположения в 1000 раз разницу такая же туфта.

Жалко у меня нет сервака с парой терабайт ОЗУ, можно было бы дать туда нагрузку от виртуалок тестовых и посмотреть как там iops и задержки.

если вы про chia, то не стоит волноваться, в такой объем влезет только 1 файл, а им их надо десятки, сотни, я видел статью на хабре где они вовсю трахают корпоративные SSD с большим ресурсом

чтобы это было выгодно майнерам нужна с система с 8TB ОЗУ, и притом чтобы это все не кусалось по деньгам в сравнении с теми же SSD

а ценник будет космический, корпоративные SSD будут куда проще и быстрее (16 потоков не предел), даже если это будет расходник

и кстати такие умные уже были, арендовали сервер у амазона с кучей памяти и получили 9 часов генерации 1 файла )))

серверные процы плохо тащат 1-поток, хуже чем десктоп значительно, а файл то только 1 )) вот такой и результат…

так что забейте, в теории может и выглядит красиво, а реальность говорит, что лучше убить SSD ))

fio на tmpfs дает 3.2Gb/s 4K операций в 1 поток (декстоп), это в 20 раз больше чем у XPoint, и на 2 порядка больше чем у NAND

не сработает схема, читайте выше

если вы про chia, то не стоит волноваться, в такой объем влезет только 1 файл,

Но если формировать файл в ОЗУ, а потом сбрасывать на накопитель, то потребуется только от уполуторенного до удвоенного размера ОЗУ, чтобы можно было одновременно рассчитывать новый и сбрасывать на накопитель уже сформированный файл.

То есть "в первом приближении" рецепт такой:

1. Берём ОЗУ не менее одного, но желательно более двух размеров файла и увеличиваем размеры буферов записи до размера большего чем один файл и остальное за вычетом необходимого для программ ОЗУ отводим под кеш записи в размере двух файлов, а остальное под кеш чтения.
2. Пишем скрипт который при появлении нового файла будет принудительно сбрасывать на диск кеш записи предыдущего файла(вроде как есть такая команда).

3. SSD подключаем к райдконтроллеру в raid0 для того чтобы иметь возможность паралено писать и читать файловую систему на собранных в рейд накопителях.(рейд должен быть именно аппаратным, програмный эффекта не даст)
4. На файловой системе включаем принудительную компрессию уровня zlib:6 так как хотя так файл и пишется немного медленнее, но зато потом намного быстрее читается, к стати в этом случае можно синхронизировать все файлы без разбору, так как зарезервированное нулями место просто сожмутся при компрессии.
5. Объём ОЗУ можно увеличить с помощью memory raiser expansion board

Разрешаю@объединяй.

никуя не получится ))

по каждому пункту можно слить эту идею

но так ради примера, просто вытекает из определения: На файловой системе включаем принудительную компрессию уровня zlib:6

а толку если внутри рандомные данные? там же энтропия ~ равна объему самого файла, ты почти ничего не сожмешь

разработчики всей этой поебистики далеко не долбаебы

Этому аргументу, только в варианте для сжатых видеофайлов и архивов, уже несколько лет, но его авторы не могут даже в простой силлогизм: "уровень сжатия случайных данных тоже случаен", не говоря уж о эксперементальной проверке своего утверждения.

В общем какие там у тебя ещё есть возражения?

разработчики всей этой поебистики далеко не долбаебы

Не факт, то что они умеют программировать не означает того, что они умеют в комплексный анализ проблемы.

Уровень сжатия случайных данных «случаен» со средним ~1 (обычно меньше) на любых относительно больших объёмах данных (более метра)

Первые два пункта куда эффективнее решать на уровне кода. Например mmap’ом. Так можно и под размеры оперативки подстраиваться и использовать её для создания большего числа файлов одновременно.

тебе бы почитать про математическое ожидание

Это всё теория, но по факту сжатие сжатого архива или сжатого видео даст экономию 10% объёма.

Ты вообще можешь провести эксперимет: взять большой файл и пожать в zlib:6, получившийся архив снова пожать в zlib:6, и сноа и снова.

Прежде чем у тебя перестанет уменьшаться объём или даже начнёт расти пройдёт не менее трёх циклов эксперимента.

Не менее, то есть жать пожатое хоть с каким-то уменьшением порой можно и более 3 или четырёх раз.

Но в целом применительно к данной теме точное ускорение авычислений надо получать тестированием.

И не заюывай того, что при оющей синхронизации sync&&sync&&sync отсутствие компрессии может привести к записи огромного количества нулей.

нет там нулей

возьми urandom например на 300MB и пожми его через zlib, zstd и тд

поделись результатами ))

мы вместе поржем )))

нет там нулей

Не забывай о чём тема, если майнер резервирует пространство на ФС то он скорее всего при резервировании будет его забивать нулями и сбрасывать их на диск при общей синхронизации будет большой потерей.

не будет, потому что в пике все пространство забито данными

если бы пространство было забито нулями но на перетасовку этой колоды не требовалось бы 9 часов

–

и мы ушли от темы,

я остановился на BRD и LVM

но пока не тестировал скорость такого решения

Что за BRD?

block ram disk

А чем тест в паре гигов принципиально отличается от теста в паре терабайт? В виртуалках может быть по 128М оперы и какая нибудь одиночная задача.

даст экономию 10% объёма.

Старым и простым алгоритмом по факту можно рассчитывать на 0-1% сжатия. Если взять медленный алгоритм с потреблением больше гига памяти, то до 5% если повезёт.

Может profile-sync-daemon поможет? Настраивается под нужного пользователя и нужный браузер. Работает с overlayfs, пишет изменения в tmpfs, раз в час синхронизирует файлы на ssd/hdd (т.е. экономит ресурс ssd). Существенно ускоряет отзывчивость при большом количестве открытых страниц. При отключении питания остаётся рабочий бэкап файлов браузера.

Кстати, присутствует в родном дистрибутиве для «малинки», работает как systemd user service, экономит ресурс sd-card.

Да просто ни раз было, что тесты на небольших данных показывают, что всё ок. А как нагрузку даёшь, то вот тут кем кончился, там кем кончился и всё лежит нафиг.

С тестами постоянно так, и не только в IT. Вроде всё проверено и перепроверено, но в реальных условиях почему то задница.