| 1 |
Sorry for the duplicate post. I had an email client error that |
| 2 |
accidentally caused me to hit send on the window I was composing in. |
| 3 |
|
| 4 |
On 8/20/22 1:15 PM, Dale wrote: |
| 5 |
> Howdy, |
| 6 |
|
| 7 |
Hi, |
| 8 |
|
| 9 |
> Related question. Does encryption slow the read/write speeds of a |
| 10 |
> drive down a fair amount? |
| 11 |
|
| 12 |
My experience has been the opposite. I know that it's unintuitive that |
| 13 |
encryption would make things faster. But my understanding is that it |
| 14 |
alters how data is read from / written to the disk such that it's done |
| 15 |
in more optimized batches and / or optimized caching. |
| 16 |
|
| 17 |
This was so surprising that I decrypted a drive / re-encrypted a drive |
| 18 |
multiple times to compare things to come to the conclusion that |
| 19 |
encryption was noticeably better. |
| 20 |
|
| 21 |
Plus, encryption has the advantage of destroying the key rendering the |
| 22 |
drive safe to use independent of the data that was on it. |
| 23 |
|
| 24 |
N.B. The actual encryption key is encrypted with the passphrase. The |
| 25 |
passphrase isn't the encryption key itself. |
| 26 |
|
| 27 |
> This new 10TB drive is maxing out at about 49.51MB/s or so. |
| 28 |
|
| 29 |
I wonder if you are possibly running into performance issues related to |
| 30 |
shingled drives. Their raw capacity comes at a performance penalty. |
| 31 |
|
| 32 |
> I actually copied that from the progress of rsync and a nice sized |
| 33 |
> file. It's been running over 24 hours now so I'd think buffer and |
| 34 |
> cache would be well done with. LOL |
| 35 |
|
| 36 |
Ya, you have /probably/ exceeded the write back cache in the system's |
| 37 |
memory. |
| 38 |
|
| 39 |
> It did pass both a short and long self test. I used cryptsetup -s 512 |
| 40 |
> to encrypt with, nice password too. My rig has a FX-8350 8 core running |
| 41 |
> at 4GHz CPU and 32GBs of memory. The CPU is fairly busy. A little more |
| 42 |
> than normal anyway. Keep in mind, I have two encrypted drives connected |
| 43 |
> right now. |
| 44 |
|
| 45 |
The last time I looked at cryptsetup / LUKS, I found that there was a |
| 46 |
[kernel] process per encrypted block device. |
| 47 |
|
| 48 |
A hack that I did while testing things was to slice up a drive into |
| 49 |
multiple partitions, encrypt each one, and then re-aggregate the LUKS |
| 50 |
devices as PVs in LVM. This surprisingly was a worthwhile performance |
| 51 |
boost. |
| 52 |
|
| 53 |
> Just curious if that speed is normal or not. |
| 54 |
|
| 55 |
I suspect that your drive is FAR more the bottleneck than the encryption |
| 56 |
itself is. There is a chance that the encryption's access pattern is |
| 57 |
exascerbating a drive performance issue. |
| 58 |
|
| 59 |
> Thoughts? |
| 60 |
|
| 61 |
Conceptually working in 512 B blocks on a drive that is natively 4 kB |
| 62 |
sectors. Thus causing the drive to do lots of extra work to account for |
| 63 |
the other seven 512 B blocks in a 4 kB sector. |
| 64 |
|
| 65 |
> P. S. The pulled drive I bought had like 60 hours on it. Dang near new. |
| 66 |
|
| 67 |
:-) |
| 68 |
|
| 69 |
|
| 70 |
|
| 71 |
-- |
| 72 |
Grant. . . . |
| 73 |
unix || die |
Archives