flyride

Your system is booted. You seem to have three NICs on that system. One is not able to get a DHCP address or does not have an IP address assigned at all (the 169.254.239.179). Have you tried navigating directly to the other two? https://192.168.50.68 https://192.168.50.150 Have you tried ssh/telnet to these addresses?

That wasn't the question. What stats does SMART return? There are error types it can report that can implicate the drive performance, the cables, or both.

mSATA drives are usually electrically connected to whatever SATA controller in is onboard so they typically work. M.2 is a flexible connector that can support mSATA storage, NVMe storage, M.key devices, or combinations of the three, depending upon the desire of the board manufacturer. NVMe for primary storage is technically not supported for baremetal, although there have been attempts to hack it in. The most reliable way to support NVMe is to spoof it in as emulated SATA using a hypervisor. Probably not a good use of resources in OP's proposed system.

If you are just using USB as a backup target inside the NAS, that will work.

OS goes to a partition on every SATA disk. USB disks cannot be used as NAS storage without some hacking of config files. Nothing wrong with a fanless system (my main NAS has 10x SSD's and a fanless power supply) but XPe really wants SATA ports for horizontal expansion.

What does SMART say? You might have bad SATA cables

There is nothing inappropriate about that rc script. You can easily disable that particular check in Security Advisor, or not run it at all.

Security Advisor reports any startup script that is unknown or modified from the distro as anomalous. You will need to inspect the file and determine if it is malware on your own. Post the contents here if you'd like more advice.

Yep, that all makes sense. In the end you are trying to get more PCIe slots so maybe another motherboard is in order...

That commonly is true IF the M.2 port is mapped to SATA (for a SATA SSD instead of NVMe). The use case you were contemplating would not disable the port.

You will need to share a lot more information (i.e. loader version, DSM platform type, previous installed version, version upgrading to, etc). Please post a new question for this in the General Questions forum.

Motherboard spec sheet says M.2 port is PCIe 3.0 x4 That is also typical with M-key designation. 2.0 is half the bandwidth of 3.0, so this matters. So the analysis should be with the card and per the parameters I gave you above. You should be ok with only HDD's, but if you want SSD's I agree look for a 4x card if such a thing exists. Second issue of course is that it must be compatible with existing drivers or extra.lzma.

M.2 is a type of port which is an interface into a SATA controller, or a miniaturized PCIe slot, or both (configurable to one or the other). If it is NVMe compatible or M-key, it's a PCIe slot. It should be PCIe 1x, 2x or 4x, depending upon the motherboard implementation. The card itself can be PCIe 1x, 2x or 4x as well. The actual lanes in use is defined by the slot or card with the least lanes. Maximum bandwidth of a SATA-3 port is 600 MBps. Maximum bandwidth of a 5-port card would be 3 GBps. This requires SSD's as real-world performance of spinning disks max out around 200MBps per channel. PCIe 3.0 performance per lane is roughly 1 GBps. Thus, a 1x connection will definitely be maxed out by 5 channels of SSD 2x connection would potentially be maxed out with SSD (but probably ok with spinning disk) 4x will always have headroom regardless of the SATA device types

https://xpenology.com/forum/topic/58662-redpill-loader-information-thread/

You make several good points. I've had the following written up for some time but haven't posted but it appears now is the time as it overlaps with your opinion. This is just my opinion, and one not even doing active development - but there are three issues that probably need resolution: 1. A comprehensive installation guide 2. An automated fix for the minor version upgrade procedure 3. More success data for complex installations and issue recovery Regarding the latter, I am still periodically reading about how large arrays suddenly drop off. Do we know why? Are we sure that they are recoverable? This is the main reason I haven't moved my production data to a new loader or DSM 7. There also seems to be a move to proliferate to a lot of Synology hardware platforms. This is good on the developer side if it enhances the available hardware ecosystem. It's bad for testing and predictability as it has the potential to severely dilute each platform's population and issue reporting. Personally, I'd like to see the dev community consolidate on specific platforms before calling it mainstream. I will add to the Loaders and Platforms matrix when Redpill solutions are published for non-dev release.

Docker apps that are running on DSM are using Synology Docker package. You specify a folder for docker and that can be backed up or replicated in its entirety (this doesn't absolve you from properly configuring your docker apps with a data folder mounted to the image). For true hot swappability you may want to look into the HA services that Synology offers. But that has been hit or miss with XPe and I haven't really heard of anyone relying on it. I just use Snapshot Replication to keep my archive server in sync. This wasn't an option with your 213j (doesn't support btrfs/snapshots) but if you are running two XPe systems, the choice becomes available.

https://kb.synology.com/en-global/DSM/tutorial/Why_does_my_Synology_NAS_have_a_single_volume_size_limitation https://www.reddit.com/r/synology/comments/kgcr1q/200tb_btfrs_volume/

Maybe this will help you: http://vcloud-lab.com/entries/general/emulate-hdd-as-ssd-flash-disk-on-esxi-and-vmware-workstation

Each core and HT are individual threads. 918+ is intended to support 4 cores with HT. If you wanted more than that the current option is DS3617xs which does not include any kernel hooks for QuickSync. There aren't any really good options (yet) for supporting more than this along with QuickSync, but DS3622xs+ may be emerging as the way forward.

It shouldn't matter if it is recognized as SSD or NVMe at all. It's virtualized so it won't be faster or better if the virtual presentation is one format or another. AFAIK any device can be designated as cache.

Couldn't say. Corruptions happen and power outages seem as good as any of a reason. It is quite possible to plug the UPS into the ESXi host and add that USB device to your XPe VM profile, so that it can see the power status. btrfs is not really designed for an offline repair. If it can, it repairs itself in real-time. Everything I have ever seen posted from Synology is to offload, re-create and repopulate if there is sustained corruption on a btrfs volume. This is opposite the advice given for ext4 (bring offline, run repair utilities, restart). The typical method of backing up @appstore is Hyper Backup as it is not accessible from the filesystem sharing toolsets. Syno apps typically store configuration data in @appstore and you control where they store their data elsewhere, but it's not a hard and fast rule. It is one of the reasons I converted from Syno apps exclusively to Docker apps - to improve portability (and get better access to new releases in most cases). If you are asking me personally, loader development and ongoing upgrade procedures still are in early beta status. I haven't moved any production data to 7.0.1 yet. I also don't pay much attention to documentation authored or hosted elsewhere, so I can't comment on that guide. Your risk tolerance may be higher, and many are using 7.x. No idea what your disks and requirements are. I maintain all my datasets replicated on two XPe systems, so I use RAID5 only (actually RAIDF1) as two-disk redundancy seems overkill. I also prefer plain RAID over SHR (what you have now) as it makes recovery simpler, which you just experienced. But if you need the flexibility of SHR, there really isn't a substitute except making multiple Storage Pools.

Looks like it is a 7.x development (a good one IMHO). Nice find.

DSM 7 loaders are in development status ("beta" is probably an embellishment). But people are installing and testing on a regular basis. Read the relevant dev threads (it's a long read). The tinycore thread is probably the most turnkey/polished install available thus far.