A new Toshiba Canvio Basics 3 TB drive has two partitions:
sudo fdisk -l /dev/sdb Disk /dev/sdb: 2.7 TiB, 3000592979968 bytes, 5860533164 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 575F7910-3F93-4FC5-B50F-7D1F05810EE6 Device Start End Sectors Size Type /dev/sdb1 34 262177 262144 128M Microsoft reserved /dev/sdb2 264192 5860532223 5860268032 2.7T Microsoft basic data Partition 1 does not start on physical sector boundary.
The “Microsoft reserved” partition is new to me. It’s apparently not a real partition, but a dumping ground for Windows disk management information.
The drive is a classic Black Box:
It comes with no specs, other than the tediously qualified “3 TB”, and the Toshiba web page shows only a 5 Gb/s = 625 MB/s “Max. transfer rate”.
A quick test slurping data from the Sandisk video-rated MicroSD card extracted from the Fly6 camera shows it can write data at a sustained 21 MB/s:
time rsync -ahu --progress /mnt/Fly6/ /mnt/part/test/
sending incremental file list
./
CONFIG.TXT
33 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=29/31)
FLY6.VER
14 100% 13.67kB/s 0:00:00 (xfr#2, to-chk=28/31)
DCIM/
DCIM/15880604/
DCIM/15980609/
DCIM/15980609/09490001.AVI
499.32M 100% 21.61MB/s 0:00:22 (xfr#3, to-chk=21/31)
DCIM/15980609/09590002.AVI
497.75M 100% 20.95MB/s 0:00:22 (xfr#4, to-chk=20/31)
DCIM/15980609/10090003.AVI
499.06M 100% 21.31MB/s 0:00:22 (xfr#5, to-chk=19/31)
DCIM/15980609/10190004.AVI
278.10M 100% 21.48MB/s 0:00:12 (xfr#6, to-chk=18/31)
... snippage ...
real 6m26.272s
user 0m55.900s
sys 0m25.496s
That’s with the card jammed into an Anker USB 3.0 adapter and both devices plugged into the two USB 3.0 “Super Speed” ports in the front of my desktop box. Plugging them both into the adjacent USB 2.0 ports drops the data rate to 18 MB/s.
The Sandisk card claims read-write speeds of “up to” 20 MB/s, so it’s the limiting factor.
Getting reliable performance numbers is surprisingly difficult:
dd bs=4M count=1000 status=progress if=/dev/urandom of=/mnt/part/random.bin 4177526784 bytes (4.2 GB, 3.9 GiB) copied, 214.064 s, 19.5 MB/s 1000+0 records in 1000+0 records out 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 214.922 s, 19.5 MB/s dd bs=4M count=1000 status=progress if=/dev/urandom of=/mnt/part/random2.bin 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 217.08 s, 19.3 MB/s 1000+0 records in 1000+0 records out 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 217.08 s, 19.3 MB/s
Obviously, prying bits out of the random number generator limits the overall write speed.
Zeros, however, are cheap and readily available:
dd bs=4M count=1000 status=progress if=/dev/zero of=/mnt/part/null.bin 4169138176 bytes (4.2 GB, 3.9 GiB) copied, 23.0091 s, 181 MB/s 1000+0 records in 1000+0 records out 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 23.1775 s, 181 MB/s dd bs=4M count=1000 status=progress if=/dev/zero of=/mnt/part/null2.bin 4093640704 bytes (4.1 GB, 3.8 GiB) copied, 25.031 s, 164 MB/s 1000+0 records in 1000+0 records out 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 25.7781 s, 163 MB/s
But the caches take a while to drain, even after the command returns:
time ( dd bs=4M count=1000 status=progress if=/dev/zero of=/mnt/part/null3.bin ; sync ) 4118806528 bytes (4.1 GB, 3.8 GiB) copied, 23.0004 s, 179 MB/s 1000+0 records in 1000+0 records out 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 23.5305 s, 178 MB/s real 0m35.887s user 0m0.008s sys 0m4.824s
Dividing 4 GB / 35.9 s says the mechanical write speed is close to 110 MB/s.
Reading proceeds a bit faster, while also running up against the effect of the many caches between the spinning platter and the screen:
time ( cp /mnt/part/random.bin /dev/null ) real 0m36.565s user 0m0.048s sys 0m1.712s time ( cp /mnt/part/random.bin /dev/null ) real 0m29.157s user 0m0.036s sys 0m1.800s time ( cp /mnt/part/random.bin /dev/null ) real 0m10.265s user 0m0.028s sys 0m1.040s time ( cp /mnt/part/random.bin /dev/null ) real 0m0.608s user 0m0.004s sys 0m0.600s time ( cp /mnt/part/random.bin /dev/null ) real 0m0.590s user 0m0.008s sys 0m0.580s time ( cp /mnt/part/random2.bin /dev/null ) real 0m31.035s user 0m0.056s sys 0m1.816s time ( cp /mnt/part/random2.bin /dev/null ) real 0m31.024s user 0m0.052s sys 0m1.860s
Unsurprisingly, copying a brace of 4 GB files in parallel takes twice as long as each cold-buffer read, so disk’s raw read speed seems to be around 130 MB/s.
The drive’s write speed won’t be the limiting factor while saving camera video data!
The Smell of Molten Projects in the Morning 
While the config format takes a bit of time to get comfortable with, fio is your friend for benchmarking drive speeds. It should be available in your default repositories, including sample job files. http://fio.readthedocs.io/en/latest/
For the bike camera videos, it’s definitely good enough!
The Western Digital 1 TB drive has a 2.7MB partition called WD Unlocker. Beyond the password protect (Windoqs only), there were some utilities that I’m ignoring. That partition is only 2.7MB; I left it alone and it stays mounted. The backup partition is mounted before an rsnapshot run and automagically dismounted.
I have a Seagate drive in reserve, but it doesn’t seem to have any other partitions. Haven’t set it up yet.