1 |
On Sat, Aug 20, 2022 at 3:15 PM Dale <rdalek1967@×××××.com> wrote: |
2 |
> |
3 |
> Related question. Does encryption slow the read/write speeds of a drive |
4 |
> down a fair amount? This new 10TB drive is maxing out at about |
5 |
> 49.51MB/s or so. |
6 |
|
7 |
Encryption won't impact the write speeds themselves of course, but it |
8 |
could introduce a CPU bottleneck. If you don't have any cores pegged |
9 |
at 100% though I'd say this isn't happening. On x86 encrypting a hard |
10 |
drive shouldn't be a problem. I have seen it become a bottleneck on |
11 |
something like a Pi4 if the encryption isn't directly supported in |
12 |
hardware by the CPU. |
13 |
|
14 |
50MB/s is reasonable if you have an IOPS-limited workload. It is of |
15 |
course a bit low for something that is bandwidth-limited. If you want |
16 |
to test that I'm not sure rsync is a great way to go. I'd pause that |
17 |
(ctrl-z is fine), then verify that all disk IO goes to zero (might |
18 |
take 30s to clear out the cache). Then I'd use "time dd bs=1M |
19 |
count=20000 if=/dev/zero of=/path/to/drive/test" to measure how long |
20 |
it takes to create a 20GB file. Oh, this assumes you're not using a |
21 |
filesystem that can detect all-zeros and compress or make the file |
22 |
sparse. If you get crazy-fast results then I'd do a test like copying |
23 |
a single large file with cp and timing that. |
24 |
|
25 |
Make sure your disk has no IO before testing. If you have two |
26 |
processes accessing at once then you're going to get a huge drop in |
27 |
performance on a spinning disk. That includes one writing process and |
28 |
one reading one, unless the reads all hit the cache. |
29 |
|
30 |
-- |
31 |
Rich |