7 ms·

It seems they have upgraded the specs on the block storage volumes, I have a support e-mail from December 22nd 2022 saying "You can expect a throughput of 250MB

It seems they have upgraded the specs on the block storage volumes, I have a support e-mail from December 22nd 2022 saying "You can expect a throughput of 250MB/s on average, and up to 2500 IOPS for the cloud blockstorage volumes." and that it's constant with size (which still seems to be the case). They write "It is not possible to RAID them, they are already in a RAID on the volume host." which is a mystery to me what it means exactly. 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.

2-3-7-43-1807 2y ago
> They write "It is not possible to RAID them, they are already in a RAID on the volume host." which is a mystery to me what it means exactly. 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
- kaliszad 2y ago
  See the quotes... 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.

2-3-7-43-1807 2y ago

> They write "It is not possible to RAID them, they are already in a RAID on the volume host." which is a mystery to me what it means exactly. 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

kaliszad 2y ago
See the quotes... 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.