richardjj627

A couple of things * the command should be 'resizepart' - not 'resize part' * if you plan to increase past 2TB then the initial volume needs to have been created >2TB to force GPT.

Great article which gave me exactly what I needed. A summary of what I did to extend the Storage Pool is as follows: sudo su parted # use ls /dev to check which SD*s are available - in my case, SDB. select /dev/sdb unit s # this will show results in sectors rather than bytes. print free # make sure all looks fine and you know what you'll be extended resize part > enter the number of the device you'll be extending > enter the end sector from the print free command quit All done! Everything else can be done via the GUI.

Yes, agreed. Software RAID offers a ton of flexibility and a ton of the arguments for hardware and ASIC type RAID are becoming moot, even in the enterprise. I'm less worried about keeping up with the latest version but did notice a few horror stories of people 'accidentally' updating to the latest version offered by Synology. It's almost a miracle that DSM works so well virtualised and on 3rd party hardware.

Regards to your first point. I just want to run RAID at the hardware level. The RAID card with its battery cache will be best placed to provide the redundancy and performance. At the DSM level, it'll just see one big single disk which is resilient behind the scenes. For context, this is a little hobby project made from bits and pieces of old servers. I had the option of a DL380 gen8 but my wife wouldn't be too happy to have one of them whirring away under the stairs. In my case, the Microserver should suffice. I'm guessing the reason why the DSM developers didn't include a GUI option to extend a single drive is that this is something which would just never happen in the purely physical world in which Synologys reside. The article sent by luchuma seems to have potentional. Your suggestion will work too but needs the swing space to make it happen. I'll keep you all apprised of progress. One interesting thing. I'm using Jun 1.02b alongside DSM 6.2.1-23824 with absolutely no problems. Should I be nervous? I see you're still on 23739U2 from your signature.

You are probably right but I'm going to give it a try anyway. I guess, from a DSM point of view, if the Syno can only see one disk (which it'd presume would be physical), that there would be no reason to programaticially faciliate its extension. A 4TB disk will always be a 4TB disk. Obviously this changes when you get into RAID1 as there is resilience.

Many thanks for your reply, Jarugut. Yes, I've got a ton of free space to hack around with and would lose nothing valuable by hacking around. A nice position to be in :-). I've tried directly extending the VMDK with the VMWare console. The disk itself increases in size with DSM but the Storage pool stays exactly the same with no obvious option to extend it. I'm guessing DSM sees what appears to be one single disk and the developers determine this to be non resilient. I wonder if there is a way of hacking the Storage Pool with mdadm from an SSH session or something like that?

Quick and hopefully easy question... I have a virtual installation of XPE running on ESXi 6.5. The base hardware is a HP Microserver Gen8 with a proper RAID card added (i.e. not the 120 which doesn't do RAID). My physical disks are running in a hardware RAID set and are presented to the VM host and one big 8TB VMFS volume. My question: I've built my vSynology with a single 2TB VMDK presented (in addition to the 50MB boot laoder, of course). What would be the neatest way to increase the size of the Storage Pool and volume to say 3TB? I could theortically create an additional 1TB VMDK and add it to the pool as a RAID0 but I don't like the idea of multiple VMDKs, especially as I grow the storage further. Obviously all the RAID, resilience and other clever stuff is being handled at the hardware level so DSM level RAID5 and the like just wastes space. What I would really like is to extend the VMDK to 3TB then grow the pool and volume within DSM. A monolithic VMDK would be easier to manage. Any ideas? I'm prepared to be destructive with my set up. This is a relatively new project. Much appreciated, Richard