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