Hetzner Cloud Documentation
docs.hetzner.com
docs.hetzner.com
I guess they could write, if you must assume the volumes are served by the same cluster or not - e.g. for the case where you need more performance or storage space as one big filesystem/ file (and want to do a software RAID/ use ZFS/ btrfs/ bcachefs etc. to achieve that).
There is no note about the performance/ limits of the NVMe storage that the instance resides on - they generally seem to be much faster.
Also in 2021, I got a clarification by Markus Schade that:
"Instance disks are included in every server type and defined in the same way as physical drives (80 GB = 80000 MiB) rounded to the nearest 4MB. As we are offering dedicated as well as virtual servers, we use GB on all our pages for included drive sizes to reflect this. Volumes are different because it is a pay as you product. As such they are sized and invoiced on a per GiB basis."
Volumes seem to be base 2.
Unfortunately, Hetzner also have no log about internal migrations of VMs or relevant adjustments to the underlying host that would be visible to the user. What seems to be some kind of infrastructure adjust seems to have had a negative influence on Java GC at least once. It would be easier to debug these things if you didn't have to ask support first and make yourself look like a fool at times.
I'd say that means they have RAID for the usual purposes but you can't configure it directly.
> 80 GB = 80000 MiB
80 GB = 76293.9 MiB = 80000 MB
At that time I wrote this excerpt:
> I observed the /dev/sda disk that comes with our VM is supposed to be 80 GB big.
> If this was to a decimal base, it would be exactly 80 000 000 000 bytes big, but
> it is actually 81923145728 bytes big. That is 80.003072 GB if you define a GB as
> 10^6 \* 1024 bytes and add 3 KiB (3072 bytes). This is quite non-standard, because
> you basically mix bases without any sort of transparency.
>
> We also have a volume mounted. /dev/sdb is currently 70 GB big where you seem to
> define a GB as IEC GiB or 2^30 bytes.