What are you measuring the speed with - hdparm or rsync or ?
hdparm is best for profiling just the harddisk (tallks to the interface
and can bypass the cache depending on settings, rsync/cp/?? usually have
the whole OS storage chain including encryption affecting throughput.
Encryption itself can be highly variable depending on what you use and
usually though not always includes compression before encryption. There
are tools you can use to isolate where the slowdown occurs. atop is
another one that may help.
[test using a USB3 shingled drive on a 32 it arm system]
xu4 ~ # hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 1596 MB in 2.00 seconds = 798.93 MB/sec
Timing buffered disk reads: 526 MB in 3.01 seconds = 174.99 MB/sec
xu4 ~ #
BillK
On 21/8/22 06:45, Dale wrote:
Grant Taylor wrote:
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.
I figured it was something like that. ;-)
On 8/20/22 1:15 PM, Dale wrote:
Howdy,
Hi,
Related question. Does encryption slow the read/write speeds of a
drive down a fair amount?
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.
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.
Plus, encryption has the advantage of destroying the key rendering the
drive safe to use independent of the data that was on it.
N.B. The actual encryption key is encrypted with the passphrase. The
passphrase isn't the encryption key itself.
This new 10TB drive is maxing out at about 49.51MB/s or so.
I wonder if you are possibly running into performance issues related
to shingled drives. Their raw capacity comes at a performance penalty.
This drive is not supposed to be SMR. It's a 10TB and according to a
site I looked on, none of them are SMR, yet. I found another site that
said it was CMR. So, pretty sure it isn't SMR. Nothing is 100% tho. I
might add, it's been at about that speed since I started the backup. If
you have a better source of info, it's a WD model WD101EDBZ-11B1DA0 drive.
I actually copied that from the progress of rsync and a nice sized
file. It's been running over 24 hours now so I'd think buffer and
cache would be well done with. LOL
Ya, you have /probably/ exceeded the write back cache in the system's
memory.
It did pass both a short and long self test. I used cryptsetup -s 512
to encrypt with, nice password too. My rig has a FX-8350 8 core running
at 4GHz CPU and 32GBs of memory. The CPU is fairly busy. A little more
than normal anyway. Keep in mind, I have two encrypted drives connected
right now.
The last time I looked at cryptsetup / LUKS, I found that there was a
[kernel] process per encrypted block device.
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.
I noticed there is a kcrypt something thread running, a few actually but
it's hard to keep up since I see it on gkrellm's top process list. The
CPU is running at about 40% or so average but I do have mplayer, a
couple Firefox profiles, Seamonkey and other stuff running as well. I
still got plenty of CPU pedal left if needed. Having Ktorrent and
qbittorrent running together isn't helping. Thinking of switching
torrent software. Qbit does seem to use more memory tho.
Just curious if that speed is normal or not.
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.
Thoughts?
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.
I think the 512 has something to do with key size or something. Am I
wrong on that? If I need to use 256 or something, I can. My
understanding was that 512 was stronger than 256 as far as the
encryption goes.
P. S. The pulled drive I bought had like 60 hours on it. Dang near
new.
:-)
I'm going to try some tests Rich mentioned after it is done doing its
backup. I don't want to stop it if I can avoid it. It's about half way
through, give or take a little.
Dale
:-) :-)
