6 ms·

Spun one up and ran some quick numbers on a 100GB volume: root@ubuntu-1gb-nyc1-01:~# time dd if=/dev/disk/by-id/scsi-0DO_Volume_volume-nyc1-01 of=test.dat bs=1

Spun one up and ran some quick numbers on a 100GB volume: root@ubuntu-1gb-nyc1-01:~# time dd if=/dev/disk/by-id/scsi-0DO_Volume_volume-nyc1-01 of=test.dat bs=1024 count=10000000 10000000+0 records in 10000000+0 records out 10240000000 bytes (10 GB) copied, 58.0655 s, 176 MB/s real 0m58.248s user 0m2.608s sys 0m41.604s Some quick observations: * Easy to add one when creating a droplet; by default they let you create volumes with these sizes: 100GB, 250GB, 500GB, 1000GB, 1.95TB; it's also really easy to create your own size. * You can resize in any increments; took about 4 seconds to go from 100GB to 110GB with no downtime; you obviously need to resize/manage the mounted volume yourself. * [Edit 1] Deleting the droplet does NOT destroy the volume. Worth keeping in mind when you spin them up/down. * [Edit 2] Remounting an existing volume to a new droplet was quick and painless.

olavgg 10y ago
Thank you for telling us these details. I can't help but I note that you benchmark the drive with a block size of 1024. Minimum block size of a modern SSD is 4096, anything lower would just cause unnecessary load. Also if you want to benchmark a drive/block storage I highly recommend using fio.
- wiremine 10y ago
  Thx for the tip, I'll give that a try!
  - ymse 10y ago
    fio --direct=1 --rw=write --ioengine=libaio --runtime=300 --bs=4k --numjobs=4 --iodepth=32 --size=2G --name=4096-direct --filename=/dev/vdb --group_reporting This is my "dd" test for any storage system. Filename can be a regular file; you can also pass --directory instead. I would love to see numbers for both this test as well as with --bs=4M. Also experiment with --rw=rw|randrw|read :) (and make sure your device is large enough to hold numjobs*size)
Thaxll 10y ago
Don't use dd for those tests it's really bad, especially on VMs.
- kornish 10y ago
  What do you mean by "really bad", out of interest?
  - Thaxll 10y ago
    I should rephrase that, it's not "really bad" but the way that most people use it is not good. The main issue is caching from your OS, and caching from the hypervisor ( the one that runs your VM ). There is also the problem about i/o syncing. By default OS buffer the data before writing it to disk.
    - acdha 10y ago
      That's true of all I/O benchmarks, even those which try to do things like call fsync since the lower layers often lie about whether something was committed to durable storage. The only way to do benchmarks reliably is still to make sure that you're reading/writing data which is much larger than the available cache. In the case of dd, the real reason why it's often a misleading benchmark is that it's the best-case scenario: full-size streaming I/O where each block is only accessed once. Some applications do have that kind of operations pattern but most don't and can see very different performance characteristics because they depend on things like file creation/deletion overhead, random I/O within an open file, read and write contention if the same file is being accessed by multiple processes, etc.
  - beachstartup 10y ago
    probably because it can produce meaningless results. it's extremely hard to tell where which bits actually ended up, ram, or disk, or some other intermediate buffer or cache on a controller somewhere. we use fio with a standard test config across systems for meaningful results.
- pepr 10y ago

olavgg 10y ago

Thank you for telling us these details. I can't help but I note that you benchmark the drive with a block size of 1024. Minimum block size of a modern SSD is 4096, anything lower would just cause unnecessary load. Also if you want to benchmark a drive/block storage I highly recommend using fio.

wiremine 10y ago
Thx for the tip, I'll give that a try!
- ymse 10y ago
  fio --direct=1 --rw=write --ioengine=libaio --runtime=300 --bs=4k --numjobs=4 --iodepth=32 --size=2G --name=4096-direct --filename=/dev/vdb --group_reporting This is my "dd" test for any storage system. Filename can be a regular file; you can also pass --directory instead. I would love to see numbers for both this test as well as with --bs=4M. Also experiment with --rw=rw|randrw|read :) (and make sure your device is large enough to hold numjobs*size)

Thaxll 10y ago

Don't use dd for those tests it's really bad, especially on VMs.

kornish 10y ago
What do you mean by "really bad", out of interest?
- Thaxll 10y ago
  I should rephrase that, it's not "really bad" but the way that most people use it is not good. The main issue is caching from your OS, and caching from the hypervisor ( the one that runs your VM ). There is also the problem about i/o syncing. By default OS buffer the data before writing it to disk.
  - acdha 10y ago
    That's true of all I/O benchmarks, even those which try to do things like call fsync since the lower layers often lie about whether something was committed to durable storage. The only way to do benchmarks reliably is still to make sure that you're reading/writing data which is much larger than the available cache. In the case of dd, the real reason why it's often a misleading benchmark is that it's the best-case scenario: full-size streaming I/O where each block is only accessed once. Some applications do have that kind of operations pattern but most don't and can see very different performance characteristics because they depend on things like file creation/deletion overhead, random I/O within an open file, read and write contention if the same file is being accessed by multiple processes, etc.
- beachstartup 10y ago
  probably because it can produce meaningless results. it's extremely hard to tell where which bits actually ended up, ram, or disk, or some other intermediate buffer or cache on a controller somewhere. we use fio with a standard test config across systems for meaningful results.
pepr 10y ago