1 |
On Mon, Sep 27, 2021 at 9:30 AM Peter Humphrey <peter@××××××××××××.uk> wrote: |
2 |
> |
3 |
> Thanks to all who've helped. I can't avoid feeling, though, that the main |
4 |
> bottleneck has been missed: that I have to read and write on a USB-3 drive. |
5 |
> It's just taken 23 minutes to copy the current system backup from USB-3 to |
6 |
> SATA SSD: 108GB in 8 .tar files. |
7 |
|
8 |
You keep mentioning USB3, but I think the main factor here is that the |
9 |
external drive is probably a spinning hard drive (I don't think you |
10 |
explicitly mentioned this but it seems likely esp with the volume of |
11 |
data). That math works out to 78MB/s. Hard drive transfer speeds |
12 |
depend on the drive itself and especially whether there is more than |
13 |
one IO task to be performed, so I can't be entirely sure, but I'm |
14 |
guessing that the USB3 interface itself is having almost no adverse |
15 |
impact on the transfer rate. |
16 |
|
17 |
The main thing to avoid is doing other sustained read/writes from the |
18 |
drive at the same time. |
19 |
|
20 |
It looks like you ended up doing the bulk of the compression on an |
21 |
SSD, and obviously those don't care nearly as much about IOPS. |
22 |
|
23 |
I've been playing around with lizardfs for bulk storage and found that |
24 |
USB3 hard drives actually work very well, as long as you're mindful |
25 |
about what physical ports are on what USB hosts and so on. A USB3 |
26 |
host can basically handle two hard drives with no loss of performance. |
27 |
I'm not dealing with a ton of IO though so I can probably stack more |
28 |
drives with pretty minimal impact unless there is a rebuild (in which |
29 |
case the gigabit ethernet is probably still the larger bottleneck). |
30 |
Even a Raspberry Pi 4 has two USB3 hosts, which means you could stack |
31 |
4 hard drives on one and get basically the same performance as SATA. |
32 |
When you couple that with the tendency of manufacturers to charge less |
33 |
for USB3 drives than SATA drives of the same performance it just |
34 |
becomes a much simpler solution than messing with HBAs and so on and |
35 |
limiting yourself to hardware that can actually work with an HBA. |
36 |
|
37 |
-- |
38 |
Rich |