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 :-) :-)
