Balrog

Thank you very much for this idea and solution! It looks very nice! I will have a deeper look if I got some time. May I ask if you use rsync for the copy process? I use for backup and recovery a combination of Titanium Backup (for full backup of all apps including the data) and a rsync of the internal sdcard to the NAS afterwards (made with shell scripts and no graphical output). So I have all data including apps with data pictures and so on available for a full restore.

I think that is the point to look at: I always use my B120i controller in AHCI mode under ESXi and have never suffer from bad performance or compatibility problems. But I use the internal B120i in AHCI-mode only for the ESXi-Datastore (with a SSD connected) and make a passthrough of an extra Dell H200-HBA in IT-mode to the Xpenology-VM. That works rock stable and fast. With this combination I even don't need to pass the single harddisks as RDM to the Xpenology VM.

My idea is to make a sidegrade and move your installation to DS3615. I have 3 Microserver Gen 8 which runs very fine with DSM 6.2.2 under ESXi and bare metal. I have made some tests with DS3617 and only got issues I never see with the DS3615-Branch. There are howtos in this forum how to make the move from DS3617 to DS3615. The most important part is to set the NIC to Intel E1000E (if on ESXi) or use a real Intel NIC and set the hdd-controller to SATA. Details are written in the howtos for sure.

I use Dell H200 and Dell H310 flashed to IT Mode with great success under ESXi 6.7 update 2 as passthrough and as bare metal install.

Nice! I am glad that you found the reason for not having enough space on the system for an upgrade. So this thread will be a good help for similar issues.

I think that this issue has nothing to do with the boot sdcard. The error points to the first partition where the DSM itself is installed. I assume that maybe logfiles or something in this direction is filling up the space. You can make a quick check if you connect as root via ssh and type "df -h" ("df" stands for "disk free" and "-h" for "human readable"). Then you get an overview over the partitions and the free space on it. Here an example: root@joe:~# df -h Filesystem Size Used Avail Use% Mounted on /dev/md0 2.3G 1.2G 1.1G 52% / I would use afterwards "ncdu / -x" which will output what directories and files are consuming the space. On my installation I have installed "optware-ng" and I am sure that "ncdu" is part of optware. So you must search for how installing "optware-ng" if you want use "ncdu". An alternative which runs out of the box but without the nice navigation options from ncdu is "du -chx / | more". This command gives you also the output which folders and files are using the space on the root partition but just as a pure list without a navigation option. I hope this helps to get an idea how to manage the problem with no space available for the update.

Nice that you found a solution and post it.

I would boot a Linux live system from an USB-Stick and have a look how the SATA-Ports are shown to the system. Then you will not have to guess and can give the loader exactly information about the SATA-Controller/-Ports.

If you just booted from the usb-stick and not have installed DSM via the assistant than you can't login to the system. If DSM is installed you can login as "root" if you wish or with "admin" and change to root afterwards (the same way you use if you login via ssh).

Can you please write is the transfer speed of this setup is sufficient for you? I have a similar setup (the only difference is that I make a complete passthrough of the H310 HBA instead of making RDMs of the single disks) and think about updating from 6.2 to 6.2.1. But I want to make this step only if the transfer speed is similar to the 6.2-setup.

Thank you for the summarization and sharing your experiences!

@flyride: Thanks for the link to your article from march! I missed it and the information in it is very useful.

Thanks for the pictures! It seems that you are right with the idea of the internal hdd as a "save harbour" for the dsm itself. The dsm partition is a mirror and the "repair" forces a sync which seems to be needed as the usb harddisks are recognised slower than internal hdd harddisks. But if this is the only issue I think you can live with it especially as this is only a backup system.

@shrabok: Thank you very much for your article and your experiences with this idea. I have a few questions: - Do your end configuration is a SHR1 Volume consisting the 2 TB internal hard disk AND all external USB-Drives or do you use the internal drive as a "basic" drive without redundancy and have made a SHR1-Array only with the external USB-Drives? - Does your SHR1 Volume survive a reboot without breaking the the array? Or are you forced to rebuild the array after every reboot? - do you get issues with the sleep mode of the USB drives? Most of them have a real aggressive power save mode build in and maybe this will lead to problems. For my USB drives (which are currently working as normal external USB drives) I have written a little script which runs at start to disable the sleep mode (or better explained to lower the load/unload-cycles).

Nice finding. i hope there will be some time an update for the vmxnet3 driver as it has much advantages over the pure intel driver.