Зеркало Telegram-чата "Репка / Repka-Pi"

Статус
Закрыто для дальнейших ответов.
Добрый день, большое спасибо за обращение!
Действительно, здесь присутствует наше упущение в части того, что мы оставили возможность неконтролируемо обновить Ubuntu до новой версии. В целом хочется, конечно, сказать про Repka OS - это в первую очередь самостоятельный дистрибутив на базе Ubuntu с собственным процессом обновления через repka-config. Мы не гарантируем успех иных путей обновления Repka OS.
В связи с этим мы сделали версию, где отключили возможность обновить Ubuntu и для Repka Pi 3, и для Repka Pi 4. Данную версию мы передали на тестирование и на следующей неделе вы сможете ее скачать с нашего сайта или обновиться через repka-config. Также мы доработали статью в документации "Обновление Repka OS", в которой описали единственный правильный (что поддерживает команда разработки Repka Pi) путь по обновлению нашей ОС.
Еще раз спасибо, что обратили внимание на данную проблему!

Автор сообщения в Telegram: Репка / Repka-Pi


Здравствуйте. Прилетело обновление. Теперь только пропало обновление ubuntu из меню? Пакеты теперь будут обновляться все через обновление repkaOs?

Автор сообщения в Telegram: Maxim Taran

Ссылка на сообщение в Telegram
 
Доброго вечера! Подскажите, а репку можно грузить по сети?

Автор сообщения в Telegram: Denver


Если голая - нет, встроенного PXE нету. Однако, если как-то реализовать PXE на флешку и/или eMMC, то возможно получится.
Пробуйте, даже интересно что будет. Ведь ещё сервер сетевой загрузки потребуется со всеми причиндалами (pxelinux, загрузочный образ, TFTP, DHCP, DNS) и соответствующей настройкой, а это такое отдельное кунг-фу.

Автор сообщения в Telegram: Павел Исопенко

Ссылка на сообщение в Telegram
 
Здравствуйте. Прилетело обновление. Теперь только пропало обновление ubuntu из меню? Пакеты теперь будут обновляться все через обновление repkaOs?

Автор сообщения в Telegram: Maxim Taran


Добрый день, спасибо за обращение! Все верно, теперь единый путь к обновлениям - через утилиту repka-config. Подробнее можно прочитать в статье "Обновление Repka OS".

Автор сообщения в Telegram: Репка / Repka-Pi

Ссылка на сообщение в Telegram
 
Здравствуйте!

Подскажите, пожалуйста, неопытному пользователю одноплатников, какие есть варианты для расширения объема энергонезависимой памяти для Repka Pi 4 Optimal с eMMC в «заводском» корпусе, кроме использования SD карт?

P.S: предполагаем размещение БД с предельным объемом ~80 Гб, поэтому встроенного eMMC на 64 ГБ может не хватить. К SD есть предубеждение по части надежности и сравнительно низкой ск-и чтения/записи, а "выносить" память из корпуса через USB 3.0 и внешние жесткие пока не очень хочется (если это вообще возможно), т.к. хотелось бы сэкономить пространство в изделии.

Автор сообщения в Telegram: Daniil Kravchenko

Ссылка на сообщение в Telegram
 
Здравствуйте!

Подскажите, пожалуйста, неопытному пользователю одноплатников, какие есть варианты для расширения объема энергонезависимой памяти для Repka Pi 4 Optimal с eMMC в «заводском» корпусе, кроме использования SD карт?

P.S: предполагаем размещение БД с предельным объемом ~80 Гб, поэтому встроенного eMMC на 64 ГБ может не хватить. К SD есть предубеждение по части надежности и сравнительно низкой ск-и чтения/записи, а "выносить" память из корпуса через USB 3.0 и внешние жесткие пока не очень хочется (если это вообще возможно), т.к. хотелось бы сэкономить пространство в изделии.

Автор сообщения в Telegram: Daniil Kravchenko


По БД лучше бы иметь понимание по количеству транзакций в единицу времени. Можно кэши подкрутить и уменьшить интервал сброса данных на накопитель. В PostgreSQL например это можно хорошо тюнингануть. Плюс можно сделать тюнинг параметров ядра. У меня по сей теме есть видео, если интересно поделюсь. Хоть оно и для серверов, но подойдёт и для репки. У меня у самого БД на репке есть.

Автор сообщения в Telegram: ☭ Александр Михайлов ☭

Ссылка на сообщение в Telegram
 
По БД лучше бы иметь понимание по количеству транзакций в единицу времени. Можно кэши подкрутить и уменьшить интервал сброса данных на накопитель. В PostgreSQL например это можно хорошо тюнингануть. Плюс можно сделать тюнинг параметров ядра. У меня по сей теме есть видео, если интересно поделюсь. Хоть оно и для серверов, но подойдёт и для репки. У меня у самого БД на репке есть.

Автор сообщения в Telegram: ☭ Александр Михайлов ☭


Хорошее видео по тюнингу postgres я бы тоже хотел посмотреть. Скиньте если можно.

Автор сообщения в Telegram: A A

Ссылка на сообщение в Telegram
 
Хорошее видео по тюнингу postgres я бы тоже хотел посмотреть. Скиньте если можно.

Автор сообщения в Telegram: A A


Сюда скину, может ещё кому пригодиться
https://rutube.ru/video/ec7acc163cf4e3f91771cf20ffb3bb66/

Автор сообщения в Telegram: ☭ Александр Михайлов ☭

Ссылка на сообщение в Telegram
 
По БД лучше бы иметь понимание по количеству транзакций в единицу времени. Можно кэши подкрутить и уменьшить интервал сброса данных на накопитель. В PostgreSQL например это можно хорошо тюнингануть. Плюс можно сделать тюнинг параметров ядра. У меня по сей теме есть видео, если интересно поделюсь. Хоть оно и для серверов, но подойдёт и для репки. У меня у самого БД на репке есть.

Автор сообщения в Telegram: ☭ Александр Михайлов ☭


По детализации транзакции пока не могу сказать, планировал это решать позже или вообще "находу" из того, что будет по факту с ПО получаться, пока вопрос чуть в другой плоскости - Хотелось бы в заводской корпус пихнуть быстрый и надежный накопитель, чтоб хоть в этой части проблем не было. Но в целом, наверное, я могу пожертвовать размерами и корпусом... Тогда у меня самые лучшие варианты это (поправьте, если ошибаюсь):
- внешний SSD через USB 3.0;
- NVME через Адаптер PCIe к M.2 для Raspberry Pi 5;

Насчет видео, однозначно полезно будет!

Автор сообщения в Telegram: Daniil Kravchenko

Ссылка на сообщение в Telegram
 
По детализации транзакции пока не могу сказать, планировал это решать позже или вообще "находу" из того, что будет по факту с ПО получаться, пока вопрос чуть в другой плоскости - Хотелось бы в заводской корпус пихнуть быстрый и надежный накопитель, чтоб хоть в этой части проблем не было. Но в целом, наверное, я могу пожертвовать размерами и корпусом... Тогда у меня самые лучшие варианты это (поправьте, если ошибаюсь):
- внешний SSD через USB 3.0;
- NVME через Адаптер PCIe к M.2 для Raspberry Pi 5;

Насчет видео, однозначно полезно будет!

Автор сообщения в Telegram: Daniil Kravchenko


Я бы прогнал сначала с рабочей нагрузкой на SD (разумеется на брендовой) и понаблюдал бы за I/O. На счёт надежности то тут никто не застрахован, у меня в проде и брендовые серверы из строя выходили. Поэтому бэкапы наше всё))

Автор сообщения в Telegram: ☭ Александр Михайлов ☭

Ссылка на сообщение в Telegram
 
По детализации транзакции пока не могу сказать, планировал это решать позже или вообще "находу" из того, что будет по факту с ПО получаться, пока вопрос чуть в другой плоскости - Хотелось бы в заводской корпус пихнуть быстрый и надежный накопитель, чтоб хоть в этой части проблем не было. Но в целом, наверное, я могу пожертвовать размерами и корпусом... Тогда у меня самые лучшие варианты это (поправьте, если ошибаюсь):
- внешний SSD через USB 3.0;
- NVME через Адаптер PCIe к M.2 для Raspberry Pi 5;

Насчет видео, однозначно полезно будет!

Автор сообщения в Telegram: Daniil Kravchenko


Через USB 3.0 наверно есть смысл 2,5" жёсткий подключить? Или очень много мелких файлов?

SSD надо с максимальным отношением TBW/объёму и максимум TLC, а лучше MLC.

QLC + PLC без разговоров фтопку.

И обязательно предусмотрите обновление содержимого в SSD раз в три месяца хотя бы средствами dd. Есть сведения, что данные в SSD за год "протухают "и из-за этого падает скорость чтения. ЕСС конечно правит ошибки, но итоговок быстродействие со временем падает. Даже если стандартные 500 циклов перезаписи, то пять лет ежеквартальной перезаписи всего объёма сожрут не более 5% ресурса, десять лет - не более 10%. А через десять лет аппарат уйдёт на пенсию...

Автор сообщения в Telegram: Александр Савин

Ссылка на сообщение в Telegram
 
Товарищ с линукс сервером столкнулся с протуханием данных в твердотельниках. Сперва черепичный жёсткий материл, который как раз был не причём. Свежезаписанные файлы читались с паспортной скоростью, годичной давности - в разы медленнее.

Автор сообщения в Telegram: Александр Савин

Ссылка на сообщение в Telegram
 
Статус
Закрыто для дальнейших ответов.