flyride

What cards do you need? Do you have SATA ports on your motherboard (you haven't posted what model it is yet)? Do you have an Ethernet port on your motherboard? You may not need to acquire anything additional.

I wouldn't bother with that CPU upgrade. Your current CPU is fine, I don't think you would be able to tell any difference. Cores are more important than hyperthreading. In regard to transcoding, the word simply refers to the action of transforming an audio/video stream from one output format to another. "Hardware" transcoding on Synology means that the transcoding software is leveraging Intel Quicksync instructions on the CPU, far faster than "software" transcoding which is just a program on the system (in most cases, FFMPEG). Software transcoding requires a lot of CPU, usually more than is available on Synology or XPenology systems. So many folks wants hardware transcoding so that they can watch their stored media in real-time on a variety of output devices without storing multiple copies. Video cards also perform hardware transcoding, but this is not supported at all in the DSM ecosystem. All that said... your entire hardware platform is unsuitable for transcoding due to age. You would need to build up a platform on a Haswell or later CPU and run the DS918+ version of DSM to even attempt it.

You're looking at this the wrong way - with another system that was not using btrfs, you would not know when your files had bit-level errors as there would be no checksum. This is the dirty reality of the storage industry - spinning disk drives encounter a statistically measurable number of write errors that are never noticed in standard, non-redundant applications. btrfs scrubbing allows the system to use the redundancy of the RAID array to correct the errors detected by checksum. So do that; your system is working as designed. Also, you don't have "one parity drive." With MDRAID, parity is spread across all the drives. I realize this is somewhat semantic, but I see people describe the system this way on a regular basis, potentially leading to loss of data if the wrong decision is made.

I suppose virtualization, either with Synology VMM Manager or wrapped in a hypervisor. That's what I use my own 4-core system for, in any case.

DSM can use a maximum of 16 threads due to kernel limitation. That means 8 cores + hyperthreading, or 16 cores with hyperthreading disabled. That said, only the very largest Synology systems have 8+ cores (only the FS series). So you will have plenty of horsepower, even with 4 cores. (EDIT: this is not entirely correct, it depends on DSM platform, see here for current information) If you have the option, ECC is always better than non-ECC for a data-intensive application, as the memory system will correct single-bit errors in real-time and not crash the system, and will detect multi-bit errors and halt rather than propagate bad data.

https://event.synology.com/en-global/dsm_preview

Thinking back, there is new Ironwolf-specific code in 6.2, Synology was touting it as a feature upon release. It seems like this may be related to that. If you do figure out what file(s) are locking your drive out, please post as I doubt anyone here has encountered it before now.

That's why I referred to Intel chipset SATA controllers - any Southbridge-type controller made by Intel in recent years 100% works (or at least I have never run across any that did not). I219-V: A lot of folks will be happy to see the new Intel PHYs getting supported!

FWIW DS3615xs is an i3-4130, DS3617 is a Xeon D. There are no Xeon-specific dependencies on any of the XPE-enabled code bases. Synology VMM has always been a bit finicky. For my own use, it did not take me long to move those workloads to ESXi instead.

They are usually printed on a sticker, physically on the card or bracket.

I apologize, you said you were on 6.2 and the last XML file referenced was for 6.1.x. I haven't yet had to recover a flagged drive status on 6.2. If you want, try renaming those two files adding extension ".bak" and reboot, see if the drive status changes. In any case, I think the error is cosmetic. This drive (/dev/sdm) has valid data on it and is present in all your arrays. Do not try to fix the array with the shell commands you found. e2fsck has no business being executed against a btrfs file system. And those commands attempt a brute force creation of an array over top an existing array, which is a high risk scenario. Rebuilding the array should be done from Disk Manager, especially when you have a SHR array. You only must add the 5TB disk /dev/sdl for repair; again, the Ironwolf drive is already present and working.

"IronWolf is displayed as "En panne" (="Failed" or "Broken") but with 0 bad sectors (but the SMART Extended test returned few errors) " Sorry, does this mean that the SMART Extended test reported errors, or that no errors were reported? If errors were reported, what were they? Based on that report, do you feel confident that the drive is okay? If you think the drive is error-free, delete the Smart Test log history by removing /var/log/smart_test_log.xml and reboot again.

Don't reinstall/migrate. That creates risk for no reason. Let's try and rename the disk_overview.xml to disk_overview.xml.bak and reboot again.

Ok, try this: Note the serial number of /dev/sdm (the drive identified as Failing) ssh into your system and edit /var/log/disk_overview.xml Delete the xml tag for that specific drive (identified by the serial number) Reboot Hopefully that will get rid of the drive failing error, which we believe to be spurious. If everything then looks clean, initiate a repair using the remaining Toshiba "Initialized" drive.

You keep referring to /dev/sdm as faulty. What makes you think it is faulty? Post a screenshot of what is making you come to this opinion. If it is a Smart status, please post the Smart detail page for that drive. I suspect that you have some sectors flagged for replacement on /dev/sdm, and DSM is reporting the disk as "Failing" or "Failed" which doesn't actually mean anything other than the number of sectors exceeds the threshold you have set in DSM for bad sectors. I also believe all your arrays are in critical state, so once we validate /dev/sdm you will probably want to initiate an array repair with /dev/sdl. Only then should you consider action on how to correct /dev/sdm status.

Intel CPU is generally more compatible than AMD. Anything current runs fine - i.e. 64-bit, Haswell or later. Transcoding is problematic no matter what you select, but any modern Intel processor with iGPU is technically capable. I haven't heard of any Intel embedded (chipset) SATA controller that did not work, ever. The DSM/Linux driver for SATA is generic and not tied to chipset. NVMe support is gimped by Synology but we have a patch now that fixes it if you must run NVMe drives. Or you can always virtualize and solve the problem that way. The only other consideration is the network card. The latest embedded Intel NICs are not always supported. So plan on a $20 PCIe Intel CT card and/or a 10Gbe card like Mellanox or Intel X557 and you'll be ready to go. See the hardware support guides in my signature for supporting information (or just go to the guide section of the forum).

E5645 is Westmere-EP, which is Nehalem family. This precedes Haswell by two generations, so no. https://en.wikipedia.org/wiki/List_of_Intel_Xeon_microprocessors

As long as your hardware supports GPT partitions, the theoretical limit is 9.44 zettabytes per partition. I think Linux basic limit is 8 zebibytes, btrfs has a maximum limit of 16 exbibytes and if you use SHR (and therefore LVM), you will be limited to 8 exbibytes So you are probably okay.

The above from your initial post, then your most recent report. FWIW a drive with status "Initialized" means it is not in use in an array.

If you do not bond the four ports and instead assign a discrete IP to each port and connect a device directly to it (which is the equivalent of your statement above) you will definitely see throughput that approximates 4x 120MBps. The NAS disk performance will then be the limiting factor. When you bond, that perfect distribution is not assured. I cannot advise you on that. If your issue is poor hash distribution, you'll have to experiment and see. There are no standards for exactly how a hash is computed for bonding, so it will be up to the switch firmware and Intel driver. The reality is that the hashing methodology really only works with a target client pool of 2n or 3n (when n is the number of bonded ports).

M.2 drives should work as cache if you follow this: https://xpenology.com/forum/topic/13342-nvme-cache-support/?do=findComment&comment=126807

Well that may be good news; hopefully it all works out for you! When this is all done (and you have your data back) please consider changing your r/w SSD cache to read only. Performance improvement from r/w SSD cache can be achieved far more safely with more RAM (and most "normal" NAS users will never see benefit from r/w cache anyway). Another way to look at it is this: If r/w cache crashes, your volume is corrupt (that is why Synology wants RAID 1 so that a simple hardware failure does not destroy a volume). If r/o cache crashes, you can just delete the cache and your volume is intact.

Based on your description, I think you understand a single client device won't get any additional bandwidth from a bonding configuration. The only benefit will be from multiple, concurrent clients. Even with concurrent clients, there is a pseudo-random method (usually hashing of IP address, IP socket ports or MAC) that causes a TCP/IP stream to traverse a specific ethernet port. How it works is specifically dependent upon the bonding method used. But having 4 clients running concurrently does not mean that all four ports will be used. It is possible to have 4 clients hash to a single port and be no better off. Your switch maximum throughput performance may be a factor as well.

Well, this is a start. It seems that you have two choices: Revert the DSM back to your original 6.1.x version (where all your drives could be accessible). There are no "unknowns" here as it clearly was working before; there is no reason it cannot work again. I still think we are missing some information as to why this happened in the first place (what was done with "basic check on DSM" in first post). Troubleshoot 6.2.2 controller configuration to try and get all drives accessible. There are many "unknowns" here and you are essentially doing an initial install and hoping your data will come over cleanly. I think this path is a mistake if the safety of your data is important, but this is the path you have been following. My advice is to go back to #1 and your original configuration. Do you have a backup copy of your original loader? If not, can you configure it exactly as you did before? You have not mentioned your DSM code base, but I assume DS3615xs, please confirm. Rather than to try and install DSM back to your old drives, disconnect all data drives (including cache) except a new 1TB test disk installed to an unused motherboard SATA port. Then install 1.02b loader and basic 6.1.7 DSM clean install. Don't build a Storage Pool or volume, just get it to boot up and Control Panel/Disk Manager accessible. Set up SSH access and report back.

I tried to write up a plan to assist you but am not going to post it as I realize it won't help right now. You are still in crisis mode (your words) and need to get control of the situation. Whenever an event like this happens, the objective should be to minimize the change in the system. Unless you are very experienced, you won't know what changes may make recovery impossible. Given the frantic and unstructured effort thus far, I have little hope for recovery, but if there is any chance for online help: be patient, slow down the change rate and post more comprehensive information about the system state. What was the event that caused the original outage? You stated "basic check on DSM" what is that specifically? Was it a DSM upgrade (planned or unplanned)? Other system upgrade? Hardware failure? What is the exact configuration of the system currently? What type/size of drives connected to what controllers? List everything out, don't summarize. What loader, what DSM version? Does DSM boot? What is the state of the system? Can all the drives be seen? Does the volume show crashed? Is there a disk pool state? Post screenshots. If DSM boots, SSH should be accessible. Can you validate the SSH/TELNET configuration in the Control Panel? Are you running a custom port? Getting to a shell will be important to improve your chances for recovery. If it isn't clear from the recommendations above: if you want help here, STOP CHANGING THINGS and gather more information.