по уму FX-8320e это энергоэффективный процессор, с урезанием TDP и частот, остальное там то же самое
FX-8320 требует 125W, в списке поддерживаемых мамкой вон у вас показана поддержка другого процесссора с таким потреблением, поэтому шансы что заработают - высокие
хм, это кажется метод как бы колбек на пересылаемые данные в сокет
проверяй, где то отправляешь вместо буфера с данными - null
ничто не мешает на время поиска проблемы подсунуть в этот код логирование ошибки (с дампом стека), проверяешь, если !el то дампишь в лог файл содержимое (new Error()).stack
не важно, очевидно что либо ошибка в модуле (маловероятно но бывает) либо неправильные параметры в используемых методах, так всегда бывает когда не проверяешь на ошибки каждый вызов, способный и выдать
Нагенирируют тьму логики и кода там где это не требуется, потом тратят огромные ресурсы чтобы решить проблемы, возникающие из-за такого велосипедостроения.
Сам не пользовался но в прошивке мерлин есть mesh bed leveling (ключевые слова для гугла), т.е. формируя команды gcode можно сначала получить карту высот, а потом ее загрузить
Правильный вопрос к топиккастеру - какие именно запросы будут происходить. Записывать данные поступающие линейно можно хоть в свой файл, но вот если читать их нужно будет не только по времени тут уже нужны индексы, и sql базы данных позволяют такие создавать очень эффективно
Damian Lewis, dd используют не как эффективный способ, а как самый простой и доступный везде (dd по умолчанию устаналивается практически в каждом дестрибутиве)
К тому же при использовании hdd линейное чтение по скорости на порядок превышает режим работы со случайным доступом, т.е. если сравнивать копирование файлами и копирование с помощью dd, то dd будет быстрее даже не взирая на то что копируется много лишнего пустого пространства (точнее соотношение пустого к заполненному должно быть очень высоким чтобы это было заметно). Плюс, со скопированного с помощью dd диска можно востаналивать удаленные файлы как с оригинала.
clonezilla (точнее используемый ими partclone) - отличное решение, умеет копировать почти линейно как dd без копирования незанятого пространства. Поддерживает все популярные файловые системы, включая ntfs и умеет делать ресайз диска (осторожно, из-за особенностей ntfs бесконечно уменьшать за счет незанятого пространства не получится, тут только по файлам остается копировать)
Аппаратный raid с ram НЕ ПОМОЖЕТ от слова никак, а вот гемороя создаст прилично.
С некоторым красноглазием можно потюнить параметр read-ahead (по больше от дефолтного, в мегабайтах или десятках), но тогда не рекомендуется использовать cow файловые системы, можно сделать свой механизм предварительного сохранения данных большими блоками, готовых решений я не видел, но и не искал серьезно, алгоритм там простой - необходимо увеличить минимальный размер данных, который будет считываться и записываться на диск, с принудительной буферизацией (пока не наберется этот блок данных, на диск не записывать), и для 300 потоков это очень большой объем.
ssd буфер это компромисcное решение, позволит дешево (без заметного кодинга) решить проблему, ограничив срок просмотра архива часами (а кому надо больше?)
Если решать в лоб, скорость работы диска падает на порядок, поэтому такие системы тянут от силы пару десятков потоков на hdd. Судя по прайс листам, готовые системы именно такие. Т.е. если по расчетам на срок хранения нужны несколько десятков дисков, то почему нет