flyride

Ok, here's where things are. The system knows it has a RAID5 array and sees one valid array member. Something has happened to the other two drives that seems to have overwritten the MD superblocks that identify partition #3 as part of the RAID5 array. There is no graceful way of recovering this. But we can force the system to think that those disks are part of the array. This is a non-reversible operation and may still not result in the recovery of any data. For example, if the filesystem base structures was overwritten, it may be impossible to get the volume to mount. Or, some of your files or directories may be corrupted or missing. Needless to say, I hope you have this data backed up somewhere. So before you decide to do any of that, let's get some answers to the following: 1. What happened before, or to cause this? You said "unknown reasons" but is there any information at all about the circumstances? 2. Is there anything that was deliberately done to get rid of /md1 and /md0 partition members for the SSD's? 3. Anything else you think is relevant should you decide to try to brute-force recover your array?

So the two missing RAID5 disks exist but the partition looks badly damaged. Is the partition structure even still present for the RAID5? # fdisk -l /dev/sdh # fdisk -l /dev/sdj

Well this does look a little odd. I would expect your /dev/sda and /dev/sdb in md0 and md1. Is this a baremetal install? Post the output of the following commands. You'll need to be root (sudo -i) # mdadm --detail /dev/md3 # mdadm --examine /dev/sd[hij]3 | egrep 'Event|/dev/sd'

Log in via ssh and post output of "cat /proc/mdstat"

This is correct; the loader is modified by DSM on installation or upgrade, so they need to be unique to the DSM install.

Life is good...

Why use XPEnology and DSM then? A regular Linux server with Samba will suffice... in any case the answer to your original question is to just alllocate a virtual disk.

config SYNO_SATA_PORT_MAP bool "Modify SATA Hosts Port Number" depends on SYNO_FIXED_DISK_NAME default y help <DSM> #18789 Reads Sata-Port-Mapping information and forces the sata hosts to initialize specified number of ports. This makes the disk name not skip some characters. Notice - Do NOT set the port number out of the range that [0-9]. It supports as most 9 ports now. For example, SataPortMap=4233 means the 1st host use 4 ports, the 2nd host use 2 ports, the 3rd and 4th host use 3 ports. config SYNO_DISK_INDEX_MAP bool "Modify Disk Name Sequence" depends on SYNO_FIXED_DISK_NAME default y help <DSM> #19604 Add boot argument DiskIdxMap to modify disk name sequence. Each two characters define the start disk index of the sata host. This argument is a hex string and is related with SataPortMap. For example, DiskIdxMap=030600 means the disk name of the first host start from sdd, the second host start from sdq, and the third host start sda. config SYNO_SATA_REMAP bool "Re-map Disk Name Sequence" depends on SYNO_FIXED_DISK_NAME default y help <DSM> #47418 Add boot argument sata_remap to remap data port sequence. For example, sata_remap=0>4:4>0 means swap the first disk name and the 5th. The following is the remap result. ata1 - sde ata2 - sdb ata3 - sdc ata4 - sdd ata5 - sda config SYNO_SATA_DISK_SEQ_REVERSE bool "Reverse Disk Port Sequence" depends on SYNO_FIXED_DISK_NAME default y help <DSM> #23278 Add boot argument DiskSeqReverse to reverse the ports of each SATA chip. For example, for a 4 SATA chips model, 4 ports of each SATA chip. We want to reverse all 4 ports of 1st chip, no modification of 2nd chip, reverse 2 former ports of 3rd chip, and reverse 3 former ports of 4th chip. The boot argument should be DiskSeqReverse=4023. And the sequence of disk is: 1st chip - [sdd, sdc, sdb, sda] 2nd chip - [sde, sdf, sdg, sdh] 3rd chip - [sdj, sdi, sdk, sdl] 4th chip - [sdo, sdn, sdm, sdp]

https://www.ebay.com/itm/6G-pcie-sata-3-ASM1166-chip-pci-express-sata-3-0-expansion-6-Port-X4-X8-X16-fast-/224081366566

This may be of assistance: https://xpenology.com/forum/topic/28183-running-623-on-esxi-synoboot-is-broken-fix-available/

All countries with Amazon storefronts have the Western Digital CMR 12TB external drive on sale for approx US$175, lowest price ever for about 24 hours from this posting. https://www.reddit.com/r/DataHoarder/comments/ja8hqm/wd_elements_12tb_17499_amazon_us_prime_day/ Many other global retailers are price matching. These drives are white-label equivalent to WD Red, and very suitable for "shucking." I bought 4 to replace my 4x8TB archive drives.

Again, you are losing much of the benefit of DSM if you insist on using a physical RAID controller in a hardware RAID mode. Most can be put into AHCI mode or a bunch of RAID 0 disks and then can provide direct access to the drives via RDM or passthrough. RDM simply translates the native drive instructions into whatever virtual controller dialect you want to use in your VM, otherwise providing direct access to the disk. This has benefits for disk portability to baremetal, etc in addition to giving DSM the direct disk access it needs to do what it does best. But if you insist on using the hardware RAID, there is no need to RDM. Just create a virtual disk and be done with it.

See this thread: https://xpenology.com/forum/topic/31456-start-adding-disks-with-plan-to-epxand-storage

If Docker is not installed, and Document Viewer is selected from the Package Center, the following appears: So it would appear that the official Synology Document Viewer package is now a Docker container. I for one applaud this.

0C is to hide your loader. This matters for ESXi but I didn't think it was necessary for baremetal. If you want to try again, try 0C0800

It's a PCIe 2.0 2x bus, still 1Gbps limit and quite oversubscribed, but it seems like it would work... too bad they couldn't put a PCIe 4x interface on it. Glad we could sort this out enough to make it tolerable for now.

@IG-88 have you seen this card? 2x JMB575 so 10 ports, not port multiplied... https://www.amazon.com/Ableconn-PEX10-SAT-Port-Express-Adapter/dp/B0177GBY0Y

Which DSM platform are you choosing? If it's DS3615xs or DS3617xs on loader 1.03, you must boot the USB key in CSM/legacy BIOS boot mode. 6.2.3 is the latest DSM but your hardware can run either 6.2.2 or 6.2.3 just fine. I assume the 1060 is a Nvidia video card and that doesn't matter or get used by DSM at all. Take a look at this table and the prerequisites in the decision tree: https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/

Did you prepare a 1.03b USB loader and properly set VID/PID?

This should work https://archive.synology.com/download/DSM/release/6.2.3/25426/DSM_DS3617xs_25426.pat

Many are still running 5.2 now, years after Syno stopped putting out updates for it. We all may do the same with 6.2.x as long as there is no loader for 7.x. My point is you should choose your current DSM using XPEnology based on features you need, not a kernel version.

What future? It is very unlikely there will be anything new other than bug fix updates to 6.2.x so why does the kernel version matter? I think the only reason Syno updated the kernel for 918+ was for nvme support. If someone makes a loader for 7.x, you will replace everything anyway (new kernel on all platforms).

Not quite enough information to be sure, but it seems like we should keep exploring the relationship between the drive and the controllers. Not sure what the impact is of not having disk write cache enabled on LSI, but lack of local write cache is certainly going to impact performance to some extent, and it would be only represented on the dd throughput or writing files to NAS, not on the raw read tests. Technically you should be able to move the drives around between the controllers with no problem. Always make sure the arrays are healthy before doing this. We really don't have any control where the filesystem writes the files, you would assume it would start by filling up from the first sector (md2) but hard to know for sure without digging into btrfs itself. Two things I'd think about trying at this point are: 1) updating the LSI controller driver (IG-88 extra.lzma) and 2) replacing the LSI with an AHCI-compatible controller (super inexpensive now). I really don't think reinstalling DSM is going to help at all.

Kernel age is not relevant to the 6.2.x codebase. With 7.x even 3617xs has newer kernel.