Leaderboard

Should we be concerned? Long term, with the intermediate updates not working? (assuming we already have backups and have all the functionality we need) Define concern? Is there anything that can be done with 6.2.4 that cannot be done with 6.2.3? The assumption has always been is that any update has the possibility of breaking the loader. Could DSM 6.2.3-25426 Update 3 possibly be the last safe Xpen Version for us using Jun's Loaders? Maybe. Is Jun still kicking around to come up with a possible solution? Or anyone else? Jun is the only one that can answer that question. My guess is that if they are at all interested in keeping XPe alive, they will be focusing on DSM 7 and not a minor "last-of-the-line" patch on a DSM version that already works quite well. How often in the past have 2 consecutive updates failed right out of the gate like the latest intermediate updates have? 25554 and 25556 are in fact the same update. Updates either work, or they don't. Is there any particular reason, such as a major OS change, or Synology wanting to rid us "Open Sourcers" of this beautiful software, that is causing these updates not to work? I am sure Synology would prefer that we do not use DSM in this way. They probably consider DSM as entirely their IP even though it is derived from GPL-licensed open source. They could probably set up a Secure Boot solution that would probably shut DSM to us forever. But that would also limit backward compatibility with the hundreds of thousands or millions of units they have shipped up until now, and probably interfere with any cloud service/virtualization plans they have in the wings. So I don't think that this or the other issues that have been worked through in the past to be a result of an "anti-XPe" effort on the part of Synology. Just to be clear, DSM 6.2.3 "broke" the loader. FixSynoboot corrects the failure without modifying or updating the loader. We have also had problems with PCI hardware compatibility, and were able to work through solutions. Other than the irrational FOMO, I'm not clear why getting 6.2.4 working is anyone's priority at this point. Personally, I'm far more interested in DSM 7.

Информация для архива, если вдруг кому тоже нужно будет. Давеча понадобилось мне заменить практически вышедший из строя один из ЖД в массиве JBOD с сохранением данных. Делается это вполне легко, при соблюдении некоторых условий. Далее описаны условия и алгоритм замены. Основные условия: 1. Исходный диск должен быть живым. Т.е. нужно чтобы все смогло прочитаться, а это значит постоянно нужно мониторить SMART, на бэды и на "повторные подключения" и реагировать быстро, если начались неисправности. Повторные подключения вообще беда, когда диск не может запуститься. Мои две недели (когда это нужно было сделать, а не откладывать в долгий ящик) как то немного затянулись и руки дошли только сейчас. Исходный диск удалось все же запустить. Кроме того, важно, конечно, чтобы диски были одинаковой емкости или, чтобы диск назначения был больше (но в этом случае на нем останется неразмеченная область). 2. Ничего не трогать на NAS, заранее знать какой диск где физически расположен в корпусе, какому порту SATA соответствует и за каким номером числится в НАС (т.е. заранее их пометить). В моем случае был диск номер 4. 3. Процедура восстановления не хитра. Загружаемся live cd linux (в моем случае linuxmint). 4. Ставим пакет gddrescue. 5. Выясняем где и какой диск, например, с помощью gaprted. 6. Запускаем процесс блочного копирования командой: sudo ddrescue -f -n /dev/sdc /dev/sda /media/mint/Zalman_prog/mapfile где, sdc - исходный диск, sda - диск назначения, mapfile - полное имя лог файла. ddrescue - копирует буквально все, включая UUID - это важно. Можно использовать православную dd, однако ddrescue имеет хорошие преимущества. 7. Ждем. В моем случае 12 часов на 3ТБ. В процессе видны были затыки через равные промежутки, т.е. винчестеру плохо было. 8. Вставляем новый винчестер в НАС. Загружаемся. НАС скажет, что системные раздел разрушен на этом винчестере. Восстанавливаем его в Диспетчере хранения, вкладка Обзор. 9. Собственно все. Вероятно, на время замены диска не следует включать НАС с неполным набором винчестеров. Если момент будет упущен и диск скопировать не удастся, вероятно собрать JBOD в первоначальном виде уже не получится, однако, подключив исправные диски к компьютеру с linux, теоретически их можно смонтировать и вытащить информацию которая на них записана. Разумеется, та информация которая была на неисправном HDD будет потеряна. Полная версия замены диска в JBOD здесь. Там же есть алгоритм по-сложнее, если наскоком заменить диск не получилось. ---- ЗЫ: На счет использования JBOD, правильно это или не правильно. У каждого свои задачи и предпочтения. В моем случае JBOD был выбран умышленно, потому как очень легко масштабируется + за счет количества дисков (данные разбросаны) увеличивается скорость чтения в определенных случаях. Кстати, на счет того, что в JBOD данные записываются последовательно - по-моему это не совсем так, мониторя графики видно, что диски работают в том числе и одновременно. На картинки 5 и 6 диски - кеш SSD - тоже офигенная штуковина как оказалось. Пользователей 200+.

I also did encountered slow read speeds about 2mbyte/sec inside of a gigabit network. Turned out to be the MTU. Did switch it to 9000, and now the speed is where it should be, around 110mbyte/sec. Find it here:

Have you disabled C1E in the bios? What DSM version are you trying to install?