Re: [gentoo-user] Getting maximum space out of a hard drive

[Dale]

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

:-)  :-)