Никто и не спорит, что это не норма. Один или несколько повреждённых заказов не должны мешать отправлять другие.
Другой вопрос - почему они повредились. Я бы рекомендовал проверить диск на ошибки на всякий случай.
Для заказов создана новая версия протокола их хранения *.v1 и они должны быть более устойчивы к повреждениям.
Одновременно добавлен пропуск повреждённых заказов для двух известных случаев.
В следующей версии такого уже не должно случаться. Если будет снова - значит создам ещё один баг.
Скорее всего причина почему они повредились - это внезапное отключение пк. Но не факт. Я не знаю как оно там в ноде внутри работает.
Полезно папку заказов вынести на ссд, рядышком к ранее вынесеной БД.
Ломаются они видимо на неординарных пиках дисковой загрузки типа 15000iops.
Сам не сталкивался, но в чате несколько человек с этим сталкивались (как минимум 4) в середине октября, после чего все кто читал их и попереносили на ссд. После этого все устаканилось.
@Alexey было бы неплохо вынести циферки по отправленным/неотправленным ордерам в апи, раз уж это оказалось настолько выжным параметром. Для дальнейшего мониторинга.
1 Like
u menja oni na SSD i tozhe 2tk slomalis, ne pomozet
1 Like
В Windows оно по умолчанию на том же диске, куда установлено. Если ОС на SSD - будет на SSD
А вообще, можно и переместить:
Создайте пожалуйста feature request тут: Storage Node feature requests - voting - Storj Community Forum (official)
Тогда вообще печаль. Я, наоборот, перенёс с SSD к данным. Ни на одном из трёх совершенно разных узлов не сломалось ни одного, даже в v0 протокола.
Даже pi3 справилась
Тут наверное стоило бы разобраться какая ос что делает когда не может отработать вал запросов к диску.
Я помню что у многих проблемы с unsent orders сопровождались поломкой баз, причём комп работал штатно. Скорее всего это либо отброшенные записи на диск, либо убитый процесс storagenode чем то вроде oom kilker
Корень проблемы, как я считаю, в бешеных iops
1 Like
Вообще очень интересная тема на самом деле.
У меня по факту две ОС - нативно в Windows, нативно в Linux (Debian, raspi), Windows Docker desktop с использованием VM Linux.
Особых проблем не было и заказы не повреждались, хотя я ожидал их увидеть хотя бы для Windows Docker desktop, потому что он использует SMB для мапа диска.
Однако и большой нагрузки на этих узлах нет - они почти полные или полные. Так что мой случай как раз нельзя использовать как пример, если проблема именно в бешенных IOPS.
Конечно они периодически очищаются от удаленных данных и загрузки снова идут полным ходом, однако это не то же самое, когда узел пустой, я полагаю.